フレームワーク活用ガイドひとことで言うと#
デザインのルールブック。色、フォント、余白、ボタン、アイコンなどの使い方を明文化し、誰が作っても一貫した見た目と体験になるようにする。スタイルガイドがなければ、デザイナーが増えるたびにUIがバラバラになっていく。
押さえておきたい用語#
- デザイントークン（Design Token）
- 色・フォント・余白などの値を変数として一元管理する仕組み。コードとデザインの橋渡し。
- カラーパレット
- プロダクトで使用する色の一覧と用途の定義。プライマリ・セカンダリ・アクセント等。
- コンポーネントライブラリ
- ボタン・カード・フォームなどの再利用可能なUI部品の集合。
- スペーシングシステム
- 余白のサイズを4px/8px/16pxなどの倍数で統一するルール。
スタイルガイドの全体像#
こんな悩みに効く#
- 画面ごとにボタンの色や大きさが微妙に違う
- デザイナーが複数人になり、統一感が失われてきた
- エンジニアに「ここの余白は何px？」と毎回聞かれる
基本の使い方#
現在のプロダクトで使われているデザイン要素をすべて洗い出す。
- 色: 実際に使われている色をすべてスポイトで抽出
- フォント: 使われている書体・サイズ・ウェイトを一覧化
- コンポーネント: ボタン、フォーム、カード、ナビゲーションなど
- 余白・間隔: 実際に使われている値を集計
よくある発見: 「青色」だけで8種類使われている、ボタンのバリエーションが15種類ある、など。
洗い出した要素を整理・統合してルール化する。
- カラーパレット: プライマリ・セカンダリ・アクセント・グレースケールを定義
- タイポグラフィ: 見出し（H1〜H4）・本文・キャプションのサイズとウェイト
- スペーシング: 4px / 8px / 16px / 24px / 32px のようなグリッドシステム
- コンポーネント: ボタン（プライマリ / セカンダリ / テキスト）の状態別デザイン
ルールは「なぜそうするか」の理由も添える。「プライマリボタンは青 → CTAに注目を集めるため」。
ルールをアクセスしやすい場所に置き、常に参照できる状態にする。
- Figmaのチームライブラリとして公開
- Notionやドキュメントサイトにまとめる
- Storybook等のコンポーネントカタログと連携
更新ルールも決めておく:
- 変更はデザインリードが承認
- 四半期ごとにレビュー・更新
- 新しいパターンが必要な場合の申請フロー
具体例#
Before（ガイドなし）:
- デザイナー3人がそれぞれ違うブルーを使用（#2563EB / #3B82F6 / #1D4ED8）
- ボタンの角丸がページによって4px / 8px / 12pxとバラバラ
- エンジニアがデザインの意図を毎回確認 → 実装に1.5倍の時間
After（スタイルガイド導入）:
- Primary: #2563EB（メインアクション）、Secondary: #64748B、Accent: #F59E0B
- ボタン: 角丸8px、高さ44px統一
- タイポグラフィ: H1=32px Bold / Body=16px Regular
結果: デザインレビューの指摘が60%減少、エンジニアの実装速度が30%向上。 「これ何色使えばいい？」の質問がゼロに。
状況: デザイナー8名、エンジニア30名、PM5名の組織。Figmaのデザインとコードの実装が常にズレており、リリース前のデザイン確認工数が全体の15%を占めていた。
アプローチ:
- Figmaのデザイントークンをスタイルガイドとして定義
- デザイントークンをJSON出力し、Storybookのコンポーネントに自動反映
- デザイン変更→Figma更新→自動でコードのトークン更新の仕組みを構築
結果: デザイン確認工数が15%から3%に削減（80%減）。 Figmaで色を変更すると翌日のビルドに自動反映され、デザイナーとエンジニアの齟齬がほぼゼロに。
状況: ブランドカラーの変更（青→緑）に伴い、200画面以上のUIを更新する必要がある。スタイルガイドなしの見積もりでは3ヶ月。
スタイルガイドの活用:
- カラーパレットのプライマリ色を1箇所変更（#2563EB→#059669）
- デザイントークン経由で200画面すべてに自動反映
- コンポーネントライブラリのボタン・バッジ・リンク色が一括更新
- 個別調整が必要な箇所のみ手動対応（アクセシビリティのコントラスト比チェック）
結果: 200画面の更新を3週間で完了（見積もりの1/4）。 スタイルガイドがなければ3ヶ月かかる作業が、トークンの一元管理で劇的に短縮された。
やりがちな失敗パターン#
- 最初から完璧なガイドを作ろうとする — 全ページ分のルールを一気に作ると半年かかって誰も使わない。まず色・フォント・ボタンの3要素だけでスタートし、段階的に拡張する
- 作って放置する — プロダクトは進化するがスタイルガイドが更新されないと、すぐに形骸化する。四半期ごとのレビューサイクルを必ず設ける
- デザイナーしか見ない場所に置く — エンジニアやPMもアクセスできる場所に置かないと、結局「これ何px？」の質問は続く。全員が見れる・検索できる形で公開する
- ルールだけ書いて理由を書かない — 「なぜこの色か」がわからないと例外判断ができない。各ルールに意図と理由を添える
まとめ#
スタイルガイドはデザインの一貫性を守るルールブック。色・フォント・コンポーネントのルールを明文化することで、チームが大きくなっても統一されたUIを維持できる。最初は小さく始めて段階的に拡張し、定期的に更新する運用サイクルをセットで設計することが成功の鍵。