デザインシステム：なぜほとんどが失敗し、機能するシステムを構築する方法

ある程度の規模に達したチームは、最終的に皆同じことを言います。「デザインシステムが必要だ」と。しかし、そのほとんどは半年かけて誰も使わないシステムを構築し、1年後には元の矛盾だらけの状態に戻ってしまいます。

問題は決してコンポーネントではありません。問題は、デザインシステムをプロジェクトとして扱い、製品として扱わないことです。プロジェクトは終わりますが、製品は進化します。進化を止めたデザインシステムは、リリースされたその日から死に始めます。

デザインシステムとは何か

デザインシステムはコンポーネントライブラリではありません。コンポーネントライブラリは再利用可能なUI部品のフォルダです。デザインシステムは、製品がどのように設計され、構築されるかを管理する標準、ドキュメント、ツールの完全なセットです。

これには以下が含まれます。

• [デザイントークン](/paper/glossary/design-tokens)。 他のすべてが参照する原子的な値（色、間隔、タイポグラフィ、影）。
• コンポーネント。 トークンから構築された再利用可能なUI要素。
• パターン。 繰り返し発生するデザインの問題（フォーム、ナビゲーション、エラー状態）に対する文書化された解決策。
• ガイドライン。 各部品をいつ、どのように使用するかに関するルール。
• ガバナンス。 システムの所有者、変更の提案方法、意思決定方法。

これらのいずれかを欠くと、部分的なシステムになってしまいます。部分的なシステムは部分的な採用しか生み出しません。部分的な採用は、解決しようとしていたのと同じ矛盾を生み出します。

ほとんどのデザインシステムが失敗する理由

失敗1：孤立して構築される。 小規模なチームが3ヶ月間姿を消し、美しいシステムを構築し、何の意見も出していない組織に提示します。システムは構築者の仮定を反映しており、ユーザーの現実を反映していません。採用は最初は丁寧に行われますが、その後静かに放棄されます。

失敗2：早すぎる硬直性。 システムはあらゆるシナリオに対して厳格なルールでリリースされます。システムが予期しなかったケースに遭遇したデザイナーやエンジニアには、2つの選択肢があります。システムと戦うか、回避策を講じるかです。ほとんどの人は回避策を選びます。システムは誰も参照しない参照物になってしまいます。

失敗3：専任の所有者がいない。 システムはスプリント中に構築されました。誰もメンテナンスを担当していません。トークンはコードベースから乖離し、コンポーネントは製品に追いつかなくなります。ドキュメントは古くなります。半年後、システムは昨年の製品の姿を映し出すスナップショットになってしまいます。

失敗4：コンポーネント優先の思考。 チームは、1つのトークンを定義したり、1つのガイドラインを書いたりする前に、47個のコンポーネントを構築します。コンポーネントはFigmaファイルでは機能しますが、基盤となる値が体系化されていないため、本番環境では壊れてしまいます。

失敗5：完璧主義による麻痺。 チームは何もリリースする前にあらゆるエッジケースを解決しようとします。システムは決して出荷されません。その間、製品は毎日システムなしで出荷されています。

生き残るシステムに共通すること

実際に長続きするシステム（Shopify Polaris、Atlassian Design System、IBM Carbon、GitHub Primer）を研究した結果、3つのパターンが浮かび上がりました。

小さく始めて成長した。 どのシステムも200個のコンポーネントでリリースされたわけではありません。トークン、少数のコアコンポーネント、そして明確なドキュメントでリリースされました。その後、理論的な完全性ではなく、実際の製品ニーズに基づいて拡張していきました。

専任のチームがいる。 一人ではありません。チームです。大規模なデザインシステムには、最低でもデザイナー、エンジニア、ドキュメントライター、プロダクトオーナーが必要です。Shopifyでは、Polarisに数十人が携わっています。数十人は必要ありませんが、ゼロよりは多く必要です。

貢献を機能として扱う。 最高のシステムは、製品チームが追加を提案したり、問題を指摘したり、コンポーネントを貢献したりすることを容易にします。システムは中心だけでなく、端からも成長します。一つのチームの決定だけで成長するシステムは、常に製品に遅れをとるでしょう。

デザイントークンこそが真の基盤

トークンは、他のすべてが継承するプリミティブな値です。トークンを変更すると、それを参照するすべてのコンポーネントが自動的に更新されます。これが、コレクションではなくシステムをシステムたらしめるものです。

トークンのレベル：

グローバルトークンは生の値を定義します。セマンティックトークンは意味（プライマリ、デンジャー、サーフェス）を割り当てます。コンポーネントトークンは、それらの意味を特定のUI要素にバインドします。この3層構造により、単一のコンポーネントに触れることなく、セマンティックトークンを変更するだけでブランドを再構築できます。

最初に定義すべきトークンの種類：

• 色（背景、テキスト、ボーダー、インタラクティブな状態）
• 間隔（4pxグリッド：4, 8, 12, 16, 24, 32, 48, 64）
• タイポグラフィ（フォントファミリー、サイズスケール、ウェイト、行の高さ）
• ボーダーラディウス（なし、小、中、大、全）
• 影（エレベーションレベル）
• モーション（期間、イージングカーブ）

