5.2 UIデザインとデザインシステム

概要と動機

ユーザーインターフェース(UI)デザインとは、人々が見て触れるものを形づくる技芸です。レイアウト、タイポグラフィ、色、余白、コントロール、状態。デザインシステムは、その技芸を、共有され、再利用可能で、統治される資産に変えます。すべてのチームが引き出す、原則、コンポーネント、パターン、トークンの文書化された集合で、プロダクト全体が一つとして見え、振る舞うようにします。UIデザインは、一つの画面がどう見えるべきかを決めます。デザインシステムは、多くのチームにわたる一万の画面が、一貫して保たれる方法を決めます。

大きな組織にとって、デザインシステムは、UIの品質とデリバリーの速度への、単一で最もてこの効く投資です。それがなければ、すべてのチームがボタン、フォーム、モーダル、エラー処理を再発明し、それぞれが少しずつ異なり、別々に保守され、別々に壊れます。ユーザーはこれに混乱と不信で払い、ビジネスは重複した労力と不均一な品質で払います。デザインシステムは、一度きりのデザインの決定を、再利用可能な資本に変えます。アクセシビリティ、レスポンシブ性、ブランディングをコンポーネントで一度解決すれば、すべてのチームがその結果を引き継ぎます。

企業と政府は、二つの特有の圧力を加えます。第一に規模です。ベンダーが作ったり合併で取得したりした数百のアプリケーションが、すべて一つの組織のように感じられる必要があります。第二に寿命と変化です。ブランドは刷新され、機関は再編され、単一のプラットフォームが、一つのコードベースから複数のブランドや下位機関に仕える必要があるかもしれません。適切なテーマ設定とトークン化を伴う、よく設計されたデザインシステムは、これらの大規模な変更を、壊滅的ではなく扱いやすいものにします。

主要原則

一貫性は認知負荷を下げます。ボタンはどこでも同じに見え、同じに振る舞うべきです。
デザインの決定は資産です。再利用可能なコンポーネントとトークンとして一度だけ捉えます。
トークンは視覚的な決定の真実の源です。コンポーネントはトークンを使い、ハードコードされた値は決して使いません。
アクセシビリティとレスポンシブ性は、画面ごとに後付けされるのではなく、コンポーネントに組み込まれます。
デザインシステムは、一度きりの成果物ではなく、ユーザー(開発者とデザイナー)を持つプロダクトです。
視覚的な階層は注意を導きます。書体、色、空間が、重要性を明白にするべきです。
ガバナンスがシステムを一貫して保ち、貢献がそれを生かし続けます。

推奨事項

システムを層で構造化する: トークン、コンポーネント、パターン

デザイントークンは、色、余白、タイポグラフィ、角丸、高さ、モーションの、名前付きでプラットフォームに依存しない値で、原子的な決定です。階層で築きます。プリミティブなパレット(生の値)、意味を運ぶセマンティックトークン(color-action-primary、space-inset-md)、必要な所ではコンポーネントレベルのトークン。コンポーネントはセマンティックトークンを使うので、一つの変更があらゆる所に伝播します。コンポーネントの上にはパターンがあります。データテーブル、複数ステップのフォーム、空の状態のような、実証済みの構成。三つの層すべてを、ライブの例と使い方のガイダンスとともに、一か所に文書化します。

視覚の基礎を正しく整える

明確な階層と、読みやすさのための十分な行間を備えたタイポグラフィのスケールを設定し、サイズとウェイトの限られた集合に留めます。色を、UIに散らばる生の色相ではなく、アクセシビリティのための十分なコントラスト(アクセシビリティの章を参照)とセマンティックな役割を備えたシステムとして定義します。余白のスケールとレイアウトのグリッドを使い、画面ごとの当て推量なしに、整列とリズムが一貫するようにします。視覚的な階層は、主要な行動と最も重要な情報を、一目で明白にするべきです。

レスポンシブでモバイルファーストに設計する

