2024年10月3日にオンラインセミナー『デザインシステム構築の進め方 基本から実践まで、具体的な手順を徹底解説』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。
目次
デザインシステムとは
まず、デザインシステムとは何か、というところから説明していきます。
デザインシステムとは、あるべきデザインを提供するための「ルール」や「実践方法」をまとめた『仕組み』です。
以下にデザインシステムの構成要素を示しておきます。
- デザイン原則
- スタイルガイド
- UIパターンライブラリ
- ルール・禁止事項
デザインシステムは、以上のようなものを構成要素として包括しています。
スタイルガイドとデザインシステムの違い
「スタイルガイドとデザインシステムは何が違うのか？」といった質問をいただくことがよくあります。使用するフォントや色、余白の値などについてまとめられたドキュメントであるスタイルガイドは、デザインシステムの一構成要素です。
先述のようにデザインシステムの構成要素に含有されるため、「このドキュメントがデザインシステムである」といったものではありません。デザインの一貫性を保つために明示されたルールや実践方法だけでなく、作成されたデザインファイルやソースコード等も包括する全体的なものがデザインシステムと呼ばれています。
デザインシステム導入のメリット
では、デザインシステムを導入することにより、どのようなメリットが得られるのでしょうか。大きくは以下のような3点が挙げられるかと思います。
- 一貫したUX/UIを提供できる
一貫したUIとは直感的に操作可能なUIのことであり、ユーザーがストレスなく使用できるものです。見た目やルールが統一されたUIにより、操作や動線に迷うことのない質の高いUXをユーザーに提供することができます。 - デザインと開発の効率化
デザインシステムを構築する際に作られるボタンやナビゲーション、フォームなどのパーツを集めたコンポーネントは、再利用可能な形で実装していきます。このようなコンポーネントやデザイントークンを再利用することで、デザイナー・エンジニアの工数削減につながります。 - コミュニケーションコストの削減
例えば、ユーザーの権限によって特定の操作を制限するような画面をエンジニアが実装する場合、ボタンなどの制限する項目を非表示にするべきか、非活性にするべきかといった迷いが生じることがあります。事前にルールが設けられていると、デザイナーへの確認が不要となり、コミュニケーションコストを削減することができます。このようなデザイナーとエンジニア間のQAに限らず、メンバー交代による引き継ぎや、外部ベンダーへの説明などにかかるコスト削減にも役立ちます。
デザインシステムの基本構成
以下は、デザインシステムの構成要素を示した図です。大きくデザイン、コード、ドキュメントに分かれています。
- デザイン
コンポーネント、サンプル画面、デザイントークンなどビジュアルデザイン作成に必要な情報を含む
使用ツールの例：Figma、Sketchなど - コード
デザインを参照しながら作成されたコンポーネントライブラリや、それらのソースコード(HTML・CSS、React等)を含む
使用ツールの例：Storybook、Code Sandboxなど - ドキュメント
デザイン原則、スタイルガイド、ソースコードなどUIに関わるあらゆる情報を含む
使用ツールの例：zeroheight、Confluence など
以上のような構成要素のうち、デザインシステムを実際に活用する場合は基本的にドキュメントを参照していくことになります。
デザインシステムの活用事例
自社で作成したデザインシステムを一般公開している企業もあります。参考までに、その一部をご紹介いたします。
クラウド人事労務ソフトSmart HR様の事例
コンポーネントからアクセシビリティまで幅広く提供されており、またサービスビジョンが明確なため、企業ブランディングの観点からもお手本のような事例となっています。
上図の左が、ドキュメントに当たる部分です。ボタンコンポーネントについて、見え方や使い方のルールなどが記載されています。
上図の右は、コードに当たる部分です。コンポーネントを一覧化したもので、詳細な説明や、ルールなどは記載されていません。コンポーネントのバリエーションやサイズの変化等を一覧で管理しているツールになります。
基本的には左のドキュメントが全体向け、右のツールは主にエンジニアが開発時に使用するものとなっています。
デザインシステム導入の判断軸
このような好事例も見られるデザインシステムですが、必ずしも全てのプロダクトに対して有効とは限りません。構築自体に工数がかかるものなので、適切な効果が見込める場合にのみ導入するという風な判断が必要です。
以下の表に、デザインシステムを導入するか否かの判断基準をまとめました。基本的には、一つでも当てはまる項目があれば導入のメリットが見込めるというものです。
| 導入を推奨 | 現時点では必須ではない | |
| プロダクト | 規模が大きいプロダクトや、複数プロダクトで一貫したデザインの提供が必要 | PoCなど技術的実現性の検証を目的としているプロダクト |
| チーム体制 | メンバーが多い、アサインの変更が頻発する | メンバーは基本的に固定である |
| 品質 | UIの一貫性が重要である | UIの一貫性が重要でない |
| 開発スピード | 機能追加・変更時のリリース速度に改善が必要である | 機能追加・変更は発生しないか、発生してもリリース速度は重要でない |
デザインシステム構築の具体的な流れ
ここまで、デザインシステムの概要についてご説明してきました。ここからは、具体的な構築の流れについてご説明していきます。
以下は、基本的なデザインシステム構築の流れになります。
各段階について、順を追って説明していきます。
デザインシステム構築の事前準備
デザインシステム構築を始める前に必要な事前準備は、大きく４点あります。
- 目的の明確化と現状把握
- ロードマップの策定
- ステークホルダーとの連携
- ツールの導入
目的の明確化と現状把握
まず、目的の明確化と現状把握を行うことが重要です。なぜかというと、目的と現状とのギャップを認識することで、アクションの検討に繋げることができるからです。また、これにはチーム全体の方向性を統一するという狙いもあります。
目的を設定するには、デザインシステムを構築する理由となった課題から考えるとよいでしょう。例えば、デザイン作成に工数がかかっている、できあがったデザインに一貫性がないなどの課題です。こういった工数や品質の課題解決を目的としてデザインシステムの導入が検討されることは少なくありません。
目的の明確化と現状把握からアクションを抽出する
ここで、前出のような目的からアクションを抽出する場合の具体例を見ていきましょう。
- 課題……自社プロダクトのUI作成に工数がとても掛かっている
- 目的……工数削減
- 現状……プロダクトごとにUIを0から作成している
- アクション……スタイルガイドの整備・UIコンポーネントのライブラリ化
自社プロダクトのUI作成に工数がかかっているという課題に対し、工数削減という目的を設定します。この目的に対し、現状どのようなギャップがあるか分析すると、プロダクトごとにUIを０から作成しているということが分かったとしましょう。ここから、スタイルガイドの整備やUIコンポーネントのライブラリ化といったアクションが抽出できます。新たなプロダクトに着手する際も、すでに整備されたスタイルガイドを参照したり、UIコンポーネントを再利用したりすることによって工数削減に繋げたいという考えです。
ロードマップの策定
目的の明確化と現状把握ができたところで、次はロードマップの策定です。
ロードマップとは、フェーズごとに明確な目標を設定し、順序立てて進行する計画のことを指します。ガントチャートなどと比較して、抽象度の高いものになります。
上図のデザインの欄には「スタイルガイド作成」や「UIコンポーネント整備」など、先に抽出したアクションが当てはめられています。このようなロードマップを策定することにより、ステークホルダー間で目標や全体の流れなどについて共通認識を持つことができるようになります。
ステークホルダーとの連携
ステークホルダーとの連携を考えていく上で、デザインシステムを構築するために最低限必要な３つのロールについて確認しておきましょう。
- プロダクトオーナー(PO) / プロジェクトマネージャー(PM)
−デザインシステムの方向性や、優先順位を管理する - デザイナー
−デザイン原則の検討や、スタイルガイドの策定 - エンジニア
−デザインファイルを基に、再利用可能なコンポーネントを開発
デザインシステムを構築する前に事前準備の段階から、できる限りこれらのステークホルダーを巻き込むようにします。より広範なチームが初期の段階から関わるほどスピーディーに導入が進むことに繋がりますので、実際の社内体制に合わせて、ここに書かれたステークホルダー以外についても整理しておくことをおすすめします。
ツールの導入
事前準備の最後はツールの導入です。どのようなツールが必要なのか見ていきましょう。
上図は、デザインシステムを構築する際に使用するツールと、その関係性を示しています。図内で挙げているツールは一般的によく使われるものであって、これでないといけないというものではありません。
- Figma
UX/UIデザインやプロトタイピングに特化したデザインツール。
リアルタイムの共同編集やデザイントークンの管理などが行いやすく、デザインシステム構築に向いている。 - Github
エンジニアが実装したコードを格納し、チーム全体に共有するためのコード管理ツール。 - Storybook
ボタンやカードなどの実装したコンポーネントをUIカタログとして管理することができるツール。それぞれのUIコンポーネントをブラウザで確認することができる。
例えばエンジニアの場合、これを参照しながら開発を進めたり、正しく動くかテストを行ったりできる。 - Chromatic
StorybookをベースとしたUIテストツール。Storybookをインターネット上に公開し、利用者が確認することができるようになる。
Storybookを用いて実装したコンポーネントに対して、UIの変化が意図通りであるかを容易に確認することができる。また、公開することにより、例えばデザイナーの場合、デザイン通りに実装されているかということを確認したりコメントを付記したりすることができる。また、公開範囲を設定できるため、社内関係者のみに向けての公開や、特定のメールアドレスの人に対してのみ公開することなども可能。 - zeroheight
デザインシステムを管理・共有するためのドキュメント作成ツール。一貫性のあるデザインと開発を実現するための基盤を提供する。
Figmaでデザインしたコンポーネント、Chromaticで公開されたUIカタログなどを一元管理し、表示することができる。また、デザイン原則のような文書などもここで管理する。 - Miro
チームのコラボレーションやブレインストーミングを効率的に行うためのオンラインホワイトボードツール。
図を共有しながら議論したり、ツール上に意見を残したりすることができるので、議事録的に使用し、後から見返すことも可能。本ツールを用いてデザイン原則について議論し、その結果をzeroheightに反映するなどの使い方をします。
デザイン原則
事前準備ができましたら、デザイン原則を考えていきます。
デザイン原則とは
デザイン原則とは、プロダクトの核となる「らしさ」や「重要なことはなにか？」を定義・明文化したものです。
以下は、先にご紹介したSmartHR様からの引用です。
基本原則として「誠実」「ポジティブ」「わかりやすい」「親しみやすい」といった言葉が並べられています。これはデザイン原則に当たるもので、デザインの方針を決める際の判断軸となります。デザイン原則は、このように抽象的な言葉を用いて定義していく特徴があります。
デザイン原則構築の進め方
以下に、デザイン原則を構築する際の進め方の一例を示します。
デザイン原則はデザインシステムの基盤となるため、POやPM、デザイナーやエンジニアといったステークホルダー全体が関わりますが、デザイナー主体で進めていく場合が多いです。
まず、企業のブランドイメージやビジョン、プロダクトの目標などといったイメージを確認するリサーチを行います。例えば、「高級感」をブランドイメージとしている場合、エレガントなデザインを目指すことをデザイン原則として定義することなどが考えられます。また、これは続くワークショップでアイデア出しを行う際の種となります。
次に、リサーチ結果を元にステークホルダー全体が集まってワークショップを行います。ブレインストーミング等の発想法を用いてアイデア出しをするのですが、ここで重要なのはステークホルダー全体が集まることです。デザインシステム構築に対する意識付けにも繋がるため、一部のステークホルダーのみで進めてしまうのではなく、なるべく様々なロールの人が参加するようにします。
続いて、フィードバックと修正です。先のワークショップで出されたアイデアを、プロダクトの目標に合致しているか、ユーザー体験の向上に繋がるかといった観点から精査していきます。
最後に、これまでの議論結果を、zeroheightを用いてドキュメント化します。
デザイン原則構築のポイント
このような手順でデザイン原則を構築する上で、ポイントとなることが３点あります。
- 具体的すぎていないか
デザイン原則はデザイン全体に関わる要素を定義するものなので、例えば、「ボタンは右上に配置する」といった具体的なデザイン指示は適切ではありません。「エレガントさ」「わかりやすさ」など、簡素で抽象的な言葉を用いることが望ましいでしょう。 - 数は適切か
一般に、3〜5個程度が推奨されています。数が増えすぎてしまうと、それら全てを守ってデザインすることが困難になってしまうためです。 - 現実的に実現可能か
例えばスタートアップ企業での取り組みのようにリソースが限られている場合、複雑なインタラクションやアニメーションなどを全面に押し出したようなものを目指すと、工数がかかりすぎ、実現性が低くなってしまいます。設定したデザイン原則が、現実的に実現可能であるか否かを見定めることが必要です。
スタイルガイド
デザイン原則が策定できたら、スタイルガイドを作成していきます。
スタイルガイドとは
スタイルガイドとは、色やタイポグラフィなど、全体のスタイルに関わるドキュメントおよびルールのことを指します。
上図はAmeba様が構築しているSpindleというデザインシステムを公開したページです。ここでは、サイドバーに表示されたカラー、タイポグラフィ、アイコン、イラストレーション、アニメーションといった要素ごとにルールが示されています。
もう少し具体的に見ていきましょう。
上図は、UIカラーに関するページです。ここでは、テキストに使用する色がカラーパレット形式で表示され、管理されており、ダークモード版も用意されています。
Surface Color & Text Color
Surface＝表層であり、Backgroundの上に乗るカラーです。 アイコンなど、オブジェクト単体の色などにも適用します。 Button等、Surfaceレイヤーが二枚以上重なる場合もあります。Text Colorは全般なテキスト表現に使用するカラーです。 WCAG2.1に準拠し、原則として背景色に対してコントラスト比4.5:1を保持する必要があります。 そのため、背景色に応じて選択可能な色が限定しているので注意してください。
更に、テキストに使用する色の使い方について、上記のように文でも説明がなされています。これらの色はテキスト表現に使用すること、といった使用目的に加え、背景色に対してのコントラスト比などが具体的な数値を交えて記されています。
スタイルガイドの主な構成要素
ここまでSpindleの例を見てきましたが、スタイルガイドの主な構成要素について確認していきましょう。スタイルガイドの主な構成要素には、以下の４点が挙げられます。
- 基本要素
デザイン全体の基盤となるもの。色、タイポグラフィ、余白、影などの要素が含まれます。 - UIコンポーネントライブラリ
ボタンや入力欄などのUI部品のこと。 - ルール
基本要素やUIコンポーネントライブラリをどのように使うか、または使ってはならないかを定めたルール。 - アクセシビリティ
高齢者や障害のある方なども含めた、全ての人が利用しやすいようにするための品質基準。
例えば、テキストの色と背景色との組み合わせやコントラスト比、フォントサイズにより可視性・可読性を担保することなどが含まれます。また、デザイン面だけでなく、スクリーンデータが適切に読み上げられるHTML構造にすることなど、システム開発に関わることもここに含まれます。公共性の高いサービスにおいては非常に重要な要素になる一方で、一部の社員しか使わない業務用システム等の場合は、ある程度ユーザーが限定できるため、ユーザーの持つ特性に合わせてあえて対応しないことも考えられます。
スタイルガイド構築の進め方
以下に、スタイルガイドを構築する際の進め方の一例を示します。
ここでは、デザイナーが主体となりスタイルガイドの構築を進めていきます。
まず、既存資産やデザイン原則の確認といったリサーチを行います。多くの場合、すでに動いているプロダクトに対して導入する場合がほとんどですので、既存のデザインファイル等を参照して使用されている色やアイコンなどについて棚卸しをする必要があります。また、デザイン原則で「信頼感」と定義していた場合、イメージに合った青系の色をメインで使用するというようなこともこの段階で考えます。
続いて、基本要素定義です。先ほど、スタイルガイドの主な構成要素でご説明したように、色、タイポグラフィ、余白、影などの要素を含むデザイン全体の基盤となるものを定義します。figma等のデザインツールで作業を行いながら定義していきます。
次に、UIコンポーネント作成です。こちらは後ほど詳しくご説明しますが、開発要素は含まれない、デザイン側の作業となります。デザインファイルの作成や、その使用に関するルールの定義を行います。
最後に、アクセシビリティ対応を行います。先述の通り、公共性の高いサービスでは特に重要になりますので、ユーザーの持つ特性に合わせて対応を考えていきます。
そして、これらの作業を通して、随時zeroheightを使ったドキュメント化も進めていきます。
UIコンポーネント
スタイルガイドが作成できたら、UIコンポーネントライブラリの構築に入っていきます。
UIコンポーネントライブラリとは
UIコンポーネントライブラリとは、ボタンや入力欄などの機能を持つ、再利用可能な要素の集合です。
上図は、shopify様の公開しているデザインシステムのうち、UIコンポーネントをまとめたUIカタログです。UIカタログとは、UI コンポーネントライブラリを視覚的に整理し、一覧化したもので、上図のようにコンポーネントをカタログのように一覧化することができます。UIカタログは、UIコンポーネントとして作成したパーツや、画面自体の閲覧・動作検証を行えるため、主にエンジニアが活用するツールです。実際に開発中のアプリケーションとは切り離して UIコンポーネントの閲覧やテストが行え、またそれを複数のプロダクトに導入することができるため、開発効率の向上に役立ちます。
UIコンポーネントライブラリ構築の進め方
以下に、UIコンポーネントライブラリを構築する際の進め方の一例を示します。
ここでは、デザイナーが主体となる場面と、エンジニアが主体となって構築を進める場面とがあります。
今回も、すでに動いているプロダクトに対して導入する場合を想定していますので、まずは必要なUIコンポーネントの特定を行います。例えば、現行のログイン画面がある場合、メールアドレスの入力欄やログインボタンなどといったUIコンポーネントが存在しています。そういった既存のUIコンポーネントの棚卸しと併せて、必要となるUIコンポーネントを特定します。
続いて、UIコンポーネントの整理です。先に棚卸しした必要なUIコンポーネントに対して、機能や見た目が同じもの同士を統合して統一感を出すようなことを行います。また、一つ前の手順で作成した色やタイポグラフィといった基本要素を適用したり、バリエーションを作成したりします。ここまでは主にデザイナーの作業となります。
次に、エンジニアが開発・テストを進めていきます。開発では、Reactのようなコンポーネント実装に特化したライブラリ・フレームワークを用いることで、効率的にコンポーネントの開発を進めることができます。
最後に、開発・テストの完了したものを公開します。ここでは、StorybookとChromaticを用いて、社内などの特定の関係者が確認できるようにします。
UIコンポーネントライブラリ構築のポイント
以上のような順番でUIコンポーネントライブラリを構築する上で、ポイントとなることが３点あります。
- コンポーネントにバリエーションを持たせ、再利用性を高める
ボタンコンポーネントを例にとると、形・サイズなどのバリエーションを持たせ、同じコンポーネントを異なる場面でも再利用できるようにします。決定ボタンをLサイズ、閉じるボタンをSサイズにするなど、ひとつのコンポーネントで表現できることを増やすと、新たにコンポーネントを作成する手間が省けます。 - デザインと開発に一貫性を持たせ、保守性を高める
ボタンにS・M・Lというサイズのバリエーションがあったとして、新機能の追加に伴いXLが必要になった場合、XLのデザインを作成するのはもちろん、開発面での変更も必要になります。この際、デザインと開発のバリエーションの持ち方を一致させておくと、開発の負担が軽減され、こういった追加にも容易に対応できるようになります。 - 複数プロダクトに導入する場合は、ライブラリ化を検討する
開発のライブラリ化はよく耳にしますが、デザインに関しても同様にライブラリ化を検討することが必要です。Figma等のツールにはライブラリ機能があるため、コンポーネントの部分だけデザインをライブラリ化し、新たなプロダクトではそのライブラリを読み込んで活用するといった風に効率化を図ることができます。
継続した改善
UIコンポーネントまで作成できたらデザインシステム構築は完了、というものではありません。
プロダクトのスケールや環境の変化に対応するため、継続的な改善が必要です。改善に対応するためには、運用ルールの策定が重要になってきます。例えば、「コンポーネントに追加には承認を必要とする」という運用ルールを定めておくと、経験の浅いデザイナーが独断でコンポーネントを追加し、デザインシステムの一貫性が欠如してしまうというようなことを防ぐことができます。
デザインシステム構築のポイント
以上が、デザインシステム構築の一連の流れです。最後に、デザインシステム構築全体に関わるポイントを３点ご紹介します。
- 小さく始めよう
ここまでご説明してきたように、デザインシステムの構築は大変な作業です。いきなりプロダクト全体へ適用するのではなく、一旦新機能だけでコンポーネント化やスタイルガイドの適用を試してみるなど、小さく進めてみると良いでしょう。 - 進め方は多様
ここまでは一般的な進め方についてご説明してきましたが、必ずしもこれが正解というわけではありません。例えば、品質に課題がある状態で、迅速に結果を出す必要がある場合などは、UIコンポーネントの整理のような結果が分かりやすいステップを先に行うことをお勧めします。現状の課題に対して適切な進め方を考えるようにしましょう。 - 密なコミュニケーション
デザインと開発に一貫性を持たせることで保守性が上がるため、デザインシステム構築において、特にエンジニアとデザイナーの連携は重要です。例えば、週次のデザインレビューを行う際はデザイナーだけでなくエンジニアも参加し、お互いの進捗を確認し合い、疑問点を解消するなどして、密なコミュニケーションを心がけてください。
デザインシステムのご相談はNCDCへ
NCDCでは、デザインシステムの検討から構築までご支援しています。
本記事でご紹介したような手順に基づき、ルールの策定からUIコンポーネントのデザイン、開発まで一貫してサポートいたします。
デザインシステムの導入を検討している方、どこから手をつけたらよいか悩まれている方は、ぜひ一度お気軽にご相談ください。
