デザインレビューの準備：1枚の要件から判断できる案まで
レビューがうまくいかないのは、議論が足りないからではありません。目的、境界、そして本当の対立点が事前に整理されていないからです。この流れは、その作業を会議の前に移します。
進め方
ステップ1：絵を描く前に、要件を1枚にまとめる
「デザイナーへの要件書」を使い、対象ユーザー、この版で解くひとつの課題、あえてやらないこと、成功条件、制約を1枚に書きます。この1枚がないと、レビューは好みの多数決になりがちです。書き終えたら、他の人が読んで同じ判断ができるかを確認します。
ステップ2：要件をレビューできるデザイン仕様にする
「要件をデザイン仕様書にする」を使い、情報の階層、主要な状態、境界のケース、受け入れ条件まで広げます。まだ決まっていない箇所には印を付けさせてください。その印が当日の議題です。きれいな言葉で覆わないようにします。
ステップ3：まず自分でレビューし、明らかな問題を会議の前に潰す
「UI デザインレビュー」に案やスクリーンショットを渡し、階層、使いやすさ、状態の網羅性の観点で、重大度の順に問題を出させます。自分で直せるものは先に直します。明白な不具合は会議に持ち込まず、意見が分かれる点だけを持ち込みます。
ステップ4：反対側から突き、詰められそうな質問を3つ用意する
「反対側からの指摘」を使い、最も厳しいレビュアーを演じさせ、案の中で最も弱い前提だけを攻撃させます。鋭い質問を3つに絞り、それぞれに一言の回答と根拠を1つ付けます（利用者の発言、数値、競合の事例）。その場で答えられないものは、取り繕わず未決事項として記録します。
ステップ5：通った結論を、開発が使える仕様として渡す
「開発への間隔と階層の受け渡し」を使い、合意した階層、間隔、状態、動きを引き継ぎ用のメモにします。決まっていない部分は「未決」と明記し、誰が決めるかも書きます。そうしないと開発が独自の解釈で実装し、次のレビューが振り出しに戻ります。
使うプロンプト
よくある質問
デザインレビューの前に何を準備すればいいですか
目的と境界を書いた1枚の要件、指し示せるデザイン案、そして詰められそうな質問3つです。案は完璧でなくても構いませんが、判断には口に出して説明できる理由が必要です。
レビューでデザイナーと意見が割れたらどうしますか
好みではなく、成功条件と利用シーンに話を戻します。「反対側からの指摘」で双方の前提を並べ、検証できる部分だけをその場で決め、残りは検証方法を決めて持ち帰ります。
デザイナーがいなくて、自分で作ったプロトタイプしかありません
問題ありません。「デザイナーへの要件書」を自分向けの制約に置き換え、スクリーンショットや文章をそのまま「UI デザインレビュー」に渡します。状態の網羅性と階層の筋が通っているかを見ます。