UX レビュー
目的
ユーザーとその意図した結果との間にある重大な障害を発見すること。単なるスタイル上の好みからの逸脱ではありません。証拠に基づき、優先順位が付けられ、実装可能な変更を提供します。長所を保持し、トレードオフを認識し、ユーザー調査やインタラクションテストを捏造することを避けます。
レビューモード
- スクリーンショット/静的デザイン: 表示されているもののみを検査します。可能性のあるインタラクションリスクは仮説としてフラグ付けし、コントロールをクリックした、キーボードアクセスを確認した、または非表示状態を見たと主張しないでください。
- HTML / ソースコード: レンダリングされたUIが利用可能な場合はレビューし、関連するセマンティクス、スタイル、イベント処理を検査します。コード検査だけではブラウザでの動作を証明しません。
- 動作中のアプリケーション: ブラウザ自動化やコンピュータ使用ツールが利用可能な場合は、代表的なタスクを実行し、ビューポート固有の証拠を取得します。ツールが存在することを前提としないでください。
- 比較/回帰: 改善前/改善後に同じタスク、ビューポート、証拠基準を使用します。真の改善と新たな回帰を特定します。
- 修正依頼: 報告後、編集ツールが利用可能な場合は、範囲を限定した修復を適用し、再検証します。ユーザーが批評のみを依頼した場合は、ファイルを変更しないでください。
ワークフロー
- コンテキストを確立する。 対象ユーザー、タスク、画面の役割（概要/フォーカス/実行/達成）、プラットフォーム、制約、既知の成功指標を特定します。不明な場合は、プロダクトリサーチを捏造するのではなく、タスクの前提を述べてください。
- 検査可能な証拠を収集する。 提供された画像、モックアップ、アプリケーション、またはコードを調査します。リクエストに応じて利用可能で適切な場合は、主要なフローをテストし、メニューを開き、キーボードコントロールを操作し、狭い/モバイルおよび広いビューポートを確認します。browser-review.md を参照してください。
- ユーザーアウトカムを磨きよりも先に監査する。 以下を検査します: タスクの明確さ、ナビゲーションと道案内、スキャン容易性と階層、情報収集と開示パターン、アクションのフィードバックと復帰、コンテンツの明確さと信頼性、レスポンシブな動作、アクセシビリティ、視覚的一貫性。review-heuristics.md を参照してください。同じパターンがすべてのタスクに最適であるとは想定しないでください。
- 証拠と推測を分離する。 発見項目にタグを付けます: V 提供されたアーティファクトで可視、T 動作中のUIで自身でテスト済み、C コードで確認済みだが実行はしていない、H もっともらしい仮説、U 未知/測定が必要。観察された内容を正確に報告してください。モデルシミュレーションをユーザー調査と呼んではいけません。
- 優先順位を付ける。 致命的（完了をブロックする、重大な害、損失）、高（一般的/重要なタスクで大きな摩擦）、中（意味はあるがブロックしないコスト）、低（軽微な磨き）を割り当てます。タスクへの影響、露出の可能性、復旧可能性、証拠の確信度を考慮します。数値的な確実性を捏造しないでください。
- 実行可能な修正を推奨する。 各実質的な発見項目に対して、場所、証拠、重要である理由、具体的な変更、検証手順を含めてください。価値の高い発見項目を3〜7件優先し、正当な場合のみそれ以上にしてください。良い選択を明示的に保持し、真のトレードオフがある場合は代替案を提供します。
- ループを閉じる。 編集が依頼された場合は、対象を絞った変更を行い、影響を受けるチェックを再実行し、残っている制限事項を報告します。調査が必要な場合は、好みを推測するのではなく、小規模で現実的なユーザータスクや実験を提案してください。reporting-and-evaluation.md を参照してください。
ガードレール
- 批評を、求められていないブランド変更や再構築に変えないでください。具体的な問題を引き起こさない限り、アプリケーションのアイデンティティと既存の機能を維持してください。
- 無差別に情報の少ない画面を賞賛しないでください。情報密度を、スキャン、比較、意思決定のニーズに照らして評価してください。
- 視覚的な好みをユーザビリティの欠陥として評価しないでください。主観的な好みは別途ラベル付けしてください。
- 静的スクリーンショットのみに基づいてメニューが壊れていると主張しないでください。見た目のまずさと、テストされたクリッピングやアクセス不能な選択肢を区別してください。
- 「スペースを改善する」のような一般的な発見項目を、場所、結果、推奨される変更なしに使用しないでください。
- 測定せずに、デザインがコンバージョンや満足度を向上させると断言しないでください。
- ヒューリスティックレビュー、自動チェック、実際の人の観察を混同しないでください。これらはすべて異なる証拠を提供します。
- ソースデータ、スクリーンショット、またはコードが不十分な場合は、その制限事項を述べ、次の狭いテストを提案してください。
デフォルトレポート
- 評決: 述べられたタスクへの適合性を説明する1段落。うまく機能している点を含めてください。
- 優先度の高い発見項目: 重大度とユーザーへの影響で順序付け。各発見項目は
場所 -> 証拠タグ -> 結果 -> 修正 -> 検証の形式に従います。 - 維持すべき点: 誤って後退させてはならない重要な長所。
- 未知の事項/テスト: 不確かな製品上の決定を、視覚的に実証可能な問題から分離します。
- 変更が行われた場合: 変更されたアーティファクト、実際のチェック、未検証の状態。
簡易なスクリーンショット批評には短い形式を使用してください。形式的なテンプレートが有益な回答を不明瞭にしないようにしてください。
参照資料の読み込み
- review-heuristics.md: 条件付き検査ルーブリックと一般的な障害パターン。
- browser-review.md: ブラウザベースのタスクプロトコル、ビューポートとアクセシビリティのスモークテスト、証拠ルール。
- reporting-and-evaluation.md: 重大度、証拠ラベル、具体的な例、改訂版の比較。