デザインレビューの進め方：30分の議題と決定ログ

デザインレビューは意見を集める場ではなく、次の判断を決める場です。最初にユーザー課題と確認したい問いを一つに絞り、根拠、決定、次の担当者を同じ画面に残します。リモートチームなら、同じ画面を見ながらコメントできるUIデザインの共同作業環境が役立ちます。

会議の前に問いを決める

「デザインを見てください」ではなく、「初めての利用者が更新日を見つけられるか」のように問いを書きます。問いが決まれば、必要な根拠、参加者、完了の条件も決まります。探索、ユーザビリティ、開発準備では、比較・検証・不足状態の発見という目的を分けます。

問いを一つに絞る実例

サブスクリプション更新画面をレビューするなら、問いを「初回利用者が次回請求日と変更方法を30秒以内に見つけられるか」とします。プロダクト担当は分析データ、デザイナーは画面の意図、サポート担当は問い合わせ例を用意し、レビューの最後に「ラベルを変更して再テストする」か「現状を採用する」かを決めます。問いが複数ある場合は、会議を分けて判断が混ざらないようにします。

30分のレビューを四つの役割で進める

進行役は問いと時間を守り、デザイナーは意図を説明します。レビュアーは根拠からリスクを指摘し、記録係は決定を担当者と期限に変換します。0〜5分で条件を確認し、5〜15分で画面を一度通し、15〜25分で決定と実験を分け、最後の5分で次の証拠を決めます。

根拠と好みを分けて記録する

「320pxでエラー文が切れる」は根拠、「このアイコンは伝わらない」は仮説、「青が好き」は好みです。問い、決定、理由、次の確認という四列のログにすると、声の大きさで結論が決まりません。

レビュー結果の状態をそろえる

記録係は各項目を「採用」「検証が必要」「保留」「却下」のいずれかに置きます。「採用」は担当者と変更対象が決まった状態、「検証が必要」は仮説と確認方法が書かれた状態です。状態だけを付けて理由を残さない項目は、次の会議で同じ議論を繰り返すため完了扱いにしません。

レビューを変更履歴につなげる

決定ごとに変更するフレームやコンポーネントをリンクし、変更後にコメントを解決します。Pixsoではコメントとプロトタイプを同じファイルに置き、観察から画面変更までを追える形で共有できます。

変更前後とUndo/Redoの境界を確認する

レビュー後にフレームの見出しを変更し、コメントを解決してからUndoとRedoを一度ずつ実行します。見出しだけが戻り、解決済みコメントの状態や別フレームの変更まで巻き戻らないかを確認してください。Undo後に別の編集を始めた場合は、Redoできる範囲が変わることを記録し、レビュー結果を誤って再適用しない運用にします。

最後に変更後の状態を示し、未解決の点だけを次の検証へ送ります。よいレビューとは、会議を再生しなくても変更理由が分かる記録です。