仕事の中で「なぜこのデザインにしたの？」と聞かれた際、うまく言葉にできずにもどかしい思いをした経験はありませんか？
デザインを言葉にする「言語化力」は多くのデザイナーが直面するハードルであり、私自身もかつては説明ができず本当に悩んでいました。

最近ではAIによるビジュアル自動生成が進化し、対話型の「AI壁打ち」も当たり前になってきています。
しかし、このAIを使いこなすためにも、私たち人間側が「何をどうしたいのか」「なぜこのUIなのか」を明確に言語化するスキルが必要不可欠です。

今回は、感覚的なデザインを論理的に翻訳し、チームの共通言語にするための具体的なアプローチや日常のトレーニング方法についてお話しします。

1. なぜ今、デザイナーに「デザイン言語化力」が必要なのか？

結論からお伝えすると、「なぜそのデザインにしたのかを言葉で説明し、合意を形成する力」の重要性自体は以前から言われていましたが、AIの急速な発達によって、その必要性がこれまで以上に極めて高まっています。

もともとデザインの意図を説明することは大切でしたが、基本的な造形や整ったレイアウトであればAIが瞬時に生成できるようになった現在、表層的な制作作業自体のコモディティ化が加速しています。
特に新卒やジュニア、駆け出しのデザイナーにとって、単に「綺麗なカンプを作れる」だけでは、チームの中で十分な価値を発揮することが難しくなっています。

だからこそ、自身の市場価値を証明し、キャリアの初期段階から成長を加速させるためにも、言語化と合意形成の能力が極めて強く求められるようになっているのです。

デザイナーが単なる「作業のオペレーター」ではなく、プロジェクトの信頼できるパートナーとして機能するためには、自らのデザイン意図を客観的かつ論理的に説明できなければなりません。

非デザイナーのステークホルダー（ビジネスサイドやエンジニアなど）と対話する際、言語化が不足していると、以下のような問題が発生します。

• 判断基準のズレ： デザイナーは「情報設計」や「認知負荷の軽減」の観点で設計しているのに対し、ビジネスサイドは「短期的な数値目標（コンバージョン率など）」、エンジニアは「実装コスト」という全く異なる基準でデザインを見ています。
• 不毛なフィードバックの繰り返し： 共通の判断軸がないため、「なんとなく違う」「もう少しおしゃれに」といった主観的で抽象的なやり取りが続き、度重なる修正作業（手戻り）が発生します。

デザインの言語化とは、単に自分のデザイン案を強引に通すための説得テクニックではありません。
お互いの「判断基準のズレ」を観察し、感覚的なイメージを論理的な言葉へ翻訳することで、チーム全体のキャッチアップコストを下げ、共創の土台を作るためのものなのです。

2. デザイン意図をロジカルに分解する「3つの軸」フレームワーク

感覚的な「なんとなく良さそう」から脱却し、誰にでも伝わる論理的な説明を組み立てるには、デザインの決定プロセスを「目的」「根拠」「オプションとトレードオフ」の3つの軸に分解して整理するのが有効です。

① 目的 (Purpose)

そのデザインが「何を解決するためのものか」、ユーザーのタスクやビジネス上のゴール（KPI）とどのように結びついているかを明確にします。

✕ 悪い例：「画面がすっきり見えるように、ボタンを右上に小さく配置しました」
◯ 良い例：「今回のターゲットユーザーは日常的にアプリを使い込んでいるため、頻繁に行う『保存』アクションへのアクセスを優先し、視線誘導の起点となる右上に配置しました」

② 根拠 (Basis)

なぜその視覚表現やレイアウトを選んだのか、個人の好みではない客観的な裏付けを提示します。
これには、色彩心理学やゲシュタルトの法則（近接、整列など）といったデザインのセオリー、あるいはユーザー行動のデータや既存のメンタルモデル（使い慣れた他社アプリの構造など）が該当します。

✕ 悪い例：「ここの余白はこれくらいがしっくりきました」
◯ 良い例：「近接の法則に基づき、関連性の高い情報群の余白を8pxに狭め、異なるセクション間の余白を32px空けることで、スクロール中も情報の区切りが直感的に伝わるよう設計しています」

