UI デザインレビュー
「きれいかどうか」ではなく、使いやすさの観点で問題を挙げる
以下は私の UI デザインの説明です：[説明]。ユーザビリティの観点でレビューし、問題を挙げてください：1）情報の階層は明確か、ユーザーが最初に目にするのは何か；2）主要な操作はすぐ見つけられるか；3）どこでユーザーが思い出す・推測する必要があるか；4）空状態・エラー状態・ローディング状態をそれぞれどう設計するか。配色が美しいかどうかは評価しないこと。
使い方
画面を機能一覧ではなく、ユーザーが出会う順に説明する。そうしないと、意図を評価されてしまう。
向いている場面
- 画面はもう動くが、ユーザーがどこで詰まるのか言葉にできない——階層・主操作・想起負担・3 つの状態という 4 つの問いで、具体的なコントロールと位置まで特定できる。見た目の調整を続けるより早い。
- レビュー会の前に、個人の好みが混ざらない問題リストがほしい——固定の 4 問を先に通せば、会議は「なんか良くない」ではなく事実を議論できる。
向いていない場面
- 機能の説明が一文しかなく、実際の画面・フィールド一覧・スクショがない——AI は一般的なベストプラクティスを評価するので、テンプレートを採点しただけになる。
- ブランドの視覚方向（高級に見えるか、調性に合うか）を判断したい——ユーザビリティレビューでは答えられない。ビジュアル要件書やブランド原則に切り替える。
例
入力
設定画面：上部にアバターとニックネーム、その下に 14 個のトグルがグループ分けなしで並ぶ。下部にグレーの「保存」ボタン、押さないと変更が失われる
得られるもの
階層の問題（14 個のトグルが無分组で、第一印象の優先順位がない）、主操作のリスク（グレーの保存ボタンは押せないように見える、自動保存もない）、想起負担（何を変えたかユーザーが覚えるしかない）を指摘。さらに不足していた 3 状態を補い、オフライン時はトグルを無効化して理由を示すべきとする。並び順はページの上から下ではなく「データが消える > 見つからない > 思い出す必要」の順。
よくある誤用
- 機能一覧を画面の説明として渡す（「検索・絞り込み・お気に入りがあります」）——評価できるのは機能リストだけで、コントロール・位置・状態には降りてこない。
- ついでに「もっと良く見える改訂版も」と頼む——ユーザビリティの結論が視覚の好みに汚染され、問題リストが審美投票に退化する。
こう変えると効く
- 「配色は評価しない」を「コントラストが 4.5:1 に達しているかは評価してよい」に変える——検証可能な視覚基準を 1 つ残し、美醜には触れないままにする。
- 末尾に「各問題に、ユーザーが何秒余計にかかるか、離脱するかを添える」を足す——問題リストがそのまま優先順位の根拠になる。