デザインシステムとの連携
みなさんは UI の記述ですでに学んだように、React コンポーネントが
- 見た目と振る舞いを定義できる（一貫性）
- 「似ているけどちょっと違う」を定義できる（柔軟性）
- 繰り返し使用できる（再利用性）
ことを学びました。
一方で、実際に React コンポーネントを実装していくと
- どのような見た目にすべきか？
- 例: 可愛い見た目にするべきか？落ち着いた見た目にするべきか？
- どのような振る舞いにすべきか？
- 例: 動画が取得できたら再生を自動で開始するか？ユーザーによる操作を待つか？
- どこまでの「似ているけどちょっと違う」を同じコンポーネントとして実装すべきか？
- 例: 幅が固定の見た目と幅が可変の見た目を同じコンポーネントとみなすか？
- どこから先の「似ているけどちょっと違う」を別のコンポーネントとして実装すべきか？
- 例: リンクとボタンは同じコンポーネントとみなすか？
- どのようなユースケース（どのようなユーザーが、どのように使い、何を達成するか）でどのコンポーネントを使うべきか？
- 例: どのようなユースケースでボタンにするべきか？あるいは、ボタンにするべきでないか？
といった悩みが出てきます。Web フロントエンドでは、これらの悩みのいくつかは次のような標準的なガイドラインで解消できるかもしれません。
標準的なガイドラインのほかに、自分たちが開発する製品やサービスで定めるデザイン言語に基づいて、悩みに対する一定の方向性を明確にするというアプローチもあります。
このページでは、デザイン言語をどうやって整備していくのか、どうやって実装に反映していくのかについて紹介したいと思います。
デザインシステムとは？
デザイン言語（製品やサービスの見た目や印象を統一するための原則・ルールの集まり）を、いくつかの要素に体系化（システム化）したエコシステム（製品、サービス、デザインツール、企業ブランディング、組織などに相互に連携したありよう）です。
デザイン言語が「言語」を標榜している通り、その話し手である開発者、デザイナー、プロダクトオーナーなどの当事者同士で、共通の解釈や合意を形成するプロセスが重要です。そのため「これらがあればデザインシステムだ」という一般的で明確な定義というのはありませんが、次のような要素で構成されます。
- デザインプリンシプル（原則）: UI の設計や実装における指針です。どのような価値観のもと、設計や実装をおこなうかを定めます。
- デザイントークン: 色、効果、サイズなどのスケール（規格化された尺度）を定めます。
- デザインアセット: 再利用可能な画像、動画などのコンテンツを定めます。デザイントークンを参照して設計と実装をおこないます。
- コンポーネント: 再利用可能な見た目や振る舞いを定めます。デザイントークンを参照して設計と実装をおこないます。
- デザインガイドライン: 個別のデザイントークン、デザインアセット、コンポーネントの使い方に関する指針です。推奨される使い方、あるいは推奨されない使い方などを定めます。
デザインシステムはなぜ必要か
製品やサービスを開発していくにあたり、当事者の立場ごとに考えることは様々です。
- デザイナー: ユーザーが快適に使えるような（ユーザブルな） UI に設計できているか。好ましい印象を与えているか。
- 開発者: 優れたパフォーマンスを発揮できているか。保守性が保たれているか。可用性が保たれているか。
- プロダクトオーナー: 設定した顧客の課題が解決できているか。製品競争力があるか。プロダクトマーケットフィット（顧客が満足し、市場に受け入れられた状態）しているか。
立場で製品やサービスの目指していく方向がバラバラになっていけば、当事者間でコミュニケーションをとることが難しくなっていきます。デザインシステムを整備することで、当事者間で共通の認識を持って開発することができます。
また、認識を合わせる手段として、当事者間同士でのコミュニケーションに加えて、デザインシステムを参照することで、それぞれが自律的な意思決定をおこないやすくなります。具体的には、次のような効果が期待できます。
- デザイナー: デザイントークンを参照して設計意図を明確にできる。デザインガイドラインを参照してデザインレビュー（設計の品質が一定の基準を満たしているか批評すること）ができる。
- 開発者: デザインガイドラインを参照して開発中の機能に適切なコンポーネントが選定できる。デザイントークンを参照して統一的な見た目が実装できる。
- プロダクトオーナー: デザインプリンシプルを参照してブランドアイデンティティを保った顧客課題の解決策を提示できる。
事例
デザインシステムが実際に運用されている事例をいくつか紹介します。
行政での取り組み
日本企業での取り組み
デザインシステムを実装に反映する仕組み
現状はデザインシステムを文書化して参照するのが主な運用方法ですが、デザインシステムに基づいて効率的に開発を進めるための仕組みが徐々に整備されつつあります。
とくに、デザイントークンについては標準化のための取り組みが継続的におこわれており、実用段階になりました1。
Design Tokens ベース
- Design Tokens
- 標準化団体である W3C のコミュニティグループ Design Tokens Community Group が策定している仕様
- Style Dictionary
- Design Tokens Community Group の仕様と互換性のあるデザイントークンを反映するビルドシステム
- Tokens Studio
- Figma Design と連携してデザイントークンを実装に反映できるサービス
- Tokens Studio の開発者（jorenbroekema (Joren Broekema)）は Style Dictionary のコントリビューター（開発に貢献している開発者）でもある
Tailwind CSS ベース
Tailwind CSS を導入することで、デザイントークンを管理することができます。
デザインシステムを構築するための Tailwind CSS 活用について学びたい場合は、f_subalさんがTailwind CSS実践入門 | 技術評論社の刊行にあたり、寄稿された次の記事を参考にしていただけると思います。