最小の妥当なビューポートを最初に設計し、それから大きな画面向けに拡張します。これにより、本質的なコンテンツとコントロールに優先順位をつけざるをえなくなります。いくつかの固定ブレークポイントの間を切り替えるのではなく、流動的なレイアウトと相対単位を使い、インターフェースがどんな画面にも適応するようにします。タッチターゲットを十分大きくし、操作がタッチ、マウス、キーボードで機能するようにします。特に政府では、ユーザーのかなりの割合が、小さい、古い、あるいは低価格のデバイスを使っていると想定してください。

デザインから開発への引き継ぎとパリティを第一級の関心事にする

デザインシステムは、出荷されるUIが意図されたデザインに合い、合い続けるときにだけ元が取れます。単一の真実の源を目指します。デザインツールからエクスポートされたトークンが直接コードに流れ込み、デザイナーとエンジニアが同じ値を参照するようにします。デザインのコンポーネントと同じ名前とpropsを持つ、エンジニアが実際に使うコード化されたコンポーネントライブラリを提供します。ビジュアルリグレッションテスト(描画されたUIを承認済みのベースライン画像と自動で比較する)とデザインレビューのチェックを使い、ずれを捉えます。そして「デザインとコードのパリティ」を明示的な健全性の指標として測定します。システムのコンポーネントから築かれたUIと、一度きりのコードの割合です。

企業規模でのテーマ設定とホワイトラベル化をサポートする

必要になる可能性が少しでもあるなら、最初から複数のブランドを想定してアーキテクチャを設計します。コンポーネントがセマンティックトークンを使うので、テーマは単に異なるトークン値の集合であり、ブランドの刷新や新しい下位ブランドは、コードの書き直しではなくデータの変更になります。同じ仕組みで、ライトとダークのテーマ、ハイコントラストのモード、テナントごとのブランディングをサポートします。ブランド固有のロジックをコンポーネントから出し、代わりにトークンの集合と設定に押し込みます。

システムをプロダクトとして統治する

デザインシステムに、専任のチーム、ロードマップ、バージョニング、変更履歴、サポートの窓口を与えます。チームが新しいコンポーネントをどう貢献し、それがどうレビューされ昇格されるかを明確にします。(一貫性とアクセシビリティを保つ)中央の制御と、(システムがボトルネックにならず、実際のニーズに沿って進化するための)貢献のモデルのバランスをとります。非推奨と移行を明確に伝え、利用するチームに十分なリードタイムを与えます。

トレードオフ: 長所と短所

決定	長所	短所
デザインシステムを築く	一貫性、速度、アクセシビリティを一度で、容易な再ブランド	事前と継続的なコスト。専任のチームが必要
既製のシステムを採用する	速い開始。実証済みのパターン	汎用的な見た目。独自のブランドとニーズに合わせにくい
厳格な中央のガバナンス	一貫性、品質、アクセシビリティが保証される	チームのボトルネックになりうる。官僚的に感じられる
オープンな貢献モデル	実際のニーズに沿って進化。共有の当事者意識	レビューなしにずれと不整合のリスク
重いトークン化とテーマ設定	安い再ブランドとマルチブランドのサポート	抽象化が増える。学習曲線が急

デザインシステムは、事前とガバナンスのコストを、長期の一貫性と速度と交換します。一つのチームの小さなプロダクトでは、オーバーヘッドは元が取れないかもしれません。多くのチームと長寿命のプロダクトを持つ大きな組織では、問いはシステムを持つかどうかではなく、どれだけ投資し、どう統治するかです。最もよくある後悔は、ガバナンスとパリティのツールへの投資不足です。システムは紙の上に存在するが、チームは静かにそこから離れていきます。

チームで議論すべき問い

