フロントエンドエンジニアの立場から「デザインシステム」をつくることができたので、その作成プロセスとできたデザインシステムをご紹介します。
「デザインシステム」とは
あるプロダクトのデザインに関するルールを定義し、そのルールに則ってプロダクトをデザインしていく仕組みのことです。
具体的には
- どうやってデザインするか(フォントや色や配置などの決め方)
- どうやって繰り返し使えるようにパーツを分割するか (ヘッダーやフッター、ボタンなどのパーツ分割の仕方)
- 何を基準にそれを更新していくのか
- どうやって関係者全員がそれを理解している状態にするか
これらを仕組み化したものです。
簡単な例だと、みなさんもパワポでプレゼン資料を作るとき、
「タイトルはこのフォントやサイズや色を使って」
「コンテンツはこのフォントサイズで」
「使うオブジェクトの角は丸くして」
「フッターにはこのロゴを置いて」
などを考えるのではないでしょうか。 それがページが変わる度に位置も余白もフォントも色も形もバラバラではまずいことはお分かりかと思います。
引き継いだパワポの体裁がバラバラで、地獄の修正作業をした人もいるのではないでしょうか。
こういうときに作成者全員がルールを守れるようにする仕組みをつくると思います。
会社のプレゼン資料ではブランド毀損がないようにテンプレートを作っている会社もありますよね。
ただ、テンプレートを使っていても、テンプレートにない表現をしたいときはどうしていますか?パワポのデフォルトのままだと、これまでの体裁に合わないのはわかっているけど、どうしたらよいかわからないのでデフォルトのまま貼り付けたことはないでしょうか。他にも画像の背景を透過にせず、白いままにして台無しにしていることはないでしょうか。
それがデザインの体裁崩壊の始まりです。
こういう時のためにデザインの方針を決めておき、それに則ってパーツをつくり、さらに他の人が使えるようにテンプレートに組み込むまでを仕組み化することが「デザインシステム」といえます。
Webサービス開発におけるデザインの保守は難しい
パワポの場合でも容易に崩壊してしまいますが、Webサービスの開発ではその規模も大きく、複数人で作業するため、そのルールを守り続けることはさらに難しいです。 また、デザインの崩壊に関しては、プレゼン資料の場合はそれほど社会的影響度は低いかもしれませんが、Webサービスの場合はその影響度は高く、ビジネスを揺るがす可能性もありあます。
そこで近年ではWebサービス開発の現場に「デザインシステム」を導入することが注目されています。 AirbnbやTEDなどの多くの企業はすでに「デザインシステム」を導入しています。
だが「デザインシステム」をつくることも難しい
ならばデザインシステムをつくろうと思ったとき、デザイナーの方が頑張って原則からルールを定めてチームに展開することがあります。 しかし、Webサービス開発ではそれをフロントエンドエンジニアが「実装」し、コードを「管理」しなくてはなりません。
作成されたデザインがいかにルールに則っていても、フロントエンドエンジニアはどの粒度で、どう管理していいのかわからず頭を悩ませます。
そういった現状を踏まえ(たわけではないのですが)、今回フロントエンドエンジニアの立場からデザインシステムをつくることができたのでその作成プロセスとできたデザインシステムをご紹介します。
お話しの前提
- サービスは昔からあり、ページは数十ページある
- 体裁が揃っていないページが多くチーム内では改善したい意欲がある
開発フロー
- ディレクター:4人〜7人
- デザイナー: 2人
- フロントエンドエンジニア:2人
進め方
- デザイナーはページ単位でデザインカンプを作る
- エンジニアはそれをコンポーネントに分割する
- ルールに厳密ではなく、ルールに外れた場合は次の開発で修正しにいく
※カンプとは、サイトのイメージをすり合わせるために作成される完成見本図のこと。
※コンポーネントとは、ボタンなどのページを構成するパーツのこと。
使用技術
- Vue.js(もちろんReactでもよい)
コンポーネント指向のJavaScriptのフレームワーク - Storybook
コンポーネントを一覧化するツール - Sketch
WebページやアプリのUIなどをデザインするためのツール - Abstract
デザイン作業を複数のデザイナーで同時に行ったり、デザインカンプを共有するためのツール
話さないこと
- デザインガイドライン
- 具体的な実装
エンジニアからはじめたデザインシステム
コンポーネントの分割
はじまりはデザインシステム云々の前に、vueを使ったコンポーネント指向のUI開発をしていて、どういう風にコンポーネントを分割するのがよい粒度なのか?という疑問を解決することからでした。
そこで行き着いたのはAtomicDesignという考え方です。
Atomic Design はUIを構築するための方法論でしかないので、デザインや実装方法、運用方法は独自に考えました。
実際に導入してみるといくつか乗り越えなくてならないハードルが存在しましたが、今はその設計ルールを使ってうまく回っています。
どいう風にコンポーネントを分割したかについては以下の記事にまとめています。
これにより、コンポーネントの粒度に関してはフロントエンドエンジニアは迷わなくなりました。
コンポーネントの一覧化
今度はコンポーネントが増えてくると探すのが大変になりました。
そこで、Storybookを導入しました。
このツールは、デザインパターンおよびその使用方法についての原則やガイドラインを収集、格納、共有するツールです。
ReactやVue.jsを使用しているプロジェクトではおすすめです。
デザイナーを巻き込む
エンジニア内では、AtomicDesignの概念によってうまくコンポーネントを分けることができるようになりました。
ただ、デザイナーから渡されるデザインカンプをみると、担当のデザイナーさんによって微妙に違うパーツがあり、同じ目的でつかうものなのか、違う目的で使い分けが今後必要なのかなど、デザインの意図と目的がわからないことがありました。
例えば、ページによって異なる余白など。
とりあえず言われたまま作っていると同じコンポーネントだがデザインが違うパターンが複数できあがっていくという課題が発生していました。
そこで、デザイナーさんを含めて課題の認識合わせを行うことにしました。
「Design Systems」輪読会
そもそも、私が何をやろうとしているか、何を目指しているのかをデザイナーとフロントエンドエンジニアに伝えたく、「Design Systems」という本を輪読しようともちかけました。
他社ではどうやっているかなど、やりたいこと以上のことが書かれていて私が熱弁するより効果的でした。
みんな賛同してくれ、業務時間内で毎週1時間をつかって1章ずつ声に出してよみました。
実際、毎週1時間1章ずつできました。
全10章なので10週で終わります。
本を読みながら、うちはこうだよね!とか、これができてないよね!とかが話せてとても効果的でした。
「デザインシステム会」を発足
その後、輪読会をしていたメンバー(デザイナーとフロントエンドエンジニア)でデザインシステム会をつくりました。 輪読会で気づいたデザインシステムを導入する上でやらなければならないことを洗い出したり、新しいパーツについて話し合う会です。
具体的には
- コンポーネントの粒度がなじんでいるか確認
- コンポーネントの粒度とSketchによるシンボル化の粒度が合っているか確認
- コンポーネントの名称がSketchと合っているか確認
- コンポーネントの表示パターンが必要最低限か確認
- コンポーネントの使用用途を決める
- コンポーネントがStorybookで一覧化されているかの確認
- その習慣が各担当者間でできているかの確認
本の指南もあり、やらなきゃいけないことが割とスムーズにだせたかと思います。
もちろん、この会はいま続いております。
チャットの専用チャンネルを作る
チャット上にデザイナーとエンジニアでコンポーネントに関するやりとりをするための専用チャンネルをつくりました。
疑問に思ったらそこで会話をします。特に名称を決めるときによく使います。
ディレクターを巻き込む
デザイナーとエンジニアで育てたStorybookはそのメンバーがいなくなったあとでも更新されていなくてはなりません。
Storybookを利用したデザインシステムが関係者全員に溶け込んでもらう必要がありました。
なので、ディレクターにもStorybookをみる習慣をつけられないかと考えました。
「Storybookを見てください」ではダメなので、どう習慣化するかがポイントです。
もともとディレクターがつくったワイヤーフレームに以下のような課題がありました。
- 他のページではこういう表現だが、ここは別の表現になっている
- そのページに複数の表示パターンがあることが考慮されていない
デザイナーやフロントエンドエンジニアが指摘をすることが多いのですが、指摘し忘れた場合は後ろの工程で気づくことになり、デザインや実装を止めてしまうこともありました。
この課題を解決するのにStorybookを活用してもらうことを思いつきました。
Storybookにページに関する全ての情報を記載する
先ほどの問題は、ページにいまどのような施策があるのかが可視化できていないのが一番の原因だと思いました。
ただし、それはwikiとかではなく、デザインされたものの近くに書いていないとおそらく誰もみてくれません。
そこで、Storybookのnotesというaddonを導入しました。
storybook/addons/notes at next · storybookjs/storybook · GitHub
Storybookのv5では導入するとプレビューのすぐ横にタブが設けられ、その中は自由にマークアップすることができます。
そして、そこにはページに関する全ての情報を記載するようにします。
例えば以下のような情報です。
- URL
- 使用目的
- 表示パターン
- ABテスト状況
- 実装注意事項
また、ディレクターと話し、開発のフローも少し変更しました。
- 案件企画担当者はNotesの内容をコピー
- 自分の案件で更新があるところを加筆・修正する
- 要件が書かれたドキュメントに添付する
- エンジニアはStorybookを更新する
- テスト時にディレクターはStorybookが更新されていることも確認する
これによってディレクターは案件作成時にそのNotes(Storybook)をみる習慣ができ、 Storybookも常に最新の状態になるようになる仕組みができました。
副次効果として会話もStorybookにある言葉でされ始めます。デザイナーとエンジニア間では名称はすでに合わせているので後ろの工程もよりスムーズになります。
出来上がったデザインシステム
以下が現場の慣習に合わせてつくった「デザインシステム」です。
どうやってデザインするか
残念ながらデザインのコンセプト・原則を決めたり、デザインコンセプトからデザインする作業は完全にデザイナーさんにお任せしていて、 どうしてその色にしたのか、どうしてそのフォントサイズにしたのかなどの作成フローはまだ私の中で言語化できていません。(いずれできるようになりたい)
そういった意味ではデザイナーのスキルが高くないとデザインをシステム化するのは難しいと思いました。
フロントエンドエンジニアとしてはその決められたカラーやフォントサイズを定数として定義し、
それ以外のカラーやフォントサイズ、余白などを実装で使うことを原則禁止するということをやりました。
また、Storybookにカラーパレットを作ったり、そういった情報をいつでも見られるようにもしました。
どうやって繰り返し使えるようにパーツを分割するか
目的達成に向けて、どのような行動をユーザーに促したいかが焦点になります。
私は先述したAtomicDesignの考え方にこれらを落とし込んでおり、それを使って分割しています。
記事に書いたことを抜粋すると、以下のように分割しています。
Atoms(原子)
* リンクやボタンやフォームのパーツ単位など UI の最小要素
* 見た目に関することはこのモジュールで表現する
* PowerPointの一つの図形で表現できるもの
(ラジオボタン・セレクトボックスなどのフォームは例外)
Molecules(分子)
* AtomsとMoleculesから構成されるグループで、比較的小さいコンポーネント
* 中身の文言や配置を変えることで使い回しが可能なもの
* 別のOrganismsを跨いで出現するもの、または、これから出現することがわかっているもの
* PowerPointの図形をグループ化して表現するもの
Organisms(生命体)
* AtomsとMoleculesから構成されるコンポーネント
* 広告のバナーのように、どのページに配置しても意味がわかる独立したコンポーネント
* デザイン上初めてでてくるもので、使い回すかどうか不明なもの。(未知の生命体)
* 使い方が限定的なもの。
* PowerPointの図形をグループ化して表現するもの。
ただ、これは一つの指標なので、デザインシステム会で話し合った結果、階層をかえることはありえます。
よく機能パターンの洗い出しには、「ユーザーの行動を分析して」とか「ユーザーストーリーマッピングをつくって」などがありますが、 開発スピードが遅くなってしまうし、時間もなかったのでやりませんでした。
いかに迷わず開発者が開発できるかが重要なポイントだと思います。
何を基準にそれを更新していくのか
ルールは厳密ではなく、間違えていたら次それを修正していくスタイルなのですが、
なるべくそうならないように下の2つの会議でレビューを行なっています。
レビュー会
ディレクター/デザイナー/フロントエンドエンジニアの3者が集まってUIのレビューを行う。
主に要件の筋がよいか、UI/UXに問題がないか、結果どうだったかを話す。デザインシステム会
以下を話し合う。
この2つの会を通して更新を行っています。
どうやって関係者全員がそれを理解している状態にするか
開発のフローにStorybookを置くようにしました。
また、Storybookの更新が滞らないようにするように考えました。
①企画
- StorybookのNotesにあることに目を通し表示パターンなどを確認する
- Notesの更新を要件に加える
②デザイン
- デザインコンセプトにそってデザイナーはページやパーツをデザインする
- 完成したら担当ディレクターと担当エンジニアの両方に確認してもらう
③実装
④テスト
- ディレクターとデザイナーが確認する
- ディレクターはStorybookに書かれていることも確認する
関係者全員がStorybookに目を通すようにしました。
「あのページが見れなくなってる」など、ディレクターからエスカレーションがあるのは嬉しい悲鳴です。
まとめ
フロントエンドエンジニアからデザインシステムを考えてみたら意外とすんなりモノゴトが進んだと感じました。
結論として、デザインシステムを始めるならフロントエンドエンジニア側から考えるのがいいのでは?と思いました。
なぜかというと理由は2つあります。
1つ目は
「どうやって分割するか」はエンジニアが考える作業
になると思うからです。
デザイナーがコンポーネントを組み上げてページをデザインするのはとても難しいことだそうです。
デザイナーはページ全体から詳細を整えていく作業をするからです。
つまり、コンポーネント分割はデザインカンプを渡された後のエンジニアの担当になると思います。
今回はそこが先にクリアになっていたのがよかったのかなと思いました。
逆にクリアになっていないままデザインシステムをやろうとしても悩むことになると感じました。
2つ目は
いまある実装で急に「コンポーネント一覧ツールを用意せよ」と言われてもエンジニアは大変だからです。
コンポーネント一覧ツール(パターンライブラリ)なしではデザインシステムは難しいと言われていますが、使用技術によっては使える使えないがありツールの選定に時間がかかります。
しかも、それをメンテナンスされるように開発フローに取り込まないといけません。
今回はStorybookが使えるようにするために技術選択をしてきたところもあるので、何か実装手段を変える必要はありませんでしたが、
KSSやSC5 StyoeGuideなど、これまでにいろいろ試した経緯があります。
自分たちの開発スタイルにあったものを選ぶまで時間がかかりました。
この2つがデザインシステムを始めるならフロントエンドエンジニア側から考えるのがいいのでは?と思っている理由です。
デザインシステム導入はコミュニケーションも活発になり「正しくものをつくっている」感があって、とても安心して開発ができるようになりました。
デザインがどうではなく、Webサービス開発において重要な仕組みではないでしょうか。
ここに書いたことはもちろん体制によって当てはまらないかもと思いますが、デザインシステム導入をお考えのプロジェクトの参考になれればと思います。