ゼロから始めるデザインシステム - チーム開発を加速させるデザインアプローチ！ #全文公開
こんにちは！トライブグループという会社でCDOをやっています、原田佳樹 @yoshigorouuといいます。前回はこんな記事を書きました！
9/22(日)の技術書典7に@scrpgilと共著で「ゼロから始めるデザインシステム - チーム開発を加速させるデザインアプローチ！」という本を出展します。
それに合わせて、事前に本書の本文を公開することにしました。技術書典というイベントは年々盛り上がっていますが、デザイン畑の人にはまだまだ認知が高くないと思うので、より多くの人に届けられるようにnoteで公開することにしました。
「ゼロから始めるデザインシステム」ということで、まさにこれから新しくデザインシステムについてしっかり腰を添えて学んでいこうという人向けの本になります。言葉は聞いたことあるけど、実際に使ったことはない、もしくはこれから導入し始めようと考えている、また、いざ導入したものの、そこまでうまく機能していない、そんな人たちに向けた本になります。
本書は6章から構成されています。第1〜5章は理論編、第6章は実践編です。はじめに、あとがき、第6章は書籍版と電子版のみの公開になります。現在オンラインで購入できますので、良かったらどうぞ！
ゼロから始めるデザインシステム - チーム開発を加速させるアプローチ！
--
第1章 デザインシステムとは何か
デザインシステムという言葉が、近年サービス開発者の間で話題になっています。しかし、一時的なトレンドで終わることなく、少しずつ多くの現場で実務レベルでの活用に定着してきたように思われます。ここではまず、デザインシステムという言葉の定義から見ていきましょう。
1.1 デザインシステムは「共通言語」
デザインシステムは多くの企業が導入を始めています。UXPINのリサーチによると、実際にデザインシステム（もしくはパターンライブラリ）を何らかの形で導入、もしくは現在作成しているデザイナーは全体の69パーセント以上にも及んでいるようです。
■図1.1 引用元: 「ENTERPRISE UX INDUSTRY REPORT 2017-2018」
デザインシステムを一言で表現するのは難しいですが、「共通言語」という言葉で説明できると思います。この「共通」というのは、何と何の共通かというと、サービスに関わっているデザイナー、エンジニア、プロダクトマネージャー等のチーム全体における共通項のことです。
なので、「運用を含めた思想・コンポーネントなどを、デザインだけでなくコードまで落とし込んだ開発チーム全員が参照すべき中核になるもの」がデザインシステムと言えるでしょう。
1.2 “Single source of truth”
■図1.2 引用元: 「InVision Design System Manager (DSM) | Design at Scale」
また、InVision DSMの公式サイトにも書かれているように、“Single source of truth” という言葉があります。これは直訳すると「信頼たる唯一の情報源」です。これがまさに、サービス開発におけるデザインシステムが最終的に目指すべき姿と言えます。
デザイナーがデザインするときはそれを元に画面を設計し、またエンジニアが実装するときも同じようにそれを参照します。このように、一元的な管理がされることによって、チームのコミュニケーションコストが削減され、またユーザーにとっても一貫性のある見た目と体験を提供できます。これが近年デザインシステムが話題になっている背景でもあります。
1.3 最小単位のデザインシステム
もう少し具体的に、デザインシステムについて見ていきましょう。以下の図はTwitterの公式ページに載せられているブランドガイドラインです（ガイドラインとデザインシステムの違いについては後述）。開発に関わっている人なら、一度は目にしたことがあるかと思います。
■図1.3 引用元: 「Twitter_Brand_Guidelines_V2_0.pdf」
ここでは、ソーシャルアイコンとしてロゴを使う際のルールが明記されています。Twitterのロゴは、決めれられた形のボタン、決められた色で使わなければならず、白抜きやカラフルにして使ったり、形を変更することは”Misuse”とされています。
次図の投稿に関しても同様です。ツイートの投稿UIそのものは、Twitterのコアなユーザー体験を守るものなので、投稿の中身として載せなければならない要素が次のようにルールとして定められています。
■図1.4 引用元: 「Twitter_Brand_Guidelines_V2_0.pdf」
こういった決まりを設けることで、どこで誰がTwitterの何かを見かけたとしても、一貫したユーザー体験ができるようになっています。以上のような決まりごとは、立派なデザインシステムの一部といえるでしょう。（このブランドガイドラインは、Twitterのチーム内で運用されているデザインシステムの一部を一般向けに公開しているもの。）
1.4 デザイナーとエンジニアの共通言語（Shared Language）
デザインシステムは「共通言語」という言葉で説明できました。この共通言語は、特にサービスを作るデザイナーとエンジニアが効率的に開発を進めることに寄与してくれます。
たとえば、こちらの図はZeplinのとあるアプリの一画面です。
このサービスでは、仮に余白の取り方のルールを4の倍数で運用しているとしましょう。しかし、この「OK」という文字とボタンの上下の余白は19pxと18pxと表示されています。これはルールにのっとっていません。
なので、19px・18pxでは実装せず、4pxの倍数で余白をとって20pxで実装します。19px・18pxにしている説明がデザイナーから特にない場合、このような1pxのズレの確認時間を省略するべきです。
デザインツールで作ったものがエンジニアの手に渡ったときにルールからずれることは発生しうることなので、デザインシステムがそれをカバーし、開発を効率的にしてくれます。また、ルールがあることでサービス開発のスピードを圧倒的にあげることができるのです。
新しくチームにデザイナーやエンジニアがジョインしたときにも効果を発揮します。デザインシステムというチーム内での決めごとがあれば、スタイルやコンポーネントが人に依存することを極力避けることができます。作る人によってアウトプットに差異があるのは望ましくありません。
誰でもそれを見れば、同じスタイルのままデザインし、実装できる。それを叶えてくれるのがデザインシステムです。後から人がジョインしてきたときに、「それさえ参照すれば大丈夫」といったものがあれば、スムーズにサービス作りができるでしょう。
1.5 ユーザーにとっても優しいデザインシステム
もちろん、開発を効率的に進められるだけがデザインシステムではありません。デザインシステムはユーザーにとっても多くのメリットをもたらします。
ひとつに、完成度の高いデザインシステムは、そのサービスを使うユーザー体験を一貫したものにしてくれます。アフォーダンスという概念を用いて考えてみましょう。アフォーダンスとは、その物がもつ形や色などが、その物自体の扱い方を説明しているという考え方です。
■図1.5 引用元: 「アフォーダンスとサッカーのトレーニング -「認知→判断→実行」を超えて-」
たとえば、こちらの図を見てください。小さいドアを見ると、これは「開くものだ」というより「くぐるものであるはずだ」と思うでしょう。「くぐるもの」というアフォーダンスをユーザーに提供している、ということです。
デザインシステムのひとつひとつ、またシステムそのものがアフォーダンスとして機能し、「これはこういう動きをするだろう」「これはこのブランドの色だろう」といった、サービス内でのユーザーの概念システムを確立してくれるわけです。これがデザインシステムのもう一つの強さです。
■図1.6 引用元: 「【エウレカ】Pairs入籍カップルをモデル起用し、渋谷街頭ビジョンやポスターにて複数展開」
さらに、ユーザーが使うサービスの外まで適用されていると、よりデザインシステムは効果を発揮します。「pairs」はすばらしい例です。この広告では、アプリ内で使われている色、テキストのトーン、形をうまくクリエティブに拡張しています。
一度どこかで「pairs」をみたことある人はすぐに「pairs」だと気付きますし、またこの街灯広告を見てからアプリをダウンロードした人は、アプリの中身との整合性に満足し、スムーズにサービスを使うことができるはずです。
このように、ユーザー獲得のチャネルに使うクリエティブに細かいルールを設けたり、サービスを使った後のコンシェルジュからの文言ルールを明確にしたりと、デザインシステムの適用範囲は広く定義できます。
サービス内だけでなくユーザーが触れるタッチポイント全てを、プラットフォームを横断した形でデザインシステムをもって運用できれば、それが最終的にブランドイメージとなり、競合サービスとの大きな差別化ポイントにできるのです。デザインシステムは、そこまで活用することができれば強力な武器になります。
第2章 デザインシステムは何で構成されているか
ここからは具体的に、デザインシステムが何によって構成されているかを見ていきます。よく比較の対象としてスタイルガイドがあげられますが、デザインシステムとの違いはどこにあるのでしょう。また、デザインシステムをどう運用するかについても考察してきます。
2.1 デザインシステムの構成要素
構成要素を一言で説明するのは難しいですが、いくつかの案をヒントにしていきましょう。まず、図2.1を見てください。
■図2.1 引用元: 「 Design systems, style guides, pattern libraries. What the hell is the difference?」
図2.1では、デザインシステムはカラーやアイコンなどのルールを定めたスタイルガイドラインとコンポーネントライブラリ、そしてアクセシビリティやモーション等のルールを含んでいることがわかります。
・Style Guide スタイルガイド
・Component Library コンポーネントライブラリ
・motion, accessibility etc.. モーションやアクセシビリティ
よく比較の対象としてあげられるスタイルガイドですが、これはデザインシステムの一部に含まれていることが、この図からわかりますね。
■図2.2 引用元: 「Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?」
次に図2.2を見てみましょう。こちらの図では、デザインシステムは、スタイルガイド、タイポグラフィやグリッド等のブロック、モジュールやテンプレートを含むパターンライブラリ、そして各ガイドラインを設けたルールの4つで成り立っていると図解されています。
・StyleGuide スタイルガイド
・Building Blocks コンポーネント
・Pattens library パターンライブラリ
・Rules ルール
2.2 もっと詳しいデザインシステムの構成要素
さて、2つの事例をみてデザインシステムの構成要素がわかったのではないのでしょうか。本書では、少なくとも次の3つを含んでいるものを、デザインシステムと呼ぶことにします。それぞれの詳細をみていきましょう。
・Design Rules 運用ルール
・Style Guide スタイルガイド
・Component Library コンポーネントライブラリ
2.2.1 Design Rules 運用ルール
■図2.3 引用元: 「Uber Rebrand 2018」
Design Rulesは、デザインシステムを運用していく上で実は一番重要な要素です。これは、スタイルガイドやコンポーネントライブラリをより抽象化した、クリエティブ面での方向性を決めてくれるデザインシステムのコアになります。
図2.3のように、3〜5個のシンプルで明確なテキストとしてまとまっているデザイン原則や、それぞれのスタイルやコンポーネントをどう使うかといったルールを記載したドキュメントによって構成されています。
2.2.2 Style Guide スタイルガイド
■図2.4 引用元: 「Atlassian Design」
Styleguideは、図2.4のようなカラーパレットを始めとして、タイポグラフィのルール、アイコンセット、イラスト、余白の取り方といったスタイリングに関する部分のルールが記述されています。そのサービスらしさを作ってくれる重要な要素です。
エンジニア向けに作られているデザインシステムツール上だと、次に述べているComponent Libraryと一緒にまとまっている場合もあります。
2.2.3 Component Library コンポーネントライブラリ
■図2.5 引用元: 「CI&UIリニューアルしながらデザインシステムを作った話」
Component Libraryは、ボタンやフォームといったUIに使われるパーツをまとめたものです。図2.5を見ると、パーツの粒度はさまざまですが（ここはAtomic Designの出番です）、よく使うものがパーツとしてまとまっていることがわかります。
たとえば新しく機能を追加するときに、これを参照するだけである程度のUIを組み立てることができます。コンポーネントライブラリは、デザイナーとエンジニアの開発効率をあげる重要な要素になるのです。
第3章 デザインシステムが盛り上ってきた背景
デザインシステムはなぜ今盛り上がりをみせ、導入する企業が増えてきているのでしょうか。それは、CSSフレームワークやデザインツールの進化といった、近年のデザイナーを取り囲む環境の変化があると考えています。
3.1 Webを取りまく技術の進化
ここ数年のデザインシステムの盛り上がりは、Web界隈を中心とした技術の進化が背景にあリます。次のフレームワークなどが代表例としてあげられるでしょう。
・CSSフレームワーク
・UIフレームワーク
・Webコンポーネント
それぞれ順に紹介していきます。
3.1.1 CSSフレームワーク
■図3.1 引用元: 「Bootstrap 1.4」
スタイルガイドはデザインルールの共有に効果を発揮しましたが、実装面は開発者の技量に左右されます。特にCSSを構造的に設計するのは非常に難しく、OOCSSやBEMといったアプローチが登場しました。一番普及したアプローチはBootstrapでしょう。
Bootstrapはボタンやナビゲーションなど、よく使われるパターンを定義したCSSフレームワークで、HTMLとCSSの正しい組み合わせにより使用できます。この方法は、カルーセルやドロップダウンなど複雑なコンポーネントを作ることも可能にしました。
また各コンポーネントの実装方法はBootstrapのサイトにいけば閲覧でき、コピー&ペーストで簡単に利用できます。これは現在のデザインシステムのコンポーネントライブラリに通じるアプローチになったと思われます。
3.1.2 UIフレームワーク
■図3.2 引用元: 「Angular」
Bootstrapのアプローチは開発面の効率化をもたらしましたが、JavaScriptの進歩によってさらに効率的なアプローチが登場しました。それはAngular、ReactのようなJSフレームワークによるコンポーネント指向の実装です。
これらは、UIパーツを見た目や振る舞いといったスタイリングを含めて、ひとつのまとまりとして実装できます。HTML、CSS、JavaScriptを1つのまとまりとして実装できるようになったのです。
これらのコンポーネント指向を持ったJSフレームワークの登場により、デザインと実装の同期が格段とやりやすくなりました。その中でも特にReactは、AirbnbやAtlassian、Shopifyなど高度なデザインシステムを導入している企業で採用されています。
またOSSプロジェクトでもUIフレームワークが続々と登場しました。たとえばAngularを用いて作成されたAngular MaterialやIonic、Vueを用いて作られたElementUIやVuetifyは、新たに登場したUIフレームワークでしょう。
■図3.3 引用元: 「webcomponents.org」
AngularやReactを使用することで、実装面で優れたUIフレームワークを構築できました。しかしながらこの方法は、特定のJSフレームワークに依存してしまうというデメリットもあります。たとえばAngularを使って構築したUIフレームワークはReactから使用することはできません。
そこで、そのデメリットの解決を期待できる技術としてWebコンポーネントが登場しました。これはコンポーネント指向の実装をピュアなJavaScriptで実装できる技術で、2018年にはほぼすべての主要なブラウザで動作するようになりました。
WebコンポーネントはWeb標準の技術で動作するため、特定のJSフレームワークに依存しないUIフレームワークを構築できます。すでに先ほど紹介したIonicは、WebコンポーネントベースのUIフレームワークになっており、AngularやReact、Vueからも利用できるようになっています。
またStencilなど、Webコンポーネントを効率的に作成できるライブラリも登場しました。今後もWebコンポーネントを利用したUIフレームワークが続々と登場してくるでしょう。
3.2 デザインツールの進化
デザインツールの進化もデザインシステムの盛り上がりに影響を与えました。最初期、Webデザインは主にAdobe Photoshopで行われていました。しかしPhotoshopはWebだけでなく、写真加工やエディトリアルなどリッチなデザインを作ることができるツールであったため、Webデザインで使うには高機能すぎる面もありました。
その後、より軽量かつ安価なデザインツールSketchが登場しました。SketchはWebやアプリケーションのUIデザインを作ることに特化しており、Phothoshopに比べて軽量に動くことが特徴的です。Sketchはシンボル機能といって、コンポーネントをデザインツール上で整理することができます。
またそれに合わせて、デザイナーとエンジニアの協業を効率化するInVisionやZeplinなどが登場しました。これらのツールの登場によって、スタイルガイドやコンポーネントの共有がしやすくなったため、よりデザインシステムに取り組みやすくなったと言えます。
■図3.4 引用元: 「Figma」
そして最近はFigmaのような複数のユーザーで同時編集ができるツールも登場し、チームによるデザイン編集を効率的に行えるようになりました。これによって、デザインをするという行為がデザイナーに閉じられたものではなく、オープンにデザインをしていくという流れを作ったように思われます。
第4章 デザインシステムの事例
本章ではデザインシステムの事例を紹介します。すでに著名な企業の多くはデザインシステムを導入しています。また、自社の取り組みやコンポーネントライブラリを公開しているところも多くあります。
海外の企業の導入事例は規模として大きすぎるものが多く、導入としては参考にならないこともあるので、日本企業で公開されているデザインシステムも合わせて紹介します。
4.1 海外のデザインシステム事例
海外の著名な企業の多くは、デザインシステムを導入しています。ここでは特に著名な4つの企業の事例を紹介します。
1. Airbnb: DSL
2. Atlassian: ADG
3. Uber: ブランドシステム
4. Shopify: Polaris
4.1.1 Airbnb：DSL
■図4.1 引用元: 「Building a Visual Language -Airbnb Design」
Airbnbは世界中で宿泊サービスを展開しているアメリカの企業です。未上場ながら評価額10億ドル以上の「ユニコーン企業」として日本でも有名でしょう。そんなAirbnbが構築したデザインシステムが、Design Language System(DSL)です。DSLはAirbnbの成長によって生じた、次の問題を解決するために構築されました。
・制約
・複数デザイナー体制
・複数プラットフォーム展開
・ソフトウェアの継続的な改善
DSLの特徴はデザインとコードが完全に同期しているところです。たとえば、Sketchファイルに存在するデザインモジュールには必ずコードも含まれていますし、そのモジュールに相当する実装も必ず存在しています。Airbnbはこの同期を実現するため、いくつかの内製ツールを開発しています。
■図4.1 引用元: 「react-sketchapp」
たとえば、react-sketchappというツールです。これはReact.jsからSketchファイルを自動生成するツールで、このツールによりAirbnbはデザインとコードの完全なる同期を実現しているのです。
またDSLは専門のDSLチームによる厳格なプロセスによって守られています。新しいモジュールを追加するときは既存モジュールを流用するか、新しいモジュールが機能しているかをチェックされます。DSLチームにより問題ないと判断されなければ実装をすることができません。
以上のような完成度から、DSLは現在多くの企業から参考にされているデザインシステムの事例になっています。
4.1.2 Atlassian：ADG
■図4.2 引用元: 「Atlassian Design」
Atlassianは、JIRAやHipChatといったソフトウェア開発に役立つサービスを運営している会社です。Bitbucketは使ったことある人も多いでしょう。
AtlassianはAtlassianデザインガイドライン(ADG)というデザインシステムを構築しています。これは、複数サービスを運営するAtlassianが各デザインのばらつきや開発効率を向上させることを目的に作成されました。
ADGはデザイン原則やブランド、そしてAtlaskitというUIライブラリを持っています。Atlaskitは社内の誰もが改版できるOSSとして存在しており、JIRAやBitbucketに利用されています。
Airbnbとの違いはオープンなところです。DSLが専門のDSLチームにより運用されていたように、ADGにも専門のチームが存在します。しかし、ADGは専門チーム以外のAtlassian社員全員がコントリビュートが可能になっており、積極的にコントリビュートすることが推奨されています。これは、サービス毎にUIのベストプラクティスが異なるAtalassianに沿ったデザインシステムの運用方法になっていると思います。
ADGは2012年から継続して運用されており、各ドキュメントはADGのサイトから誰でも閲覧できます。ADGはオープンなデザインシステムの最良の例のひとつでしょう。
4.1.3 Uber：ブランドシステム
■図4.3 引用元: 「Uber Rebrand 2018」
Uberは「ユニコーン企業」の代表としてAirbnbに並ぶ、自動車の配車サービスを世界中で展開している企業です。日本ではフードデリバリサービスのUber Eatsでも有名でしょう。
彼らが2018年に発表したのがブランドシステムです。これは、世界中どこでもユーザーがUberのサービスが見つけられることを目的に構築されました。
ブランドシステムの特徴の一つは、ロゴへの投資です。Uberはコーポレートロゴをもたず、Wordマークだけを利用しています。また「Uber」という文字を認識しやすいようタイポグラフィ「Uber Move」を作成しています。
■図4.4 引用元: 「Uber Rebrand 2018」
他にも、Uberの「u」を利用したuフレームガイダンスというものが定義されています。これは、Uberのクリエイティブに「u」の文字を忍ばせるものです。これを利用することでポスターなどの大型広告でもUberであることを認識できるようになっています。
UberのブランドシステムはAirbnbやAtlassianのデザインシステムとはまた異なった、ブランドを作ることに特化した事例と言えるでしょう。
4.1.4 Shopify：Polaris
最後にShopifyのPolarisを紹介します。Shopifyはカナダ発ECプラットフォームです。誰でも簡単にECサイトを構築できるサービスです。
PolarisはShopifyが2018年に公開したECサイトを構築するためのデザインシステムです。PolarisがAirbnbやUberのデザインシステムと違うのは、オープンソースプロジェクトとして公開されているところです。
誰もがShopify内はもちろん、それ以外のプロジェクトでもPolarisを利用でき、ShopifyがこれまでECサイト構築で培ったUI/UXの恩恵を受けることができます。また、Polarisの公式サイトはデザインシステムの管理ページとして非常にまとまっているので、デザインシステムについてまず触れて見たい人は閲覧することをお勧めします。
4.2 日本での事例
ここまでは海外のデザインシステムの事例を紹介しました。海外企業の導入事例は規模が大きく、初期段階で参考にするのは難しいでしょう。導入の参考になる日本企業の導入事例を紹介します。
4.2.1 コデアル
■図4.6 引用元: 「Codeal Design Guideline」
コデアルのデザインシステムを構築した話がnoteで公開されています。このnoteにはデザインシステム構築の際の目的設定から開発への影響範囲、チームとの協業をどのように行ったかが記載されています。また、実際に作成したガイドラインやSketchファイルも公開されています。これからデザインシステムを始める際に、まず最初に参考にしたい事例です。
4.2.2 クックパッド：Citrus
■図4.7 引用元: 「「UXエンジニア」って何する人？ クックパッド流・開発力を高めるDesignOpsの進め方」
クックパッドが導入しているデザインシステムが「citrus」というものです。この取り組みについても記事が公開されています。
クックパッドが当初はUIフレームワークを用いてデザインの共通化をしていたが、グローバル展開を見据えてデザインシステム構築を始めた流れや、利用したツールの話がまとめられています。デザインシステム導入のタイミングや規模感の参考になると思います。
4.3 事例から分かること
ここまで、海外と日本の事例をみてきました。Airbnbのように実サービスと深く結び付いているものもあれば、Uberのようにブランド確立のために構築されたものもありました。また、多くの企業は複数チーム、サービスになった段階でデザインシステムを導入しています。事例から分かったことをまとめてみましょう。
・海外企業はデザインシステム専任のチームが存在している
・タイポグラフィまで開発している企業がある
・海外でオープン化されている事例は規模が大きすぎる
・デザインシステムは複数サービス、チームができた時に導入される
この他にもデザインシステムの導入事例は多く公開されています。自社にデザインシステムを導入する際には、規模に合わせて各社の事例を参考にすると良いでしょう。
4.4 アプリのデザインガイドライン
ここまでデザインシステムの事例は、Webサービスに沿った事例を紹介してきました。次は、アプリのデザインガイドラインをみていきます。アプリのガイドラインは、AppleのHuman InterfaceGuidelineとAndroidのMaterial Designの2つがあります。
4.4.1 iOS Human Interface Guidelines
■図4.8 引用元: 「Human Interface Guidelines」
Human Interface Guidelines（HIG）はAppleが作ったデザインガイドラインです。1978年に初版が出てからずっと更新がされ続けています。HIGはもともとデスクトップ環境向けのドキュメントでしたが、iOS向けにも「iOS Human Interface Guidelines」が公開されています。このガイドラインに沿ってUIを構築すれば、誰でも直感的で、使いやすいアプリが作れるようになっています。
また、HIGに準拠しているかどうかがアプリ公開前に審査されるため、App Storeは一定の水準のUIを持ったアプリのみが公開されるようになっています。デザインシステムとは少し違いますが、厳格な審査が存在していることによって、開発者がHIGに準拠する仕組みができています。
4.4.2 Material Design
■図4.9 引用元: 「Material Design」
Material DesignはAndroidアプリのためのデザインガイドラインです。基本概念は、ユーザーが接する画面にマテリアル(物質)というメタファの用いて一貫性のある世界を作る、というものです。
Google Playストアは審査がゆるく、どんなUIであろうとアプリの公開が可能です。そのため、かつてのAndroidはUIがばらばらという状況でした。そこにMaterial Designが登場し、AndroidのUI・UX作成の指針ができました。
Google Playストアの審査は今でもMaterial Designに沿っていないアプリのリリースも可能です。それでも多くのAndroidアプリ開発者は、Material Designに準拠した開発を行うことが当たり前になりました。
4.4.3 ガイドラインから分かること
iOS、Androidともデザインシステムではないですが、そこには強いガイドラインが存在しています。もしアプリでデザインシステムを作る場合は、ガイドラインにかぶせる形で構築することになります。
これらを行うことは複雑で、難易度が高く、気合いと高いスキルが必要になってきます。アプリでデザインシステムを構築する場合、それを行う価値があるほどのサービス規模になっているか、社内のリソースは足りているか、この辺りをよく検討する必要がありそうです。
第5章 デザインシステムの導入、正しい運用管理方法
デザインシステムの導入は、開発チームの規模感や、サービスのフェーズによってそれぞれです。物によっては必要ない場合もあるでしょう。また、デザインシステムは導入より、運用の方が大事です。採用するツール含め、デザインシステムをどう管理していけばよいのでしょうか。
5.1 デザインシステムは小さくリーンに
デザインシステムは初期から一気に作るより、小さくリーンに始めるべきです。導入タイミングは、サービスのフェーズや数、開発に関わる人数によって変わってきます。
まず前提として、プロダクトがPMF（プロダクトマーケットフィット）していない場合は、デザインシステム作りに時間をかけるのはやめましょう。新しいサービスを作る場合は、一貫性や柔軟性を追求より、できるだけ早くサービスのコアバリューに達することに時間を使うべきです。
PMF以前にデザイナーがいるのであれば、自分が使いやすいようにデザインツール上でのコンポーネントの整理をすることに留めておくべきでしょう。
■図5.1 引用元: 「デザインシステムに関わるいろいろなプロセスを図にしてみた」
チームの人数も考慮すべき点です。デザイナーが1〜2人で回しているチームの場合は、やはりサービス作りに専念すべきでしょう。その規模では、デザインシステム作りのためのリソースがないに等しいですし、時間をかけた分だけの恩恵を得られる程でもありません。
このタイミングでは、たとえばアプリであればOSに準拠したマテリアルデザインやiOSのHIG、WebであればJSフレームワークやWeb Copornentを活用した方が効率的に開発できます。
5.2 どのタイミングで導入するのか
上記のフェーズを超えたことを前提として、デザインシステムの導入は次のいずれかの状況を迎えたら検討するとよいでしょう。
まず、デザインチームと言えるレベルのチームができた時です。サービス開発以外に、デザインシステムのことだけをメインに考えることができるリソースを確保できたら、少しずつ着手していきましょう。サービスの大きさにもよりますが、3人以上のデザインチームができると取り組みやすいと思います。
また1つのサービス内に縦にチームができたときにも、導入を検討すべきです。CS部門やマーケティング部門など1つのサービス内にチームが増えると、それぞれが定義するユーザー体験に最適化して物ごとを進めて行くようになり、サービス全体の品質を保つのが難しくなります。そこで、チームを横断する形でユーザー体験を一定にしてくれるデザインシステムが大変役に立ちます。
最後に検討すべきは、サービスが複数展開し始めるフェーズです。これは、1つのブランド内で横展開をするのか、もしくは縦に事業を深掘って行く形になると思います。ここではさらにユーザーとのタッチポイントが増えるため、先ほど同様にクオリティコントロールが大変になってきます。この状況こそデザインシステムで補えるのではないでしょうか。
5.3 メンテナンスデイを設け、運用していく
本章の冒頭に述べたとおり、デザインシステムは一気に作り込むより、少しずつ拡張していくのが望ましいです。一気に作ってリリースする場合は、だいたい運用に失敗するケースが多いです。なので繰り返しになりますが、デザインシステムは作って終わりではなく、小まめに作って運用していく、というスタンスで取り組みましょう。
サービスが大きくなったり、チームの数が増えるにつれて、デザインシステムも一緒に進化していかなければいけません。新しい機能を盛り込んだり、担当する人が増えると、管理することも増えていきます。なので、デザインシステムを作る専任リソースがない場合は、定期的に見直す時間をとるのがオススメです。たとえば月に1回のメンテナンスデイを設け、増えてしまったコンポーネントをチーム全体で整理していくのがよいでしょう。
5.4 どのツールで運用し、管理するのがいいのか
ここからは、デザインシステムの運用方法とツールについて紹介していきます。さまざまなデザインシステムやコンポーネントを管理するツールが世の中にありますが、大きく分けて2つに分けられると思います。ひとつはデザイナー向けに作られているもの、もうひとつはエンジニア向けに作られているものです。
5.4.1 デザイナー向けのツール
デザイナー向けに作られているツールは、基本的にはSketchやXD、Figmaといったデザインツールと連携して作られています。アップロードしたデザインデータを元に、スタイルガイドやコンポーネントライブラリを生成したり、リッチなドキュメントを書けたり、アセットの書き出し等ができます。InVision DSMやzeroheightなどがそうです。
・InVision Design System manager （DSM）
■図5.2 引用元: 「InVision Design System Manager (DSM) | Design at Scale」
InVision DSMはInVision社から出ているデザインシステムツールです。デザインツール上でのアップデートの反映、強力なヒストリー機能、複数人編集ができます。また、デザイントークンAPIというものを使用して、最新のデザインシステムをコード上で管理することができるのも魅力的です。
・zeroheight
■図5.3 引用元: 「zeroheight · document your design systems, together」
もうひとつ代表的なサービスとして、zeroheightがあげられます。zeroheightは、Invision DSMで出来ることにプラスして、リッチなドキュメント機能が特徴的です。デザインシステムを作る上で重要な、Design Rulesの運用をスムーズに行えます。
5.4.2 エンジニア向けのツール
一方、エンジニア向けに作られているツールは、主な機能としてはコンポーネントライブラリの管理になります。エンジニア側で実装したものを、コードベースで再度コンポーネント化し、それらyml等で管理することでライブラリ集として使うことができます。
・Storybook
■図5.4 引用元: 「Storybook Build bulletproof UI components faster」
たとえば有名なのは、Storybookでしょう。StorybookはVueやAngularといった主要なJSフレームワーク向けのUIコンポーネントを管理できるツールです。このページをコンポーネントライブラリとして運用すれば、使いたいときに呼び出せるので非常に便利です。
・Stencil
■図5.5 引用元: 「Stencil」
また最近では、特定のJavaScriptのフレームワークにとらわれずに、Web標準に準拠したWebコンポーネントを生成できる、Stencilにも注目が集まっています。
5.5 Single source of truthを実現を目指して
2種類のデザインシステムのツールを見てきました。ここで問題になってくるのはデザイナー向けツールで管理するのか、もしくはエンジニアツール向けで管理するかです。
冒頭に、デザインシステムのあるべき姿は、“Single source of truth” だと述べました。この思想は、コード上でスタイルガイドやコンポーネントが管理されて初めて、実現可能なものだと思います。なので、これまで述べてきたデザインシステムの構成要素は、すべてコード上で管理されているのが望ましいでしょう。
デザインツール上で管理されているものは、パターンライブラリにすぎません。たとえば、デザイナーだけで考えてしまうと、実装の実現可能性が加味されていないコンポーネントを生成してしまうこともあります。また、デザインツール上で見ていたものが、インスペクタ機能の未熟さゆえに実際にブラウザやアプリで確認すると元のデザインとどこか違う、なんてこともよくあります。
これでは、「唯一信頼たる情報源」であるべきというデザインシステムの思想を叶えることはできません。この課題は、ツールで解決されるべきです。しかしながら、それを叶えてくれるデザインシステムのツールはまだ世の中にはないように思われます。
デザイナー向けのツールはデザインツールの連携やドキュメント機能が充実していますが、コード連携はまた簡易的なスタイルガイドにとどまっている印象です。またエンジニア向けツールでは、UIコンポーネントの管理は便利ですが、デザインツールとの連携はできませんし、運用上重要なDesign Rulesの運用が難しいでしょう。
■図5.5 引用元: 「The 2019 Design Systems Survey」
最後に、参考までにどのデザインシステムツールが採用されているのかについて載せておきます。The 2019 Design Systems Surveyによると、デザインシステムを導入している108チームのうち、34%はStorybook、32%はInVision DSMを利用しているようです。
第6章 ゼロから始めるデザインシステム （実践編）
ここまで、理論編としてデザインシステムについて理解を深めてきました。ここから実際に、ゼロから始めるデザインシステムということで、架空のサイトを元にデザインシステムを作っていきましょう。理論編で見たデザインシステムの3つの要素、デザイン原則・スタイルガイド・コンポーネントライブラリを主に作っていきます。
(第6章は書籍版のみの公開となります)
第6章目次
・6.1 求人ページを作ろう
・6.2 デザイン原則を決めよう
・6.3 コンポーネントライブラリを作ろう
・6.4 スタイルガイドを作ろう
・6.5 コンポーネントライブラリを実装しよう
--
「ゼロから始めるデザインシステム - チーム開発を加速させるデザインアプローチ！」のほぼ全文公開は以上となります。書籍だと70ページ、文字数に換算するとおよそ2万字という、そこそこ分量の多い内容になりました。ここまで読んで頂きありがとうございます！
弊社でのデザインシステム導入はまだ日が浅いながらも、少しずつノウハウが溜まってきました。実践編の続きとして、これからもデザインシステムについての情報発信をしていければなと思います。
最後に、株式会社キネカ(10月にTRIVE GROUPとして生まれ変わります！)では、デザインシステムに挑戦してみたいデザイナーを募集していきます！ご興味ありましたら、ぜひ私のツイッターのDMまでご連絡ください！