③ オプションとトレードオフ (Options & Trade-offs)

デザインの決定は常にトレードオフを伴います。
「他にどのような選択肢を検討し、なぜ最終的にこの案を採用したのか」、あるいは「何を優先して何を捨てたのか」を説明できるようにしておきます。

✕ 悪い例：「このデザインが一番良いと思います」
◯ 良い例：「ナビゲーションについて、下部タブUIとサイドメニューUIの2つを検討しました。項目が3つと少なく、瞬時の切り替えが必要なため、実装工数は若干増えますが、認知負荷の最も低い下部タブUIを採用し、サイドメニュー案は見送りました」

この「3つの軸」は、日々の実務ミーティングはもちろん、新卒やジュニアデザイナーの就職活動におけるポートフォリオ作成や採用面接の場でも強力な武器になります。

「なぜこのデザインにしたのか」をこのフレームワークに沿ってあらかじめ記述しておくことで、採用担当者や面接官に対して「感覚だけで作っているのではなく、目的と根拠を持って設計できるデザイナーである」ことを明確にアピールでき、実務経験が浅くても高い信頼感を与えることができます。

また、このように要素を分解して整理しておくことで、他職種のメンバーも「何を基準に議論すればよいか」が分かりやすくなり、現場での建設的な意見交換がスムーズに行えるようになります。

3. 先進企業の事例から学ぶ「共通言語」としての言語化

多くの成長企業やデザイン組織では、デザイナーの評価基準や社内プロセスにおいて、言語化の重要性が公式に明文化されています。

これらの企業事例が示すように、シニアレベル以上のデザイナーに共通して求められるのは、単なるスタイリング能力ではありません。
「デザインを通じて事業価値をどう最大化するか」を論理的に語り、チームを巻き込んで合意を形成する力なのです。

4. 日常の業務に組み込める「言語化トレーニング」

デザインの言語化力は、生まれ持ったセンスではなく、日々の意識的な取り組みによって後天的に鍛えられる「技術」です。
特にキャリアの浅いうちは、まず「無意識に行っている選択を意識化すること」から始めましょう。

今日からでも実践できる3つのトレーニング方法をご紹介します。

① 「なぜ？」を3回繰り返す自問自答

自分のデザイン作業中に、無意識で行った選択（色、フォント、余白など）に対して、頭の中で「なぜそうしたのか」と自問自答を繰り返します。
ジュニアのうちは、上司や先輩から突っ込まれやすいポイントを先回りして考えるのがコツです。

• 「なぜここのフォントサイズを大きくしたのか？」
  → 「ユーザーが最初に読むべき見出しだからです」
• 「なぜ最初に読ませる必要があるのか？」
  → 「スクロールするかどうかの判断基準になる情報だからです」
• 「なぜこの情報が判断基準になるのか？」
  → 「前ページでの課題感と直結する結論部分だからです」

最低3回繰り返すことで、自分の感性的な判断を客観的なロジックに結びつける回路が鍛えられます。

② 既存デザインの「逆引き」トレース

世の中の優れたUI（日常的に使うアプリなど）を観察し、「制作者はどのような課題を解決するために、なぜこのレイアウトにしたのか」を逆算して仮説を立て、言葉に書き出してみます。

単に見た目を綺麗だと感じるだけでなく、「この配置になっている理由は、スマートフォンの親指が届きやすい範囲を考慮したからではないか」といった仮説を言語化することで、自分自身のデザインの引き出しが拡張されます。

③ AIを用いた高速PDCA壁打ち

近年では、AI（ChatGPTやGeminiなど）を壁打ち相手にした言語化トレーニングも非常に効果的です。

例えば、AIに対して「このような目的のUIデザイン（またはHTML/CSSコード）を作成してほしい」と指示を出します。
AIから出力された結果に対して、「もっと情報の優先度を高めるために余白を広くして」「ターゲットユーザーのメンタルモデルに合わせて配置を変更して」など、具体的な修正指示を重ねていきます。

AIは人間の「なんとなく」という曖昧な表現を理解できません。
そのため、このプロセスそのものが、自らの意図を「具体的かつ客観的な指示」に落とし込むための極めて速いフィードバックループ（PDCA）になります。

