こんにちは！
UIデザイナーのYunyです。
この記事はこんな方に向けて書いています
- デザインレビューで「自分のデザインを否定された」と感じて落ち込んでしまう方
- レビュー会議で意見が散らかり、方向性が決まらずに困っているデザイナーの方
- フィードバックを建設的に受け止め、プロダクトの品質向上に繋げたい方
最近、FigmaのMCP連携や音声入力などを使い、AIと「対話」しながら作業を進めることが増えました。客観的なフィードバックをくれる「相棒」がそばにいると、一人で抱え込んで作るよりも、格段に視野が広がるのを感じています。
この「外部の視点を入れて、一緒にプロダクトを良くしていく」という心地よい感覚は、チームで行う「デザインレビュー」の本質そのものです。
しかし、人間同士のレビューとなると、どうしても「ダメ出しされるのではないか」「自分のセンスを否定されているのではないか」と身構えてしまうこともありますよね。
せっかく時間をかけて作ったデザインだからこそ、そこへの指摘を自分自身への攻撃のように感じてしまう。そんなレビューへの苦手意識をスッキリと解消し、プロダクトの品質を高めるための強力なプロセスへと昇華させる「受審者の心構え」と、議論をリードする高度実践的なフレームワークを見ていきましょう。
1. なぜデザインレビューは「恐怖の場」になりやすいのか？
デザインレビューで指摘を受けると、胸がキュッと痛くなったり、反論したくなったりすることがありますよね。これはデザイナーとしての能力が低いからではなく、人間の脳の自然な反応です。
ものづくりに関わる私たちは、知らず知らずのうちに「自分 ＝ 制作物（デザイン）」という同一視をしてしまいがちです。自分が時間をかけて考え抜いたデザインだからこそ、そこへの指摘を「あなた自身のスキルやセンスが足りない」という人格否定として脳が誤って翻訳してしまうのです。
この心理的な仕組みを理解し、「デザインへの指摘」と「自分自身への評価」を切り離して捉え直すことが、最初の心構えになります。
そもそも、デザインレビューの本来の目的は何でしょうか。それは、デザイナーの優劣を競うことではなく、「プロダクトの問題発見コストを最小化するための防波堤」となることです。
プロダクト開発において、デザイン段階で問題を見つけるのと、エンジニアによるコーディングが完了した後に見つけるのでは、修正にかかる時間やコストに大きな差が生まれます。IBM Systems Sciences Instituteの調査などでも、設計（デザイン）段階で不具合を解決するのに比べて、実装（コーディング）段階では約6倍、さらにリリース後の運用段階では最大100倍の修正コストがかかると報告されています。早い段階で多様なメンバーの視点を取り入れ、デザインレビューという「防波堤」で問題を早期に特定することは、プロジェクト全体のコストと時間を守るための賢い防衛策なのです。
世界標準に学ぶ「伝わるデザイン」の基礎体力と、日常を整えるヒントでも紹介したように、デザインの使いやすさには明確な論理が存在します。レビューで指摘されるのは、あなたのセンスの良し悪しではなく、「ユーザーの認知負荷をさらに下げるための改善点」です。他者の目を「自分のデザインをより強くするための心強い味方」として歓迎することから始めてみましょう。
2. 受審を自らコントロールする高度実践フレームワーク「30-60-90ルール」
レビューでよくある失敗が、「ボタンの色や細かな文言ばかりに議論が集中し、根本的な画面遷移や情報設計の議論ができなかった」というケースです。このような事態を防ぐために、受審者であるデザイナー自身が議論の範囲をコントロールするフレームワークが「30-60-90ルール」です。
これは、デザインの進捗度（30%、60%、90%）に応じて、求めるフィードバックと、あえて求めない（制限する）フィードバックをあらかじめ定義し、参加者に宣言する手法です。
30%レビュー（方向性・コンセプトの確認）
デザインの初期段階で実施するレビューです。画面はまだ手書きのワイヤーフレームや、主要なユーザーフローが記述された簡易的な資料のレベルです。
- 求めるフィードバック：解決しようとしている課題定義の整合性、大まかな情報階層、ユーザーフローの妥当性。
- 求めないこと：フォントの種類、配色、ボタンの角丸のサイズ、具体的なテキスト表現などのビジュアル詳細。
60%レビュー（構造とUX設計の確認）
骨組みが固まり、グレースケール（白黒）でワイヤーフレームや遷移図を構築した段階でのレビューです。
- 求めるフィードバック：詳細な情報設計、主要な画面遷移のつながり、一般的なエラー状態（ローディングやデータ未登録時など）の網羅性。
- 求めないこと：写真の選定、微細なインタラクションアニメーション、ビジュアルとしての美しさの評価。
90%レビュー（ビジュアルと実装詳細の確認）
ビジュアルデザインがほぼ完成し、リリースに近い状態のプロトタイプでのレビューです。
- 求めるフィードバック：ピクセル単位のレイアウト調整、最終的なコピーライト（文言）のチェック、エッジケース（テキストが極端に長い場合の表示崩れなど）の確認。
レビューの冒頭で、「今回は60%段階のレビューですので、情報設計と画面遷移に絞ってご意見をください。色やフォントは仮のものなので、ビジュアルへの指摘は次回お願いできればと思います」と受審者から宣言します。これだけで、レビューアーは「今どこに目を向ければよいか」が明確になり、議論の脱線や散らかりを防ぐことができます。
特に60%〜90%の段階では、実装上の制約を考慮することが不可欠です。AI時代におけるデザイナーとエンジニアの協働。デザインとコードが近づくことで変わる、私たちのマインドセットでも解説している通り、早い段階からエンジニアをレビューに巻き込み、実装可能性について対話しておくことで、後工程の大幅な手戻りを劇的に減らすことができます。
3. レビューを円滑に進める「受審者の3つの作法」
レビューの場でデザイナー自身がとるべき具体的なコミュニケーションの作法を3つに整理しました。これらを意識するだけで、レビューの場は「指摘会」から「建設的なディスカッション」へと変化します。
① デザインの意思決定の背景（背景の文脈）を伝える
単に「この画面を作りました」と見せるのではなく、なぜその配置やスタイルにしたのか、意思決定の背景（コンテキスト）を説明します。
「過去のユーザー調査で〇〇という課題があったため、ここでは認知負荷を下げるためにAのパターンを採用しました」といった論理的な根拠を添えましょう。
美しさの根拠を語れるか。数字を武器にするデザイナーの静かなる提案力でも解説しているように、数字や認知心理学的な根拠を背景に持つことで、レビューアーとの間で「感覚的な好き嫌い」の平行線になるのを防ぎ、共通の判断軸を持って対話を行うことができます。
② 反論ではなく「まずは理解と感謝」を示す
「ここは〇〇だからこうしたんです」と、指摘に対して即座に自己防衛の反論をしたくなる気持ちはよく分かります。しかし、そこをグッと抑えて、まずは「ご指摘ありがとうございます。確かにそこは初見のユーザーにとって分かりにくいかもしれませんね」と、相手の指摘を一度そのまま受け止めましょう。
その上で、「その懸念を解消するために、実はBという選択肢も検討したのですが…」と対話を広げます。このワンクッションがあるだけで、場全体の空気は非常に柔らかくなります。
③ 次のアクションと役割をその場でクリアにする
レビュー中に出たすべての指摘をそのままデザインに反映する必要はありません。レビューの最後、または議事録の確認時に、以下の3つのフォルダに指摘を分類して提示しましょう。
- 対応する項目：次のステップまでにデザインを修正するもの。
- 持ち帰る項目：他のデータや仕様を確認した上で、後日判断するもの。
- 見送る項目：今回のリリーススコープ外とする、または別の理由で現状維持とするもの。
受審者がこの分類を主導することで、「すべての指摘に振り回されてデザインが破綻する」のを防ぎ、デザイナーとしての設計責任を守ることができます。
まとめ：レビューは「チームで勝利する」ための最高のツール
デザインレビューを受審することは、決して「自分の作品を採点される試練」ではありません。むしろ、自分一人では気づけなかったユーザーの迷いや実装上の懸念を、チームメンバーが寄ってたかって一緒に解決してくれる「最高の協力プレイ」です。
「30-60-90ルール」を用いて議論を自らコントロールし、対話の作法を意識することで、レビュー会議はデザインの質を飛躍的に高めるパワフルな時間へと進化します。
チーム全員を「自分のデザインの共同制作者」として味方につけ、より良いプロダクトを届けていきましょう！
終わりに
最後までお読みいただき、ありがとうございます！
デザインレビューに対して漠然とした苦手意識や怖さを抱いていた方も、フレームワークを活用して「見せる範囲」を制限することで、少し気持ちが軽くなるのではないでしょうか。
私自身もレビューを受けるときは毎回緊張しますが、今回紹介したアプローチを意識するようになってからは、メンバーの意見を前向きに取り入れられるようになりました。
皆さんの次のデザインレビューが、より楽しく、建設的な時間になることを願っています。
それでは、良いデザインライフを！