トークンのアーキテクチャはどう階層化され、コンポーネントはハードコードされた値の使用を禁じられていますか。 デザインシステムの見返りのすべて(安い再ブランド、マルチブランドのテーマ設定、一度で解決されるアクセシビリティ)は、コンポーネントが、コードに散らばる生の色相やピクセル値ではなく、color-action-primaryのようなセマンティックトークンを使うことにかかっています。階層を今決めてください。プリミティブなパレット、意味を運ぶセマンティックトークン、本当に必要な所だけのコンポーネントレベルのトークン。過度の抽象化は本物のリスクなので、何層が多すぎるか、開発者が適切なトークンをどう素早く見つけるかに合意してください。ずれの証拠として、コードベース全体のハードコードされた色と余白のgrepを持ち込んでください。ブランドのロジックがコンポーネントに焼き込まれていれば、再ブランドは設定の変更ではなくコードの書き直しになり、それはトークン化が防ぐために存在するまさに壊滅です。
デザインとコードのパリティをどう測定して守り、どんなツールが自動でずれを捉えますか。 デザインファイルとしてしか存在しないデザインシステムは、ステッカーシートです。エンジニアはとにかくすべてを再構築し、出荷されるUIは意図から静かに乖離します。明示的なパリティの指標(システムのコンポーネントから築かれたUIと一度きりのコードの割合)に合意し、ビジュアルリグレッションテストをCIに配線して、描画された画面が承認済みのベースラインと比較されるようにしてください。これは企業と政府の規模で重要です。ベンダーが作ったり合併で引き継いだりした数百のアプリケーションが、すべて一つの組織のように感じられる必要があるからです。現在のパリティの数字と、チームが再構築し続ける上位のオーダーメイドのコンポーネントの一覧を持ち込んでください。誰も指標やリグレッションのスイートを所有しないなら、ずれはすでに静かに勝っています。
システムがチームのボトルネックにも断片化の原因にもならないよう、貢献、非推奨、移行をどう統治しますか。 厳格な中央の制御は一貫性とアクセシビリティを保証しますが、デザインシステムのチームを、チームが回避するボトルネックにしかねず、オープンな貢献はシステムを生かし続けますが、レビューのない分岐した変種のリスクがあります。貢献の経路を決めてください。チームがどう新しいコンポーネントを提案し、誰がレビューし、どう昇格されるか。同じく、破壊的変更をどう伝えるかに合意してください。移行の支援とリードタイムのない非推奨は、利用するチームを停止させたりフォークさせたりするからです。システムの外でチームが築いたコンポーネントの例を持ち込み、なぜ貢献し返さなかったのかを問ってください。答えは通常、ガバナンスがサービスなのか障害なのかを明らかにします。
アクセシビリティがコンポーネントの中で一度解決されることをどう保証し、チームがアクセシブルでない一度きりのものを出荷するのを何が止めますか。デザインシステムの最も強い論拠は、色のコントラスト、フォーカスの状態、キーボード操作、スクリーンリーダーのセマンティクスが一度解決されてあらゆる所に引き継がれることですが、その約束は、チームが独自のコントロールを手作りした瞬間に崩れます。大きな組織では、ここに最大の法的および評判上のリスクがあります。たった一つのアクセシブルでない決済フォームや日付ピッカーが、実際のユーザーをブロックし、それをコピーしたすべてのプロダクトにわたって苦情を引き起こしえるからです。中央の徹底(アクセシブルなコンポーネントと、生のマークアップを拒否するリンターやレビューのゲート)をチームの自律と量り、固い線をどこに引くかを決めてください。アクセシビリティ監査の結果、適合状況を付したコンポーネントの一覧、システムの外でチームが再構築したオーダーメイドのコントロールの数を持ち込んでください。企業と政府の設定では、これは礼儀ではありません。WCAG、Section 508、EN 301 549のような義務が適合を調達と監査の要件にするので、文書化された適合を備えたコンポーネントライブラリは、それ自体がコンプライアンスの資産です。
このシステムは、いくつのブランド、テナント、テーマに仕えなければならず、後で後付けするのではなく、今それに向けてトークンの層を設計しましたか。テーマ設定は、設計していれば安く、していなければ過酷です。想定されなかったブランドやテナントは、ブランドのロジックをコンポーネントに戻させ、トークン化の目的全体を元に戻すからです。大きなチームにとって、この決定は何年もの仕事を形づくります。複数のブランド、ライトとダークのテーマ、ハイコントラストのモード、テナントごとのブランディングに仕えなければならないプラットフォームには、テーマが単に異なる値の集合になるくらい、きれいなセマンティックトークンの層が必要です。その柔軟性を過度の抽象化と量ってください。誰もナビゲートできないトークンの木は、それ自体の失敗だからです。予見できるブランドとテナントのロードマップ、今使われているテーマの数、すでにブランド固有のロジックを漏らしているコンポーネントを持ち込んでください。企業と政府の文脈では、合併、買収、機関の再編が、計画しなかったブランドを日常的に加えるので、最初からマルチブランドのために設計することが、データの変更と数年の書き直しの違いです。
レガシーとベンダーが作ったアプリケーションをシステムにどう移行し、デザインシステムのチームは次の予算サイクルを生き延びるようどう資金を出されますか。デザインシステムは、実際のプロダクトが採用したときにだけ見返りをもたらしますが、変換が最も難しいアプリケーションは、それを最も必要とする古いものや外注されたものであり、システムを保守するチームは、予算が引き締まるとしばしば最初に切られます。大きな組織では、ビッグバンの移行と段階的な移行のどちらにするか、ベンダーに、あなたのコンポーネントを避けるのではなくその上に築かせる方法を決めなければなりません。現在のパリティのスコアを付したアプリケーションの目録、アプリケーションごとの移行の労力の見積もり、ベンダーに対して持つ契約上のてこを持ち込んでください。企業と政府の設定では、デザインシステムへの適合を調達の条件に書き込み、新しいベンダーの仕事が既定でシステムの上に着地するようにし、保守するチームを、永続する共有のインフラストラクチャとして資金を出してください。再編でそのスチュワードを失うシステムは、一年以内に断片化へと漂い戻るからです。