5. レビューをチームの共創の場にする工夫

組織としてデザインの品質を担保しながら言語化力を高めるためには、デザインレビュー（DR）の仕組みづくりも重要です。

特に新卒やジュニアデザイナーにとって、先輩やリーダーからのデザインレビューは「自分の作ったものが否定されている」ように感じられ、心理的ハードルが非常に高くなりがちです。
しかし、レビューは決して個人の能力を測る試験ではなく、チームでより良いプロダクトを作るための「共創の場」です。

そこで、レビューの心理的ハードルを下げ、活発な合意形成とジュニアの成長を促すために、以下のような工夫が有効です。

• 「見た目」から議論に入らないルールの徹底： レビューの冒頭では、いきなり完成したデザインデータを見せるのではなく、必ずデザイナー自身が最初に「案件の背景」「解決したい課題（目的）」「今回検証したいポイント」を言葉で説明するルールを徹底します。これにより、「好みの問題」に終始するのを防げます。
• 「2割共有」とオンデマンドな壁打ちの推奨： デザインが8割〜10割完成した段階でレビューに出すと、大きな手戻りが発生した際のダメージ（心理的・工数的）が計り知れません。新卒やジュニアこそ、ワイヤーフレームや初期のアイデア段階（2〜3割の進捗）で、「なぜこの方向性で考えているか」を気軽に言葉で先輩と壁打ちし、早めに軌道修正を図る仕組みを推奨します。
• ラジオ感覚でのオープンな聴講： レビューの場を当事者以外にもオンラインで解放し、他のメンバーが「ラジオ感覚」で聴講できるようにします。他のデザイナーがどのように自分の意図を言語化し、フィードバックを受け取っているかを聞くだけでも、ジュニアデザイナーにとっては非常に学びの多い、生きた教科書になります。

デザインレビューの場を「意図を説明し、他者の視点を取り入れてより良くする対話の場」として再定義することが、新卒やジュニアデザイナーの急速な成長とプロダクトの品質向上を両立させる近道です。

あわせて読みたい：デザインの裏側にある「意図」と「協働」

デザイナーの役割が変化する時代において、チームで共通言語を持ち、どのようにプロダクトの体験を作り上げていくかについて、こちらの記事も参考にしてみてください！

undefined

AI時代におけるデザイナーとエンジニアの協働。デザインとコードが近づくことで変わる、私たちのマインドセット

こんにちは！UIデザイナーのYunyです。 デザインデータを作り終えてエンジニアさんに渡した後、「あれ、ここの余白ちょっ…

終わりに

AIがビジュアルを瞬時に作れる時代だからこそ、人間心理に基づき「なぜそのデザインにしたのか」を言葉にする価値がかつてないほど高まっています。
最後に、今回の記事で押さえておきたいポイントをまとめました。

• 目的・根拠・トレードオフの3軸でデザイン決定のプロセスを分解する
• エンジニアやPdMなど、相手の職能の判断基準（物差し）に合わせて言葉を翻訳する
• 日常の中で「なぜ？」を繰り返す自問自答や、AIを壁打ち相手にした練習を取り入れる
• ジュニアデザイナーこそ、デザイン初期段階の「2割共有」で気軽に壁打ちする習慣を作る

最初から完璧な説明を目指す必要はありません。
まずは日々の無意識な選択に対して「なぜ？」と1回問いかけてみることから、少しずつ言語化の引き出しを増やしていきましょう。

最後までお読みいただき、ありがとうございました！

それでは、良いデザインライフを！

The post 「なんとなく良い」を卒業する。デザインの意図を論理的に翻訳する「言語化力」の鍛え方 first appeared on デザペディア.

最近、FigmaのMCP連携や音声入力などを使い、AIと「対話」しながら作業を進めることが増えました。客観的なフィードバックをくれる「相棒」がそばにいると、一人で抱え込んで作るよりも、格段に視野が広がるのを感じています。

この「外部の視点を入れて、一緒にプロダクトを良くしていく」という心地よい感覚は、チームで行う「デザインレビュー」の本質そのものです。

