デザインシステムを形骸化させない：デザイントークンの3層構造と柔軟性の設計原則
プロダクトの成長とともに開発の効率化とUIの一貫性を支える強力なツールとなる「デザインシステム」。しかし、多くのプロジェクトにおいて「せっかく作ったシステムが現場の要件に合わず、使われなくなってしまった（形骸化）」という課題が頻発しています。
使いやすく、持続可能なシステムにするための鍵は、UIの最小単位である「色」や「余白」を管理する「デザイントークン」の設計と、コンポーネントの「一貫性」と「柔軟性」の絶妙なバランスにあります。今回はUIデザイナーの視点から、形骸化させないための実践的な設計原則を解き明かします。
出典: デザイントークンを形骸化させない「3層構造」の重要性
デザイントークンとは、ブランドカラー、余白、タイポグラフィ、角丸（Border Radius）などのデザインの決定事項を、プログラムで扱える「名前付きの値（変数）」として定義したものです。
よくある失敗は、color-brand: #4c6ef5 のような変数を直接コンポーネントで使ってしまうことです。これでは、ブランドカラーを少し変更したいときや、ダークモード対応が必要になった際に、すべてのコンポーネントの定義を書き換えなければならず、デザインシステムの本質である「一元管理」が崩壊します。
この問題を解決するのが、デザイントークンの**「3層レイヤー構造」**です。
- グローバル・トークン（Global Tokens / Reference）
システムで使用するすべての値のプールです。コンテキストに依存しません。
- 例:
color-blue-500: #4c6ef5,space-16: 16px
- 例:
- エイリアス・トークン（Alias Tokens / Semantic）
グローバル・トークンを参照し、「どう使われるか（役割・意味）」を定義します。
- 例:
color-action-primary: color-blue-500,space-card-padding: space-16
- 例:
- コンポーネント・トークン（Component-Specific Tokens）
特定のコンポーネント専用にエイリアス・トークンを紐付けます。
- 例:
button-primary-bg: color-action-primary
- 例:
この3層構造を採用することで、デザインの意図（セマンティクス）がコードに明示され、ダークモードのようなコンテキストの切り替えも、エイリアス・トークンの参照先を変更するだけでシームレスに実現できるようになります。
一貫性と柔軟性のトレードオフ：コンポーネント設計の2つのアプローチ
システム構築において、デザイナーとエンジニアが頭を悩ませるのが「どこまでコンポーネントの自由度を許容するか」という点です。ガチガチに固められたコンポーネントは一貫性を保ちやすいですが、例外的な要件に対応できず、現場での「勝手な魔改造」を生み出します。
柔軟性を担保するためには、以下の2つのアプローチを組み合わせることが効果的です。
出典: 1. スロット（Slot）による子要素の注入
Figmaのコンポーネント設計や、現代のフロントエンドフレームワーク（React, Astroなど）の設計において、「中身を空けた枠組み」を提供し、中に入れる要素（スロット）を呼び出し側に委ねるアプローチです。 例えば、カードコンポーネントの「ヘッダー」や「コンテンツエリア」を固定のテキストにするのではなく、任意のマークアップや別のコンポーネントを差し込めるように設計します。これにより、レイアウトの一貫性を守りつつ、内容の自由度を最大化できます。
2. スタイルプロップスとテーマオーバーライド
すべての余白をトークンで固定するのではなく、特定の外枠（マージンなど）については、親コンポーネントからオーバーライド（上書き）できるようにします。これにより、他の要素との位置調整を行うための「隙間」を個別に調整可能にし、コンポーネント内部に不必要なマージンを持たせないクリーンな実装が可能になります。
現場で使われるシステムにするための3つのプラクティス
- ドキュメントと「なぜ」の共有 単にデザインアセットやコードコンポーネントを置くだけでは機能しません。「なぜこのルールになっているのか」の背景（アフォーダンスや認知負荷への配慮）を言語化し、誰でも見られる場所に公開しておくことが大切です。
- 変更プロセスの確立 プロダクトの進化に伴い、システム側もアップデートされる必要があります。「新しいコンポーネントを追加したい」「既存のトークンを変更したい」という時の相談窓口やレビュープロセスを整備し、システムを「生きている存在」として維持します。
- デザイナーとエンジニアの共通言語（Figma VariablesとCSS Variables of the project） FigmaのVariables機能などを活用し、デザインツールのトークン名と、CSS / Sassの変数名、あるいはTailwindのテーマ定義名を完全に一致させます。これにより、レビュー時のコミュニケーションコストが劇的に削減されます。
持続可能なデザインシステムは、最初から完璧なものを作ろうとせず、小さなコンポーネントからスタートし、現場のフィードバックを取り入れながら徐々に拡大していく「アジャイル」なアプローチこそが最も成功への近道です。
お役立ち情報
- Design Tokens Community Group (W3C) (英語)
- デザイントークンの世界標準フォーマットに関する仕様策定プロジェクト。
- Figma Design Systems Guide (英語)
- 業界標準デザインツールFigmaによる、持続可能なシステム構築の実践ステップ。
- スマートHRデザインシステム (日本語)
- デザイナーと開発者の連携、アクセシビリティの確保など、日本国内における運用のロールモデルとなるドキュメント。