セクター別の視点

スタートアップ。 二、三人のエンジニアで猶予がないなら、統治されたシステムは築かないでください。色、余白、書体のセマンティックトークンの小さな集合と、十数個の共有コンポーネントを、チーム全体が参照する一つのファイルに、一、二日かけて定義してください。難しい部分は既製のプリミティブライブラリに頼り、何もハードコードしないので、最初の本物の再ブランドが書き直しではなくトークンの変更になります。

小規模事業者。 専任のデザイナーがおらず予算も厳しいので、築くのではなく買ってください。実証済みのコンポーネントライブラリやUIキットを採用し、ブランドに合わせて軽くテーマ設定します。目標は、デザインシステムのチームに人員を置かずに、一貫してアクセシブルなプロダクトを得ることなので、アクセシビリティとレスポンシブ性を最初から備えたシステムを好んでください。フォークしたい衝動に抵抗してください。保守できないカスタマイズ版のコピーは、上流のプロジェクトが先に進んだ瞬間に負債になるからです。

大企業。 問題は、多くのチームと長寿命のプロダクトにわたる一貫性なので、デザインシステムを、専任のチーム、バージョニング、ロードマップを持つ、統治される共有インフラストラクチャとして扱ってください。デザインとコードのパリティを本物の指標として追跡し、ビジュアルリグレッションテストをCIに配線し、最初から複数のブランドとテーマのためにトークンの層を設計します。ガバナンスと移行のコストを明示的に予算化し、チームが自力でシステムへ漂ってくると想定せず、採用をポートフォリオとして管理します。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。WCAG、Section 508、EN 301 549のような標準へのアクセシビリティの適合は、好みではなく法的要件なので、文書化された適合を備えたコンポーネントライブラリは、コンプライアンスの資産になります。市民がサービスをまたいで同じパターンに出会うよう、共有の公共のデザインシステムを好むか拡張し、デザインシステムの利用をベンダーの契約に書き込み、機関とその供給者が採用し、責任を課せられるよう、コンポーネントとガイダンスをオープンに公開してください。

事例

