デザインシステム

何が実体で、何が文書の中だけにあるのか

デザインシステムの説明はたいてい成果物の一覧です。トークン、コンポーネント、パターン、ドキュメント。この一覧は正確であり、同時に少し誤解を招きます。あなたが「作るもの」を述べているだけで、「なぜ機能するのか」を述べていないからです。どの層にも2つの版があります。書かれている版と、破ろうとすると実際に何かが止めてくれる版です。

• トークン — 色・タイポグラフィ・余白・角丸に名前を付けた値。強制がなければ、人がカラーコードをコピーしていくだけのパレットになります。
• コンポーネント — 繰り返し現れる要素の唯一の実装。強制がなければ、手作りの派生が十数個並ぶ横に置かれた見本フォルダになります。
• パターン — ページヘッダーや空状態のような繰り返す仕事に対して、コンポーネントをどう組み合わせるか。強制がなければ、すべてのページが同じ問題を別々に解きます。
• ドキュメント — 理由と、ルールをあえて適用しない場合の説明。強制がなければ、最初の1週間を過ぎたら誰も開かないサイトになります。

この区別が最も痛いのは小さなチームです。そこではシステムがたいてい一人の記憶だからです。記憶は大きな音を立てて壊れません。ドリフトとして壊れます — 同じ見出しが5つのサイズになり、同じボタンが3つの太さになる — そして一つひとつを取り出せば、どれも弁護できてしまいます。

誰も気づかない失敗、効いていないルール

自社プロダクトの例を挙げます。この項目が存在する理由そのものです。私たちのディスプレイ書体は、ウェイトがちょうど1つしかありません。グローバルなルールがすべての見出しをウェイト500に設定していましたが、それは何もしていませんでした。CSSのウェイトマッチングは、500という要求を、そのフォントが実際に持つ唯一のウェイトへ解決し直すからです。宣言は存在し、もっともらしく、そして無効でした。高くついたのは回避策のほうです。その書体を使っていた223か所のうちおよそ180か所が、はじめから効いていなかった宣言を「直す」ためにウェイト400を手書きしており、同じ画面群は44種類の異なるフォントサイズへとドリフトしていました。

これらは型チェッカーには何も見えません。どの派生も妥当なスタイルオブジェクトだからです。レビューでもほとんど見えません。差分は1行ずつで、1行ずつなら弁護できるからです。修理は化粧ではなく構造でした — ページ見出しのサイズを書いてよい場所をただ1つのコンポーネントに集約し、ページが独自に手書きしたらビルドが落ちるテストを置いたのです。そのテストこそがデザインシステムです。トークンは、はじめからその記述にすぎませんでした。

小さなチームに実際に必要なもの

• テンプレートからではなく、繰り返しから始める。 名前を付ける価値のあるプリミティブは、すでに3回打ち直したものです。それ以外は、維持するだけで一度も使わない在庫です。
• ルールは読まれる場所ではなく、効く場所に置く。 共有コンポーネント、lintルール、落ちるテストは、wikiのページより強い。急ぎの金曜日を生き延びるのは前者だけだからです。
• 変更は単体ではなく合成で判断する。 ウェイトやサイズは単体では良く見え、バッジ・テーブルヘッダー・本文の太字と並ぶと崩れます。それらを全部載せた実画面を描いてください。
• 何もできない宣言に注意する。 フォントやフレームワーク、あるいはコンテンツセキュリティポリシーが尊重できない対象を指すトークンは、無いよりも悪い。解決済みのように読めてしまうからです。
• システムはプロダクトの境界で止めてよい。 マーケティングページとプロダクトUIは別のタイポグラフィを求めることが多く、片方に限定して上書きするのは判断です。グローバルの既定値をうっかり反転させるのは判断ではありません。

インターフェースをAIが書いているなら、これはむしろ重要度が増します。モデルは何かが範囲を狭めない限り中央値へ寄るからで、UI UX Pro Maxのようなデザインルールのパックが埋めようとしているのは、まさにその隙間です。一貫性は、誰かが判断している最中のページにおいて最も安価な信頼の作り方でもあります — Core Web Vitalsとコンバージョンの改善が同じ月に持ち上がりがちなのと同じ理由です。