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