スタートアップ。 2人のエンジニアのスタートアップは、新しい画面ごとにボタンとフォームの項目を少しずつ違う形で再構築し続け、プロダクトはつぎはぎに見え始めていました。重いシステムの代わりに、色、余白、書体のセマンティックなデザイントークンの小さな集合と、約十数個の共有コンポーネントを、チーム全体が参照する一つのファイルに定義するのに二日を使いました。何もハードコードされていなかったので、最初のデザイン志向の採用者がより洗練されたパレットを提案したとき、刷新は画面ごとの苦行ではなく、午後のうちにアプリ全体に着地するトークンの変更でした。

大企業。 数十のプロダクトチームを持つ世界的なソフトウェア企業は、共有のコード化されたコンポーネントライブラリを伴うトークン化されたデザインシステムを築きました。セマンティックトークンにより、変更が何千ものハードコードされた色の編集ではなく新しいトークンの集合だったので、チームごとの数年の苦行ではなく、数週間ですべてのプロダクトにわたる完全なブランドの刷新を出荷できました。ダッシュボードの指標として追跡されたデザインとコードのパリティは、チームがオーダーメイドのコンポーネントを置き換えるにつれて上がり、重複したUIの保守を削りました。

政府。 ある国の政府は、公共サービスのための共通のデザインシステム(共有のコンポーネント、パターン、組み込みのアクセシビリティ)を作り、機関にわたって義務づけました。税のサービス、医療のサービス、免許のサービスの間を移る市民は、同じヘッダー、フォームのコントロール、エラーのパターンに出会い、それが信頼を築き、学習曲線を短くします。難しい問題が中央で解決されるので、機関とそのベンダーはより速く、よりアクセシブルに出荷し、政府はガイダンスやアクセシビリティの修正を一度更新するだけで、あらゆる所に伝播させられます。

ビジネスケース: 動機、ROI、TCO

デザインシステムのROIは、重複の除去とデリバリーの加速から来ます。すべてのチームが同じコンポーネントを設計し築く代わりに、共有のライブラリから構成するので、デリバリーが測定可能に速くなり、デザイナーとエンジニアがプロダクト固有の仕事に解放されます。コンポーネントで一度解決されたアクセシビリティとレスポンシブ性は、プロジェクトごとの是正のコストを節約します。かつて数年かかった再ブランドとテーマ設定が、数週間で済みます。

TCOでは、採用のコストは、専任のチーム、ツール、既存のプロダクトがシステムに移行する労力です。採用しないコストは継続的に払われます。チーム間の重複した構築と保守、サポートと法的リスクを生む一貫せずアクセシブルでないUI、遅く高価な再ブランド。重複は多くのチームの予算に散らばっているので、見落としやすいのですが、デザインシステムはその隠れたコストを可視にし、一か所に捉えます。

リーダーシップに論拠を示すには、チーム間の重複したコンポーネントの作業、構成によるマーケットへの投入時間の利得、最後の再ブランドのコストと期間を、トークン化されたシステムが許すものと対比して定量化します。システムを、測定可能な採用の指標(パリティの割合)を持つ共有インフラストラクチャとして枠づけ、その価値が、単に主張されるのではなく、時間とともに追跡できるようにします。

アンチパターンと落とし穴

ステッカーシートとしてのデザインシステム: コード化されたコンポーネントのない静的なデザインファイルで、エンジニアがとにかくすべてを再構築すること。
あらゆる所のハードコードされた値: コードに散らばる色と余白で、テーマ設定と再ブランドを不可能にすること。
ガバナンスがない: チームが分岐した変種を加えるにつれてシステムが断片化し、一貫性が侵食されること。
貢献のないガバナンス: 中央のチームがボトルネックになり、チームがそれを回避すること。
パリティの無視: コード化されたUIがデザインの意図から乖離し、誰もそのギャップを測らないこと。
過度の抽象化: あまりに多くのトークンと層で、誰も適切なものを見つけたり使ったりできないこと。
コンポーネントに焼き込まれたブランドのロジック: マルチブランドとテーマ設定を、設定の変更ではなくコードの書き直しにすること。
移行の支援のない破壊的変更: 利用するチームが停止したり、システムをフォークしたりすること。