しかし、人間同士のレビューとなると、どうしても「ダメ出しされるのではないか」「自分のセンスを否定されているのではないか」と身構えてしまうこともありますよね。

せっかく時間をかけて作ったデザインだからこそ、そこへの指摘を自分自身への攻撃のように感じてしまう。そんなレビューへの苦手意識をスッキリと解消し、プロダクトの品質を高めるための強力なプロセスへと昇華させる「受審者の心構え」と、議論をリードする高度実践的なフレームワークを見ていきましょう。

1. なぜデザインレビューは「恐怖の場」になりやすいのか？

デザインレビューで指摘を受けると、胸がキュッと痛くなったり、反論したくなったりすることがありますよね。これはデザイナーとしての能力が低いからではなく、人間の脳の自然な反応です。

ものづくりに関わる私たちは、知らず知らずのうちに「自分 ＝ 制作物（デザイン）」という同一視をしてしまいがちです。自分が時間をかけて考え抜いたデザインだからこそ、そこへの指摘を「あなた自身のスキルやセンスが足りない」という人格否定として脳が誤って翻訳してしまうのです。

この心理的な仕組みを理解し、「デザインへの指摘」と「自分自身への評価」を切り離して捉え直すことが、最初の心構えになります。

そもそも、デザインレビューの本来の目的は何でしょうか。それは、デザイナーの優劣を競うことではなく、「プロダクトの問題発見コストを最小化するための防波堤」となることです。

プロダクト開発において、デザイン段階で問題を見つけるのと、エンジニアによるコーディングが完了した後に見つけるのでは、修正にかかる時間やコストに大きな差が生まれます。IBM Systems Sciences Instituteの調査などでも、設計（デザイン）段階で不具合を解決するのに比べて、実装（コーディング）段階では約6倍、さらにリリース後の運用段階では最大100倍の修正コストがかかると報告されています。早い段階で多様なメンバーの視点を取り入れ、デザインレビューという「防波堤」で問題を早期に特定することは、プロジェクト全体のコストと時間を守るための賢い防衛策なのです。

下記記事でも紹介したように、デザインの使いやすさには明確な論理が存在します。レビューで指摘されるのは、あなたのセンスの良し悪しではなく、「ユーザーの認知負荷をさらに下げるための改善点」です。他者の目を「自分のデザインをより強くするための心強い味方」として歓迎することから始めてみましょう。

undefined

2. 受審を自らコントロールする高度実践フレームワーク「30-60-90ルール」

レビューでよくある失敗が、「ボタンの色や細かな文言ばかりに議論が集中し、根本的な画面遷移や情報設計の議論ができなかった」というケースです。このような事態を防ぐために、受審者であるデザイナー自身が議論の範囲をコントロールするフレームワークが「30-60-90ルール」です。

これは、デザインの進捗度（30%、60%、90%）に応じて、求めるフィードバックと、あえて求めない（制限する）フィードバックをあらかじめ定義し、参加者に宣言する手法です。

30%レビュー（方向性・コンセプトの確認）

デザインの初期段階で実施するレビューです。画面はまだ手書きのワイヤーフレームや、主要なユーザーフローが記述された簡易的な資料のレベルです。

• 求めるフィードバック：解決しようとしている課題定義の整合性、大まかな情報階層、ユーザーフローの妥当性。
• 求めないこと：フォントの種類、配色、ボタンの角丸のサイズ、具体的なテキスト表現などのビジュアル詳細。

60%レビュー（構造とUX設計の確認）

骨組みが固まり、グレースケール（白黒）でワイヤーフレームや遷移図を構築した段階でのレビューです。

• 求めるフィードバック：詳細な情報設計、主要な画面遷移のつながり、一般的なエラー状態（ローディングやデータ未登録時など）の網羅性。
• 求めないこと：写真の選定、微細なインタラクションアニメーション、ビジュアルとしての美しさの評価。

90%レビュー（ビジュアルと実装詳細の確認）

ビジュアルデザインがほぼ完成し、リリースに近い状態のプロトタイプでのレビューです。

• 求めるフィードバック：ピクセル単位のレイアウト調整、最終的なコピーライト（文言）のチェック、エッジケース（テキストが極端に長い場合の表示崩れなど）の確認。

