フレームワーク活用ガイドひとことで言うと#
プロダクトやブランドが「どう見え、どう感じられるべきか」を定義した共通言語。色・タイポグラフィ・アイコン・アニメーションといった視覚要素だけでなく、トーン&ボイス・インタラクションパターンまで含む包括的なルールセット。デザインシステムが「部品集」なら、デザイン言語は「設計思想」に当たる上位概念。
押さえておきたい用語#
- デザイン原則（Design Principles）
- デザイン言語の核となる3〜5個の判断基準。すべてのデザイン判断の拠り所であり、トレードオフを明示する。
- トーン&ボイス（Tone & Voice）
- プロダクトが**ユーザーに語りかける「人格」**のこと。フレンドリーか、プロフェッショナルか、テキストの文体を決める。
- モーション言語（Motion Language）
- アニメーションの速度・イージング・意味を体系化したルール。「何が動くとどういう意味か」を定義する。
- セマンティックカラー
- 色に意味を持たせた定義。例：赤=エラー、緑=成功、黄=警告。ブランドカラーとは別に機能的な色体系を持つ。
デザイン言語の全体像#
こんな悩みに効く#
- チームが大きくなるにつれて、デザインの一貫性が崩れてきた
- 新しいデザイナーが入るたびに「このブランドらしさ」を説明するのが大変
- デザインレビューで主観的な議論が多く、合意に時間がかかる
基本の使い方#
デザイン言語の核は3〜5個のデザイン原則。すべてのデザイン判断の拠り所となる。
良いデザイン原則の条件:
- 具体的で判断基準になる（「美しい」は曖昧すぎる）
- トレードオフを明示する（「Aを優先し、Bは妥協する」）
- ブランドの個性を反映する（どの会社でも当てはまる言葉は避ける）
例（フィットネスアプリの場合）:
- 「励ますが、押し付けない」 — モチベーションを与えるが、罪悪感を刺激しない
- 「データは洞察に変える」 — 数字を見せるだけでなく、次に何をすべきかを提案する
- 「1秒で理解できる」 — 運動中でも一瞬で情報を把握できるシンプルさを追求する
これらの原則が、色の選定からマイクロコピーの文体まで、すべてのデザイン判断を導く。
デザイン原則に基づいて、視覚的な要素を定義する。
定義すべき要素:
| 要素 | 定義内容 | 例 |
|---|---|---|
| カラーパレット | プライマリ、セカンダリ、セマンティックカラー | 信頼=#2563EB, 成功=#16A34A |
| タイポグラフィ | フォント、サイズスケール、行間 | 見出し: Noto Sans JP Bold |
| アイコノグラフィ | スタイル、線の太さ、角の丸み | ラウンド、2px、4px radius |
| 写真・イラスト | トーン、構図のガイドライン | 自然光、人物中心、温かみ |
| スペーシング | 余白のスケール | 4px ベースの倍数 |
| シャドウ・エレベーション | 奥行きの表現ルール | 3段階のシャドウレベル |
各要素を決める際に必ず「この選択はデザイン原則のどれに基づくか」を明記する。 根拠のないルールは守られない。
視覚だけでなく、ユーザーとの「対話」のルールも定義する。
インタラクション言語の要素:
- モーション: アニメーションの速度、イージング、意味（何が動くとどういう意味か）
- フィードバック: タップ、ホバー、成功、エラーの表現方法
- トーン&ボイス: テキストの人格（フレンドリー？プロフェッショナル？）
- 情報密度: 1画面に出す情報量の基準
例（モーション言語）:
| 動き | 用途 | 速度 | イージング |
|---|---|---|---|
| フェードイン | コンテンツの出現 | 200ms | ease-out |
| スライド | 画面遷移 | 300ms | ease-in-out |
| スケール | 強調・注目 | 150ms | ease-out |
| バウンス | 成功・完了 | 400ms | spring |
モーションには必ず「意味」を持たせる。 装飾のためだけのアニメーションは認知負荷を増やす。
定義しただけでは意味がない。チーム全体に浸透させる仕組みを作る。
浸透のためのアクション:
- デザイン言語ドキュメントを作成: 原則 + 具体例 + NG例を含む
- オンボーディングに組み込む: 新メンバーが最初に読む資料にする
- デザインレビューで原則を引用: 「原則2に基づくと、この表現は〜」
- 定期的な見直し: 四半期に1回、原則がまだ有効か確認する
NG: PDFを作って共有フォルダに置くだけ。 → 誰も読まない。Figmaのライブラリや社内Wikiにリビングドキュメントとして管理する。
具体例#
状況: SaaSプロダクト。5人のデザイナーがそれぞれの判断でデザインしており、同じアプリ内でボタンの色が3種類、フォントサイズが12種類、アイコンスタイルが2種類混在。リデザインプロジェクトが始まったが、「どの方向性にするか」の議論だけで1ヶ月経過。
取り組み:
- デザインリードが2日間のワークショップを開催
- Day1: ブランドの価値観を言語化 → デザイン原則3つを策定
- Day2: 原則に基づいてカラー・タイポグラフィ・モーションを定義
策定したデザイン原則:
- 「プロを信頼する」— ユーザーは専門家。過剰な説明は省く
- 「静かに導く」— 派手なUIではなく、自然に次のアクションが見える
- 「一貫性は敬意」— ユーザーの学習コストを最小にする
3ヶ月後の変化:
- デザインレビュー時間: 平均60分→25分（58%削減、原則を基準に判断できる）
- デザインの手戻り率: 40%→15%
- 新メンバーのオンボーディング: 「まずデザイン言語を読んで」で初日からブランドに合った成果物が出る
個々のデザイン判断を速くするために、上位の「判断基準」を先に決めた。これがデザイン言語の本質的な価値。
状況: アプリ内のテキストがデザイナー・PM・エンジニアそれぞれの感覚で書かれており、同じアプリなのに「です・ます調」と「だ・である調」が混在。エラーメッセージのトーンもバラバラ。
デザイン原則とトーン&ボイスの策定:
- 原則: 「励ますが、押し付けない」
- ボイス: フレンドリーだが馴れ馴れしくない。「！」は1画面に1回まで
- トーン例: エラー時は「申し訳ありません」ではなく「うまくいきませんでした。もう一度試してみてください」
NG → OK のビフォー・アフター:
- NG: 「データの読み込みに失敗しました」→ OK: 「通信がうまくいきませんでした。少し待ってリトライしてみてください」
- NG: 「目標未達成です」→ OK: 「今週はあと2回で目標達成です」
結果: テキストのレビュー指摘が月40件→8件に減少。ユーザーアンケートで「アプリの雰囲気が好き」の回答が32%→51%に上昇。
状況: 日本・アメリカ・インドの3拠点にデザインチーム（計15名）。地域ごとに独自のカラーパレットとコンポーネントが発生し、共通プラットフォームなのにUIがバラバラ。
取り組み:
- 3日間のバーチャルワークショップで全拠点合同のデザイン原則を策定
- 視覚要素を統一（カラー8色→5色、フォントサイズ15→6段階、アイコン2スタイル→1スタイル）
- Figmaの共有ライブラリとStorybook上のコンポーネントを同期
- 月1回のデザイン言語レビュー会（各拠点持ち回り）
結果: 新機能の開発速度が1.8倍に向上。地域間の「このデザインどっちが正しい？」の問い合わせが週15件→2件に激減。ユーザーからも「どの国で使っても同じ体験」との声が増え、グローバルNPSが+12ポイント改善。
やりがちな失敗パターン#
- デザイン原則が抽象的すぎる — 「シンプルで美しい」はどの会社でも言える。判断に使えない原則は飾りになる。「AとBで迷ったとき、この原則に従えばAを選ぶ」くらい具体的にする
- 視覚要素だけ定義してインタラクションを無視する — 見た目は統一されているが、動きやフィードバックがバラバラ。モーション・トーン&ボイスもデザイン言語の一部
- 一度作って更新しない — プロダクトが進化してもデザイン言語が古いまま。現実と乖離し、誰も参照しなくなる。四半期ごとのレビューサイクルを設ける
- PDFを作って共有フォルダに置くだけ — 静的なドキュメントは誰も読まない。FigmaライブラリやStorybookなど、日常のワークフローに組み込む形で提供する
まとめ#
デザイン言語は、デザイン原則を核として視覚要素・インタラクション・トーン&ボイスを包括的に定義するルール体系。デザインシステムの「設計思想」に当たる上位概念であり、チームが大きくなるほどその価値が増す。「なぜこのデザインなのか」に対して全員が同じ言葉で答えられる状態を作ることが目標。