デザインシステムは、UI部品を並べたカタログだけではありません。組織が一貫して使いやすい体験を作るための、原則、ルール、部品、コード、文言、ドキュメント、運用の仕組みです。
デザインシステムで解決すること
- 同じ操作なのに見た目が違う
- ページごとに色や余白が増える
- デザイナーと開発者の認識がずれる
- アクセシビリティ確認を毎回やり直す
- 変更の影響範囲が分からない
- 新しい担当者が判断基準を学べない
目的は統一そのものではなく、利用者が操作を予測でき、チームが品質を再現できることです。
構成要素
| 層 | 内容 |
|---|---|
| 原則 | 分かりやすさ、一貫性、包摂性など |
| 基礎 | 色、文字、余白、角、影、動き |
| トークン | 意味を持つ値と名前 |
| 部品 | ボタン、入力、カード、通知 |
| パターン | 検索、申込、エラー回復 |
| 文言 | ラベル、案内、エラー |
| 運用 | 提案、レビュー、更新、廃止 |
小さく始める順番
- 現在の画面を棚卸しする
- 重複と不一致を見つける
- よく使う色・文字・余白を定義する
- ボタンとフォームを統合する
- 状態とアクセシビリティを追加する
- 使用例と禁止例を書く
- 実画面で採用し、改善する
使われない完全なライブラリを先に作らず、実際の問題から始めます。
トークンは意味で名付ける
blue-500のような見た目の名前だけでなく、text-primary、action-primary-background、error-borderのような役割名を使うと、テーマ変更やコントラスト改善を反映しやすくなります。
基礎色と意味色の対応を分けて管理します。
コンポーネントに含める状態
- 通常
- ホバー
- フォーカス
- 押下
- 無効
- 読み込み
- エラー
- 完了
見た目だけでなく、キーボード操作、スクリーンリーダー名、タップ領域、長文・多言語・文字拡大も確認します。
ドキュメントに書くこと
- 何の問題を解く部品か
- 使う場面・使わない場面
- 必須ラベルと内容制約
- 状態と操作
- アクセシビリティ要件
- 実装例
- 関連部品
- 変更履歴
スクリーンショットだけでは、動きや意味が伝わりません。
公式システムを参考にする
デジタル庁デザインシステムは、カラー、タイポグラフィ、アイコン、レイアウト、余白などの基礎とアクセシビリティを公開しています。自社へそのまま複製せず、設計判断と記述方法を参考にします。
運用の責任を決める
提案者、レビュー担当、承認者、実装担当、変更通知先を決めます。誰でも変更できない状態と、誰も変更できない状態の両方を避けます。
まとめ
デザインシステムは、一貫した体験を再現するための共同基盤です。色・文字・余白・ボタン・フォームから小さく始め、状態、文言、アクセシビリティ、変更管理を実画面と一緒に育てましょう。
