「デザインは主観だから、好みの問題」——この言い訳がレビューを無意味にする。
デザインレビューが「なんとなく気に入らない」「もっとポップに」という感想大会になっていないか。基準なきレビューは時間の無駄であり、デザイナーのモチベーションを削ぐ。
デザインレビューは基準に基づいた評価と建設的なフィードバックのプロセス。ユーザー視点、ビジネス視点、技術視点で評価し、改善につなげる。
1. 手法の定義
チームやステークホルダーがデザインを共同で評価し、問題点の発見と改善案の検討を行う協働プロセス。
ユーザーテストの代替ではなく、開発プロセスにおける品質ゲート。デザインシステムへの準拠、アクセシビリティ、一貫性などを確認する。
2. いつ使うか
適している場面
- 設計フェーズのマイルストーン: 次に進む前の品質確認
- デザインシステムの準拠確認: ガイドラインに従っているか
- チーム間の認識合わせ: デザイン・開発・PMの連携
- ステークホルダーの承認: 方向性の確認
向いていない場面
- ユーザーの実際の行動を見たい → ユーザビリティテスト
- 客観的な評価が必要 → ヒューリスティック評価
- 初期アイデアの発散 → ブレインストーミング
3. 設計判断の核
レビューは「感想」ではなく「基準に基づく評価」。
「好き/嫌い」ではなく「ユーザーにとって良い/悪い」で議論する。基準がなければ、声の大きい人の意見が通るだけ。
よくある誤解 「全員の意見を取り入れるべき」
実際 全員の意見を取り入れると、デザインは妥協の産物になる。最終判断はデザイナーまたはオーナーが行う。レビューは意見を集める場であり、民主主義で決める場ではない。
4. 調査タイプ
| 軸 | 内容 |
|---|---|
| データ | 定性（意見・フィードバック） |
| 対象 | デザイン成果物 |
| 参加者 | デザイナー、開発者、PM、ステークホルダー |
| 実施フェーズ | Design（設計の各マイルストーン） |
手法のポジション
評価者の客観性
↑
ユーザビリティテスト（実ユーザー）
↑
ヒューリスティック評価（UX専門家）
↑
デザインレビュー（チーム内）
→ 実施コスト（低→高）
デザインレビューはチームの視点で素早く確認できるが、実ユーザー視点の代替にはならない。
5. 実施プロセス
1. 準備
共有するもの
- デザイン成果物（ワイヤーフレーム、モックアップ、プロトタイプ）
- 背景・目的
- 評価基準
- フィードバックしてほしいポイント
事前共有
- 可能なら事前に資料を共有
- 参加者が準備してから臨む
2. レビューの進行
プレゼンテーション
- デザイナーが意図を説明
- 「なぜこうしたか」の根拠を示す
フィードバック収集
- 1人ずつ意見を聞く（声の大きい人に支配されないように）
- 批判ではなく建設的な提案
- 「問題」と「解決案」をセットで
議論
- 重要な論点を深掘り
- トレードオフを明確に
3. 記録
- フィードバックを文書化
- 対応方針を決定（採用/不採用/保留）
- 次のアクションを明確に
4. フォローアップ
- 修正を反映
- 必要に応じて再レビュー
6. 実務チェックリスト
最低ライン（Must - これがないと失敗）
理想ライン（Better - プロの品質）
7. 関連リンク
関連するUXリサーチ手法
関連するUX心理
- 確証バイアス
- 集団思考
関連する用語
まとめ
デザインレビューはチームでデザインを評価し改善につなげる協働プロセスである。「感想」ではなく「基準に基づく評価」を行う。全員の意見を取り入れるのではなく、意見を集めた上で最終判断はオーナーが行う。ユーザーテストの代替ではないため、チーム内レビューで「良い」とされても、実ユーザーで検証することを忘れてはならない。
