ひとことで言うと#
色・フォント・コンポーネント・インタラクション・文言のルールを一箇所にまとめた「UIの共通言語」。デザイナーとエンジニアが同じルールブックを見ることで、一貫性のあるプロダクトを素早く作れるようになる。
押さえておきたい用語#
- デザイントークン(Design Token)
- 色・フォント・余白などのデザイン値を変数名で管理する仕組み。
color-primaryのように名前で指定し、後から一括変更が可能。 - コンポーネント
- ボタン、入力フィールド、モーダルなど再利用可能なUIの部品。バリエーション(Primary/Secondary/Disabled等)を持つ。
- Storybook(ストーリーブック)
- コンポーネントをブラウザ上でカタログ形式に表示し、動作確認できる開発ツール。
- コントリビューションガイド
- デザインシステムに新しいコンポーネントを追加するためのルールとプロセスを定めた文書。
- ガバナンス
- デザインシステムの更新管理・品質維持・意思決定の仕組み。専任チームまたは担当者が必要。
デザインシステムの全体像#
こんな悩みに効く#
- 画面ごとにデザインがバラバラで、同じアプリに見えない
- デザイナーが増えるたびにUIの不一致が増える
- 同じようなコンポーネントを何度もゼロから作っている
基本の使い方#
デザインシステムの最小単位=デザイントークンを決める。
- カラー: プライマリ、セカンダリ、背景、テキスト、エラー、成功などの色パレット
- タイポグラフィ: フォントファミリー、サイズスケール(H1〜body〜caption)、行間
- スペーシング: 余白のスケール(4px, 8px, 16px, 24px, 32px, 48px……)
- 角丸・影・ボーダー: UIの質感を決める基本値
トークンに意味のある名前をつける(color-primary spacing-md など)。#3B82F6 や 16px ではなくトークン名で指定することで、後から一括変更が可能になる。
デザイントークンを使って再利用可能なUIコンポーネントを作る。
- 基本コンポーネント: ボタン、入力フィールド、チェックボックス、ドロップダウン
- パターンコンポーネント: カード、モーダル、テーブル、ナビゲーション
- 各コンポーネントにバリエーションを定義(例: ボタン → Primary / Secondary / Ghost / Disabled)
- 使用ガイドライン: いつ、どの場面で、どのバリエーションを使うか
デザインファイル(Figma)とコードライブラリ(React、Vue等)を同期させるのが理想。
デザインシステムは使われなければ意味がない。
- ドキュメントサイト: 各コンポーネントの使用例、Do/Don’t、コード例を掲載
- コントリビューションガイド: 新コンポーネントの追加ルール
- バージョニング: 変更履歴を管理し、破壊的変更は事前に通知
- オーナーシップ: デザインシステムの専任チーム(最低1名)を置く
小さく始めて育てるのが鉄則。最初から完璧なシステムを目指さない。
具体例#
Phase 1(2週間): 現状の棚卸し
- 全画面のスクリーンショットを並べて、使われている色・フォント・コンポーネントを洗い出す
- 発見: ボタンが7種類、グレーが12色、フォントサイズが15パターン。統一感ゼロ
Phase 2(2週間): トークン+基本コンポーネント定義
- カラー: プライマリ(Blue-600)、セカンダリ(Gray-700)、エラー(Red-500)+ 各色の100〜900スケール
- フォント: 見出しInter Bold / 本文Inter Regular / サイズ5段階
- スペーシング: 4px刻みの8段階
- 基本コンポーネント: ボタン3種、入力4種、カード、モーダルをFigma+React
Phase 3(1ヶ月): 展開+ドキュメント
- Storybookでコンポーネントカタログを公開
- 新規画面からデザインシステムを適用。既存画面は段階的に移行
- 週1回の「デザインシステムオフィスアワー」で質問対応
効果: 新画面のデザイン〜実装が40%短縮。 「このボタンどっちを使う?」の議論がゼロに。エンジニアのコメント「コンポーネントを組み合わせるだけで画面が作れる」。
状況: 3つのSaaSプロダクトを持つ企業。各プロダクトが独自のUIルールで開発されており、同じ会社の製品に見えない。顧客から「操作体系がバラバラで使いにくい」との声。
取り組み:
- 3プロダクト共通のデザイントークンを定義(カラー5色、フォント2種、スペーシング8段階)
- 共通コンポーネント25個を作成。各プロダクト固有のコンポーネントは別レイヤーで管理
- 全プロダクトのデザイナー8名+エンジニア15名がStorybookを共有
結果:
- プロダクト間のUI差異: 87箇所→12箇所(86%削減)
- 新機能開発速度: 平均2.3倍に向上(共通コンポーネント再利用のため)
- 顧客満足度調査で「製品間の一貫性」スコアが3.1→4.4に改善(5点満点)
- デザイナーの異動時のキャッチアップ期間が2週間→3日に短縮
状況: デザイナー1名、エンジニア4名のスタートアップ。デザインシステムの必要性は感じているが、専任リソースは割けない。
最小構成でのスタート(Week 1-2):
- デザイントークン: カラー4色、フォントサイズ4段階、スペーシング4段階
- コンポーネント: ボタン2種、入力フィールド2種、カード1種(計5個)
- ドキュメント: NotionにDo/Don’tを記載(1コンポーネント1ページ)
成長過程(6ヶ月):
- Month 1: +3コンポーネント(モーダル、ドロップダウン、テーブル)
- Month 3: Storybookを導入しコード側も整備。コンポーネント計15個
- Month 6: デザイントークンをFigma Variables化。コンポーネント計28個
結果: 6ヶ月後にはデザイン〜実装のサイクルが2.5倍速に。 エンジニアの声「最初の5個だけでも、あるとないでは全然違った」。小さく始めたからこそ、プロダクトの成長に合わせて自然にシステムが育った。
やりがちな失敗パターン#
- 最初から完璧を目指す — 100コンポーネントを定義してからローンチしようとして、いつまでも完成しない。まず10〜15個の最頻出コンポーネントから始める
- デザインだけ or コードだけ — Figmaにだけ定義してコードと乖離する(逆も然り)。デザインとコードの同期が命
- ルールを作って押し付ける — 開発者やデザイナーが「使いたい」と思えるDX(Developer Experience)が大事。強制ではなく「使うほうが楽」な状態を作る
- 専任担当者を置かない — 全員の「片手間」で運用すると、更新が止まり陳腐化する。最低1名のオーナーを明確にし、更新とサポートの責任を持たせる
まとめ#
デザインシステムは「UIの共通言語」。トークン→コンポーネント→ドキュメントの3層構造で、一貫性と効率を両立する。小さく始めて育てていくことが成功の鍵。プロダクトが成長してメンバーが増えるほど、デザインシステムの投資対効果は大きくなる。