成熟度モデル

レベル1: 開始。 各チームが自分のUIをその場しのぎで反応的に築きます。共有のコンポーネントはなく、見た目と振る舞いは一貫せず、色と余白は画面ごとにハードコードされます。すべての再ブランドが、手作業の画面ごとの苦行です。

レベル2: 発展。 共有のスタイルガイドやコンポーネントライブラリは存在しますが、部分的で任意で、デザインとコードの間でしばしば同期が取れていません。使うチームもあれば使わないチームもあり、基本的な実践はチームごとに大きく異なります。

レベル3: 標準化。 保守されるコード化されたライブラリ、文書、ガバナンスを備えたトークン化されたデザインシステムが、文書化され、組織全体で徹底されています。コンポーネントはセマンティックトークンを使い、テーマ設定がサポートされ、アクセシビリティとレスポンシブ性は、画面ごとに後付けされるのではなく組み込まれています。

レベル4: 管理。 システムが、ベースラインに対するデータで測定され、制御されています。デザインとコードのパリティはプロダクトごとの目標を備えた明示的な指標として追跡され、ビジュアルリグレッションテストがCIで走ってずれを捉え、アクセシビリティの適合は想定されるのではなく標準に対して測定されます。採用のダッシュボードがチームごとのコンポーネントのカバレッジを示し、再ブランドのコストと期間が記録されるので、改善が時間とともに見えます。

レベル5: オーケストレーション。 デザインシステムは、組織全体に統合され、変化に適応する、継続的に改善されるプロダクトです。バージョニング、ロードマップ、機能する貢献のモデルを持つので、実際のニーズに沿って進化します。再ブランドと新しいテーマは日常的なトークンの変更で、マルチブランドとマルチテナントのテーマ設定は普通であり、チームは使用データの証拠に基づいてパターンを退役させ、再スコープし、昇格させて、単一の真実の源からデザインツールとデリバリーのパイプラインに供給します。

議論のためのアイデア

断片化もボトルネックも起こさずに、中央のガバナンスとチームの自律をどうバランスさせますか。
「デザインとコードのパリティ」の正しい指標は何で、それをどう誠実に保ちますか。
チームがシステムを使う代わりに一度きりのコンポーネントを築くことを許されるのは、どんなときですか。
予算サイクルと再編を生き延びるよう、デザインシステムにどう資金を出し人員を置きますか。
追加の抽象化のコストに見合う、テーマ設定の柔軟性はどれくらいですか。
レガシーとベンダーが作ったアプリケーションを、共有のシステムにどう移行しますか。

要点

デザインシステムは、一度きりのデザインの決定を、再利用可能で統治される資本に変えます。
層(トークン、コンポーネント、パターン)で構造化し、コンポーネントはセマンティックトークンを使います。
アクセシビリティとレスポンシブ性をコンポーネントに組み込み、すべてのチームが引き継げるようにします。
デザインとコードのパリティを、想定ではなく、測定可能な健全性の指標として扱います。
トークン化により、再ブランドとマルチブランドのテーマ設定は、書き直しではなくデータの変更になります。
ロードマップ、バージョニング、貢献のモデルを持つプロダクトとして、システムを統治します。
企業と政府の規模では、共有のシステムは利用できる最もてこの効くUIへの投資です。

参考文献とさらなる読み物

Brad Frost, Atomic Design
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages
Josef Müller-Brockmann, Grid Systems in Graphic Design
Robert Bringhurst, The Elements of Typographic Style
Ellen Lupton, Thinking with Type
Luke Wroblewski, Mobile First
Ethan Marcotte, Responsive Web Design
Nathan Curtis, writings on design tokens and design system governance
W3C Design Tokens Community Group, format specification
Government design systems (e.g., UK Government Design System, U.S. Web Design System) as reference implementations