レビューの冒頭で、「今回は60%段階のレビューですので、情報設計と画面遷移に絞ってご意見をください。色やフォントは仮のものなので、ビジュアルへの指摘は次回お願いできればと思います」と受審者から宣言します。これだけで、レビューアーは「今どこに目を向ければよいか」が明確になり、議論の脱線や散らかりを防ぐことができます。

特に60%〜90%の段階では、実装上の制約を考慮することが不可欠です。下記記事でも解説している通り、早い段階からエンジニアをレビューに巻き込み、実装可能性について対話しておくことで、後工程の大幅な手戻りを劇的に減らすことができます。

undefined

3. レビューを円滑に進める「受審者の3つの作法」

レビューの場でデザイナー自身がとるべき具体的なコミュニケーションの作法を3つに整理しました。これらを意識するだけで、レビューの場は「指摘会」から「建設的なディスカッション」へと変化します。

① デザインの意思決定の背景（背景の文脈）を伝える

単に「この画面を作りました」と見せるのではなく、なぜその配置やスタイルにしたのか、意思決定の背景（コンテキスト）を説明します。
「過去のユーザー調査で〇〇という課題があったため、ここでは認知負荷を下げるためにAのパターンを採用しました」といった論理的な根拠を添えましょう。

下記記事でも解説しているように、数字や認知心理学的な根拠を背景に持つことで、レビューアーとの間で「感覚的な好き嫌い」の平行線になるのを防ぎ、共通の判断軸を持って対話を行うことができます。

undefined

② 反論ではなく「まずは理解と感謝」を示す

「ここは〇〇だからこうしたんです」と、指摘に対して即座に自己防衛の反論をしたくなる気持ちはよく分かります。しかし、そこをグッと抑えて、まずは「ご指摘ありがとうございます。確かにそこは初見のユーザーにとって分かりにくいかもしれませんね」と、相手の指摘を一度そのまま受け止めましょう。
その上で、「その懸念を解消するために、実はBという選択肢も検討したのですが…」と対話を広げます。このワンクッションがあるだけで、場全体の空気は非常に柔らかくなります。

③ 次のアクションと役割をその場でクリアにする

レビュー中に出たすべての指摘をそのままデザインに反映する必要はありません。レビューの最後、または議事録の確認時に、以下の3つのフォルダに指摘を分類して提示しましょう。

• 対応する項目：次のステップまでにデザインを修正するもの。
• 持ち帰る項目：他のデータや仕様を確認した上で、後日判断するもの。
• 見送る項目：今回のリリーススコープ外とする、または別の理由で現状維持とするもの。

受審者がこの分類を主導することで、「すべての指摘に振り回されてデザインが破綻する」のを防ぎ、デザイナーとしての設計責任を守ることができます。

まとめ：レビューは「チームで勝利する」ための最高のツール

デザインレビューを受審することは、決して「自分の作品を採点される試練」ではありません。むしろ、自分一人では気づけなかったユーザーの迷いや実装上の懸念を、チームメンバーが寄ってたかって一緒に解決してくれる「最高の協力プレイ」です。

「30-60-90ルール」を用いて議論を自らコントロールし、対話の作法を意識することで、レビュー会議はデザインの質を飛躍的に高めるパワフルな時間へと進化します。

チーム全員を「自分のデザインの共同制作者」として味方につけ、より良いプロダクトを届けていきましょう！

終わりに

最後までお読みいただき、ありがとうございます！

デザインレビューに対して漠然とした苦手意識や怖さを抱いていた方も、フレームワークを活用して「見せる範囲」を制限することで、少し気持ちが軽くなるのではないでしょうか。

私自身もレビューを受けるときは毎回緊張しますが、今回紹介したアプローチを意識するようになってからは、メンバーの意見を前向きに取り入れられるようになりました。

皆さんの次のデザインレビューが、より楽しく、建設的な時間になることを願っています。

それでは、良いデザインライフを！

The post 「デザインレビューが怖い」を卒業する。受審の心構えとフィードバックを自ら操る実践フレームワーク first appeared on デザペディア.