他に何も定義しないとしても、これらは定義してください。これらはチームが日常的に行う視覚的決定の90%をカバーします。

長く使えるコンポーネントを構築する

トークンに基づいて構築されたコンポーネントは、ハードコードされた値に基づいて構築されたコンポーネントよりも本質的に回復力があります。しかし、トークンベースのコンポーネントでさえ、誤って構築されると失敗します。

生き残るコンポーネントのルール：

設定よりも構成。 14個のプロパティを持つボタンは柔軟ではありません。それは脆弱です。すべてのバリアントをプロパティで処理するメガコンポーネントを構築する代わりに、パターンに結合する小さな構成可能な部品を構築してください。カードは1つのコンポーネントではありません。それはカードコンテナ、カードヘッダー、カードボディ、カードフッターが組み合わさったものです。

状態はオプションではない。 すべてのインタラクティブなコンポーネントには、デフォルト、ホバー、アクティブ、フォーカス、無効、ローディング、エラーの状態が必要です。これら7つの状態すべてなしでコンポーネントを出荷すると、誰かがそれらの状態をアドホックに構築することになり、一致しなくなります。

「何」だけでなく「いつ」を文書化する。 ボタンのドキュメントは、それがどのように見えるかを示すだけでなく、プライマリボタン、セカンダリボタン、ゴーストボタンをいつ使用すべきかを記述する必要があります。視覚的な参照よりも意思決定フレームワークが重要です。

パターンはコンポーネントでは解決できない問題を解決する

ドロップダウンコンポーネントは、ドロップダウンがどのように見えるかを教えてくれます。しかし、ドロップダウン、ラジオグループ、セグメント化されたコントロールのどれをいつ使用すべきかは教えてくれません。その決定はパターンです。

早期に文書化すべきパターン：

• フォームレイアウト。 ラベルの配置、エラー表示、必須フィールドの表示、複数ステップのフロー。
• ナビゲーション。 タブ、サイドバー、パンくずリストのどれをいつ使用するか。モバイルナビゲーションの折りたたみ動作。
• 空の状態。 データがない場合に何を表示するか。イラスト？CTA？教育コンテンツ？
• ローディング状態。 スケルトンスクリーン、スピナー、プログレッシブローディング。それぞれがいつ適切か。
• エラー処理。 インラインバリデーション、トースト通知、全ページエラー状態。

これらのパターンは、システムを持たないチームを悩ませる「同じフォームを5つの異なる方法で構築してしまった」という問題を防止します。

ガバナンスが採用を左右する

ガバナンスのないデザインシステムは提案に過ぎません。ガバナンスは3つの質問に答えます。

1. 誰が決定するのか？ レビューボードがあるのか？単一の所有者か？民主的な投票か？何を選ぶにしても、それを明確にしてください。
2. 変更はどのように行われるのか？ RFCプロセスか？GitHubのIssueか？Slackのスレッドか？「新しいコンポーネントが必要だと思う」から「システムに組み込まれた」までの経路を定義してください。
3. バージョン管理戦略は何か？ トークンパッケージのセマンティックバージョニングか？リリースごとの変更履歴か？破壊的変更ポリシーか？

ガバナンスをスキップするチームは、最終的にフォークしたシステムに行き着きます。デザインはバージョン2.3を使用し、エンジニアリングはバージョン1.8を使用します。マーケティングサイトはローカルオーバーライドでバージョン2.0を使用します。その時点で、3つのデザインシステムがあり、一貫性はゼロです。

よくある質問

デザインシステムの構築にはどのくらい時間がかかりますか？

最初の基盤（トークン、10〜15個のコアコンポーネント、基本的なドキュメント）は、専任チームで2〜4ヶ月かかります。しかし、デザインシステムは決して「完成」することはありません。デザインエンジニアリングチームの能力の15〜25%を継続的に投資する計画を立ててください。

小規模チームでもデザインシステムは必要ですか？

はい、しかし規模に応じたものです。3人チームにPolarisは必要ありません。トークン、8〜10個のコアコンポーネント、そして1ページの意思決定ガイドを備えた共有Figmaライブラリが必要です。最も困っていること（通常は一貫性のない間隔と色の使用）から始めて、そこから成長させてください。

デザインシステムとコンポーネントライブラリの違いは何ですか？

コンポーネントライブラリは再利用可能なUI要素のコレクションです。デザインシステムには、コンポーネントライブラリに加えて、デザイントークン、使用ガイドライン、パターン、ドキュメント、ガバナンスが含まれます。ライブラリはシステムの一つの層に過ぎません。

野心ではなく、課題から始める

プロフェッショナルに聞こえるからといってデザインシステムを構築しないでください。チームが同じ問題を繰り返し解決するのに時間を無駄にしているからこそ、構築してください。今最も一貫性のない原因となっている3つのことから始めましょう。それらを体系化し、出荷します。その後、ケーススタディで印象的に見えるものではなく、チームが次に求めるものに基づいて拡張してください。