デザインシステムを作ったのに、制作の現場で使われていない。何を共通の基準とし、誰が更新するかが曖昧なままでは、使われない理由も確かめにくくなります。
説明が割れているのには理由があります。デザインシステムという語は、作る対象の名前としても、続ける仕組みの名前としても使われています。公開されているデザインシステムを並べても、何を構成要素に数えるかは揃いません。どれかが誤りというわけではありません。
共通している部分と、割れている部分は分けて見た方が早い。
デザインシステムとは何か
デザインシステムは、プロダクトのデザインを大規模に扱うための基準を、参照先1つにまとめたものです。NN/g は「再利用可能な要素を使ってデザインを大規模に管理するための基準の完全なセット」と定義しています。UXPin は「原則・ガイドライン・コンポーネント・トークン・ドキュメントを統合した包括的で単一の情報源」という言い方をします。
日本語で読める公的な定義には、デジタル庁のデザインシステム（DADS）があります。ブランドやコミュニケーションの価値観を指針化したデザインプリンシプル、情報アーキテクチャとインタラクションデザインに基づくコンポーネント定義、アクセシビリティを含む規範となるデザインガイドライン。これらを含むデザインアセットの集合体とされ、単なる規約ではなくアクセシビリティと組み合わさった仕組みだと書かれています。
ここまでは、再利用する基準や要素をまとめて参照できるようにする点でおおむね揃っています。一方、トークンを独立した構成要素として挙げるかは出典によって違います。
スタイルガイドとは何が違うのか
スタイルガイドはデザインシステムより狭く、その内側に置かれます。NN/g は両者を親子関係として整理し、スタイルガイドを「特定の実装ガイドラインを含む1つのドキュメント」と位置づけています。デザインシステムが基準の集合で、スタイルガイドはそのうちの1冊、という関係です。
ただし、そのスタイルガイドがどこまでを含むかで説明が分かれます。NN/g はスタイルガイドを「コンテンツ」「ブランド」「フロントエンド」の3種に分け、コピーのトーンもその範囲に入れています。日本語の解説記事では、色・フォント・余白といった視覚要素に限定して説明するものが目立ちます。「スタイルガイドはあります」という言葉が、見た目のルールだけを指すのか、文言の書き方まで含むのかは、聞き返さないと分かりません。
別の用法もあります。デジタル庁 DADS は「ローカルデザインシステム（スタイルガイド）」を、共通基盤を個々のサイトやサービスの要件に合わせて定義したデザイン仕様と説明します。導入先に合わせてデザイントークンを編集し、使うコンポーネントを選び、ブランドに関する規定を加える形です。この用法では、スタイルガイドは共通基盤を導入先に合わせた仕様になります。
UIキットとコンポーネントライブラリ
UIキットを Figma などのデザインツール上のパーツ素材集に限る説明があります。一方、Goodpatch は「ユーザーインタフェースキット」にデザインファイル内のライブラリと開発用のコンポーネントライブラリの両方を含めます。UXPin は、スタイルガイド、パターンライブラリ、コンポーネントライブラリをデザインシステムの部分集合として並べています。
「UIキット」という名前だけで実装から呼び出せるかは判断できません。デザインファイル内の素材と、コードとして配られる部品のどちらがあるかを確認します。
構成要素として何を説明しているか
公開されているデザインシステムと提唱者の説明では、取り上げる範囲が異なります。以下は各出典が説明している内容であり、必要な要素の数を決める表ではありません。
| 出典 | 出典が説明している範囲 |
|---|---|
| Atlassian Design System | 基盤の説明にデザイントークン、ガイドライン、ビジュアルスタイルを含め、コンポーネントなども別に案内する |
| GOV.UK Design System | 公開サイトの主要項目としてスタイル、コンポーネント、パターンを案内する。政府のデザイン原則は別に、従う考え方として示す |
| デジタル庁 DADS | デザインプリンシプル、コンポーネント定義、デザインガイドラインなどをデザインアセットの例として挙げる |
| Goodpatch | 原則、ブランドガイドライン、ユーザーインタフェースガイドライン、ユーザーインタフェースキットの4要素 |
| Nathan Curtis（2017年） | 再利用可能なパーツのキット、まとまりのある複数プロダクト、協働するコミュニティの3層 |
このうち、デザイントークンの名前の階層と、定義をデザインツールと実装のどこに置くかはデザイントークンとは何かで整理しています。
性格がいちばん違うのは Nathan Curtis の3層です。2017年10月10日の記事で、デザインシステムを「再利用可能で相互接続されたパーツのキット」「まとまりのある相互接続された複数プロダクト」「協働する相互接続されたコミュニティ」の3つの相互関連するシステムとして定義しました。他の説明では構成要素に入ってこない人と組織が、ここでは要素そのものに含まれています。
正解を1つ選ぶ話ではありません。説明する範囲と粒度が違います。社内で「デザインシステムを作る」と言うときは、どの基準や部品を扱い、誰が使い続けるかを揃えておくと、完成範囲の認識がずれにくくなります。
成果物として見るか、運用として見るか
作る対象として見る
- 原則、ガイドライン、再利用できる部品などを共有する
- スタイルガイドは、出典によって部分集合にも、サービス固有の派生仕様にもなる
続ける仕組みとして見る
- 「デザインシステムは組織を表したもの」（Goodpatch）
- 使い手の声を集め、必要に応じて基準や部品を更新する運用も含む
機能しているかをどう見分けるか
公開されている運用例には、確認の入口があります。デジタル庁 DADS は継続的な研究と改善を掲げ、GOV.UK Design System は利用者調査、フィードバック、変更提案の窓口を示しています。部品を使う現場からの指摘がどこに届き、誰が改訂を判断するかまで追えると、ドキュメントの有無だけでは見えない運用を確かめられます。
Nue はプロダクトを週次でクロールして、UX、UI品質、デザインシステムからの逸脱、アクセシビリティ、コピー、コンバージョンの阻害要因の6観点でレビューします。コントラスト比、代替テキストの有無、デザイントークンからの逸脱のように機械で判定できる項目は自動化し、UXの妥当性は人が見ます。
検査項目を決めるときは、既存の基準から形式化できるものを選び、基準が無い項目は確認方法を定めます。これはデザインシステム全体の運用状況を判定する手順ではなく、週次レビューの検査範囲を決めるための整理です。
「デザインシステムがあります」という自己申告だけでは、運用状況は分かりません。実際の画面で共有部品が使われているか、使いにくい点が集まっているか、更新の担当が決まっているかを確認します。
AIエージェントにデザインを作らせる場面でも、見分け方の軸は同じです。制約と検証をエージェント向けに体系立てたものはデザインハーネスと呼ばれ、検証層を運用し続けたときに何が起きるかは別記事にまとめています。
検査項目と人が確認するUXの範囲は、プロダクト開発支援に示しています。
守られなくなるのはどこからか
形骸化の理由として挙げられるのは、作った後の扱いです。Goodpatch は、他組織の完成度の高いデザインシステムをそのまま流用すると組織との乖離が生まれること、厳格なルールとして定めておきながら運用を怠ることを、失敗の要因として説明しています。
ドキュメントがあっても使われていないなら、参照されない理由を使い手に聞きます。形式化したルールに逸脱が出ているなら、検査結果を見て修正の順番を決めます。利用者の課題に合わなくなった部品なら、調査結果を踏まえて基準そのものを見直します。原因によって次の一手は変わります。
作ったものが使われないという形は、デザインシステムに限りません。生成AIのPoCが本番に行かないで書いたのも、精度ではなく置き場所が無いまま作られている、という話でした。
作らない方がいい場合
1つは、他社の完成度の高いデザインシステムを持ってきて自社に当てる場合です。この進め方は失敗の要因に挙げられています。参照するのと、そのまま使うのは別です。
規模の面では、Nathan Curtis の定義が「まとまりのある複数プロダクト」を構成要素に含んでいることが手がかりになります。複数のプロダクトや画面をまたいで同じ判断を繰り返している状態が、この定義の前提として置かれていると読めます。
何画面から必要になるか、という線引きを数字で置くのは難しい。プロダクトの複雑さと、同じ判断を繰り返している回数で変わります。
代わりに、共通の部品や基準を誰が維持し、使い手の指摘をどう受けて更新するかを決められるかが判断材料になります。形式化できる項目の検査も、その運用に組み込みます。