Tweet
Share
はじめに
こんにちは、デザイナーの浜田です。
マンガZEROのWebリニューアルを担当することになり、AtomicDesignに則ってSketchでデザイン制作をしました。
そして今回デザイナーがAtomicDesignで言うAtoms/Molecules/OrganismsあたりのHTML/CSSを書いてみようという話になり、Storybookが導入されることになりました。
本記事ではデザイナーがStorybook+AtomicDesignを使って開発に参加してみてどうだったか、どのように活用ができたか、について紹介したいと思います。
デザイナー＆エンジニア間でStorybookが有用に使えそうかどうかの参考になればと思います。
※本記事では、Storybookの環境構築やコードについての解説などは行いません。
AtomicDesignについては以前に弊社デザイナーが記事にしているので紹介です。
AtomicdesignとSymbol機能でUIデザイン制作効率化！Sketchファイル1つで完結するデザイン制作と伝達のツボ
Storybookとは
StorybookはUIコンポーネントの開発環境です。各コンポーネントの挙動のテストだけでなく動的なスタイルガイドとしても利用することができます。
現在(v3.3.0-alpha.4)
- React
- Vue
- Angular
- Polymer
に対応しているようです。
サンプル（公式）がこちらから確認できます。
サンプルのキャプチャですが、以下のようなコンポーネントカタログを作成することができます。
Storybookを始める
おそらくメインはVueかReactで始めるかと思うので、公式のスタートガイドを紹介します。
また、こちらの記事で日本語で解説されており、アドオンについても触れられているので分かりやすいかと思います。
ちなみに私のようなVue.js初心者は本当に分からないことだらけになる可能性大なので、都度公式ドキュメントを読むことをオススメします。。！
今回チャレンジしたこと
- 開発に参加！
- Storybook (Vue.js + Pug + Typescript + PostCSS)
- GitHubをチーム開発で使う
環境構築など下準備をエンジニアさんに全て行ってもらい、githubからcloneしてくれば始められる状態からスタートしました。
また、私がこのプロジェクトに携わる前にどのくらいエンジニアリングに理解があったかは以下の通りです。
- HTML/CSSがある程度かける
- javascriptはほぼ書いたことがない(昔jQueryを少し書いたくらい)
- Storybook未経験
- Gitはほぼ個人プロジェクトでしか使用したことがない
開発に参加してみて-良かった点
自分でスタイルを書くことができる
コーディングをお願いした際に、「あれ、ここちょっと違うな..」という箇所を減らすことができるのは大きいと思います。
(De)デザイン制作→(En)実装→(De)確認→(De)修正依頼→(En)修正→(De)確認のフローを
(De)デザイン制作→(De)実装/修正(→(En)コードレビュー)にできるため、修正のやりとりが大幅に減ることになります。
デザイン制作時の取捨選択に役立つ
例えばですが、cssではborderに簡単にグラデーションを当てられないことを知っていないと、デザインでは簡単に出来てしまいます。
実装の難易度を知れることは、デザインする上でちょっと面倒でもここは実現させたい、とかの取捨選択に役立つんじゃないかなと思います。
新しい技術に触れることが出来た
今回全く初めて触れたのがVue.js/Typescript/PostCSSでした。ほとんどです。
Vue.jsが採用された経緯については以下の記事で解説されています。
次の項目でも触れていますが、状態別にクラスを当てたり表示を切り替えるのが、v-bind:classやv-ifを使って簡単に出来て使いやすかったです。
Storybookを使ってみて-良かった点
コンポーネントを一覧で確認できる
イメージ的にはSketchのSymbolページのような感じです。Storybookだと動的なスタイルも加わるため、例えばhover時のスタイルやクリック時の挙動なども確認することができます。
前に使ったスタイル、アニメーションを再利用しよう！という時に参照しやすく、一覧で見たときにコンポーネントが増えすぎてしまっていないかの確認も容易です。
また、アップデートなどで追加のデザインが必要な際にも、スタイルガイドがあると再利用可能なコンポーネントの確認がしやすいですよね。
まだStorybookの運用はしていないのですが、今後の運用も便利になりそうな印象です。
イベントが書けなくても(恐らく)使える
私はjavascript(今回はTypescript)をほとんど書いたことがないので、Storybookの強みである「状態別にスタイルを確認できる」「アクションの確認ができる」などのイベントの追加があまり出来ませんでした。
しかしCSSはある程度書くことが出来たので、状態別にスタイルを当てることは可能です。
WebデザイナーであればHTML/CSS/(js)を習得されている方も多いかと思うので、「状態別にスタイルを当てる」ことができれば充分に活用できるかと思います。（ただしその後のイベント追加はエンジニアさん任せになるので要相談です。）
ちなみに私は今回難しいことは出来ませんでしたが、勉強のためにも簡単なルールや記法を教えて頂き、簡単なイベントだけ追加できるようになりました。（画像の@clickイベントの追加など）
デザイナー側でイベントを書くことができればよりStorybookを活用できそうです。
今後のデザインに反映出来そう
今回AtomicDesignに則ってStorybookを利用したので、AtomsやMoleculesを組み立て、Organismsを形成していく過程がとても分かり易かったです。
デザイン制作時には「これMoleculesかな、Organismsかな…」と迷うことも多かったですが、実装時にどんな風に組み立てられるかが分かっていると、デザイン制作時に正しくコンポーネントを分けられそうだなと感じました。
デザイナーからすると、UIの設計に加えてコーディングの設計も並行して進めることができるようになると言えるかなと思います。
複数人開発で有用
Storybookは複数人での開発で、より役に立ちそうです。
全員が共通したコンポーネントカタログを参照できる環境があることで、開発者同士の意思疎通がスムーズになり、デザイナーが開発に参加していることでデザインとの乖離も防ぐことができます。
また、デザイナーが参加する場合は全ての実装をデザイナーが担当するわけではなく、コンポーネント単位やAtomicDesignのレベル単位で担当を分けるとハードルも低くチャレンジしやすいです。
AtomicDesignを採用したことによって、複数人での開発が進めやすくなるのではないでしょうか。
Storybookを使ってみて-反省点
スタイルの調整が楽な分、変更箇所が増えてしまった
これは良かった点にも挙げたことですが、長所でもあり短所でもあるところです。
デザイン制作時に細かくルールを作っていたのに、自分でスタイルを書きながら「やっぱりこうしようかな」と変更する箇所が多くありました。
プロダクト全体で決めていたルールをちょこちょこと変更してしまっては、ページが出来上がった時にばらつきが生まれるかもしれません。
もちろん変更が必要な時はあるとは思いますが、完成されたデザインを作り、それを忠実に再現できることが一番だなと思いました。
Storybookを利用するときは、デザインデータではなくStorybookのスタイルガイドが正であると決めておくといいかなと思います。
Storybookの注意点
どこまでコンポーネント化するか
今回のプロジェクトでは目安として、処理が必要なもの、複数回使用するものをコンポーネント化するというルールが決めてありました。
これには、コンポーネントが増えすぎると管理が大変になってしまうことや、パフォーマンスが低下してしまうという背景がありました。
デザイナーからすると、どこまでコンポーネント化するべきか？が曖昧な場合があるかもしれないので、プロジェクト毎に目安があるとわかりやすいかなと思いました。
マークアップは慎重に
Atoms/Moleculesでは、汎用性がなくなってしまうようなマークアップは避けるようにするのが吉です。
Atomsを<a>でマークアップした時にMoleculesやOrganismsで<a>がネストしてしまうことがあったため、なるべくAtomsやMoleculesでは意味を持たせないマークアップをしていきました。
Viewport Addonを入れよう
ブラウザの開発者モードでスマホでの見え方を確認すると思いますが、Storybookを使用するときはうまく使えないためStorybook Viewport Addonを入れると正しく表示を確認することができます。
まとめ
まず注意すべきことが1点、エンジニアさんのリソースを割かなければならないことです。環境構築などゴリゴリできちゃうデザイナー以外は、エンジニアさんに頼らなければならないところがたくさんあります。
今回のプロジェクトでは、エンジニアさんからStorybookを使ってみようと提案して頂いたので、スムーズに導入できましたが、デザイナー側から提案するには少しハードルがあると思います。
ただ今回のプロジェクトでStorybookを実際に使ってみて、デザイナーが使いこなすことができればエンジニアさんとの共通言語が増え、コミュニケーションを取りやすくなると思いました。
また、「やっぱりあれ変更したいな..」「ここ微妙にデザインと違うな..」といった変更を自分で行えるのが強い魅力です。
またAtomicDesignを採用すると、デザイナーが担当する範囲を決めやすくなります。レイアウト調整などが入らないAtomsのコンポーネントであれば、HTML/CSSに馴染みのないデザイナーでも取り掛かりやすいかと思います。
そして徐々にMolecules~Organismsも担当していくようにすれば、デザイナーにとっては良い勉強になると思います！
今回Storybookを導入して見て、すでに自分でもスタイルを書いているデザイナーでも、そうでない方でも、動的なスタイルガイドを作成できるという点ではStorybookが有用ではないかなと思いました。
本記事で開発に足を踏み入れてみたい！と思ったデザイナーさんがいたら良いなと思います。
しかしながらエンジニアさんの協力が不可欠なので、導入を検討する際にはしっかり相談しましょう！
大きなサービスや、今後も定期的に運用/更新があるWebサイトなどではStorybookが活躍しそうです。
