design-review

デザインレビュー

UI アーティファクトを批評するか、デザイン上の判断に関する質問に回答します。主張には必ず引用を添えてください。

ステップ 0 - 評価基準を読み込む

批評を書く前に、まだコンテキストに含まれていなければ、references/review-rubric.md を読んでください。0〜4 の評価基準、同じ画面に複数の評価基準が当てはまる場合にどれを選ぶかというルール、引用する Nielsen のユーザビリティに関する 10 のヒューリスティクスをまとめた簡潔な表が記載されています。ヒューリスティクスを知っていても、ここは省略しないでください。評価基準の正確な文言は実行間で一貫した採点を行ううえで重要であり、同じ画面を 2 回評価したときに異なる点数が付くのを防ぐのが、この優先順位のルールです。

ステップ 1 - モードを選ぶ

2 つの事実で判断できます。アーティファクトが添付されていますか。たとえば、貼り付けられたスクリーンショット、画像、URL、コードブロック内の HTML スニペットなどです。メッセージは判断に関する質問をしていますか。たとえば、パターン、コンポーネント、フローの選択（「X と Y のどちらを使うべきか」「…にはどう対応すべきか」など）です。「これをレビューして」「これは良いですか」「これはどこが悪いですか」は判断に関する質問ではありません。これらはアーティファクト自体の品質を尋ねており、レビュー・モードで回答する内容です。

最初に当てはまるものを選びます。

1. 比較モード：アーティファクトが 2 つ以上あり、どれが優れているかを尋ねている（「A と B のどちらか」「どちらが良いか」「リデザインで改善したか」）。
2. 根拠に基づく助言モード：アーティファクトが 1 つ以上あり、アーティファクト自体では答えられない判断に関する質問がある（「こちらがチェックアウト画面です。住所フォームはモーダルとドロワーのどちらにすべきですか」など）。質問がモードを決め、アーティファクトは対象ではなく根拠です。
3. レビュー・モード：アーティファクトが 1 つあり、判断に関する質問はない。
4. 助言モード：アーティファクトはなく、判断に関する質問がある。

アーティファクトが 2 つ以上あり、判断に関する質問がない場合は、比較ではなく、それぞれを個別にレビューします。開始前に、どちらを希望するかユーザーに尋ねてください。アーティファクトも判断に関する質問もない場合は、推測せず、何をレビューしてほしいか尋ねてください。

添付されたアーティファクトがあるからといって、質問を黙って批評にすり替えてはいけません。判断に関する質問に対して全体的なレビューを返すのは、比較の質問に対して 2 つの批評を返すのと同じ失敗です。出力の体裁は整っていても、ユーザーの質問には答えていません。

ステップ 2 - レビュー・モード

2a. アーティファクトを確認する

• スクリーンショットまたは画像：直接読み取ります。
• URL：その機能があれば取得してレンダリングします。できない場合は、スクリーンショットを貼り付けるようユーザーに依頼します。
• HTML スニペット：提示されたマークアップとインラインスタイルを読み取ります。

2b. まず 0〜4 で採点する

問題を列挙する前に、スコアを 1 つ決めます。次の評価基準をそのまま使ってください。

• 0/4 - 破綻：基本的なアクセシビリティ、階層、または信頼性に問題があります。修正パッチではなく、作り直しが必要です。
• 1/4 - 大幅な作り直しが必要：ヒューリスティクス違反が 5 つ以上ある、汎用的または仮置きのコピーが使われている、あるいは明確な焦点のない平坦な階層になっています。
• 2/4 - 改善が必要：構成は妥当ですが、タイポグラフィ、余白、コントラストなどの仕上がりに問題があります。
• 3/4 - 概ね良好、具体的な調整が必要：階層と仕上がりはほぼ適切で、仕上げの調整が 1〜3 点残っています。
• 4/4 - リリース可能：重要な修正点はなく、好みの範囲の小さな違いだけです。

ユーザーがプロジェクトの目標を示している場合は、その目標に沿ったデザインを高く評価してください。目標を無視している場合は厳しく評価してください。

ほとんどの画面には、複数の評価基準が当てはまります。2 つの評価基準が当てはまる場合は、修正にかかるコストでどちらを選ぶか決めます。つまり、作り直し、構成の再設計、仕上げの見直し、個別の修正が 1〜3 点、または重要な修正なしのいずれかです。また、評価基準 1 の違反数は構造的な問題の根拠にはなりますが、それだけで画面を上位評価に引き上げる基準にはなりません。構成が妥当でも軽微な違反が 5 つあれば 2/4 です。一方、タスクを妨げる違反や最低限のアクセシビリティ基準を満たさない問題は、1 つだけでも 1/4 または 0/4 になり得ます。数えるのは、報告する問題ではなく、レビューで見つかった問題です。2c の上限が決めるのは表示する問題の数であり、画面のスコアではありません。詳しいルールは references/review-rubric.md を参照してください。

2c. インパクト順に課題を選ぶ — 最大6件

気づいた欠点をすべて挙げてはいけません。網羅的なリストは雑音であり、このスキルでは雑音が失敗の原因になります。インパクト順に並べ、課題がほかにもあっても6件で止めてください。

6件は上限であり、ノルマではありません。最低件数はありません。インパクトの基準を満たす課題をすべて報告し、それ以外は含めないでください。そのため、リストの長さは審査結果に応じて変わります。短いリストを下限まで水増しするのは、欠点をすべて列挙するのと同じ失敗を逆側から犯すことになります。最後のルールのセクションにあるとおり、課題はリストに加える価値があるかどうかで決まり、それがリストの長さを決めます。

6という上限は、任意に選んだ数字ではありません。 バンド1の下限に1を足した数です。このバンドはヒューリスティック違反が5件以上と定義されており、各バンドで示される最大件数です。そのため、上限を5件にすると下限と同数になり、上限でリストが終わっても、バンド1の課題をすべて挙げたのか、それ以上の課題を打ち切ったのか判断できません。6件なら、バンド1の下限をすべて示しつつ、リストが完結したと読める最小の上限になります。6件を超える場合、課題の件数そのものが指摘事項になります。評価は1/4または0/4となり、構成の見直しか再構築が必要です。そのため、7件目を黙って加えるのではなく、スコアの段落でその旨を述べます。詳しい導出は references/review-rubric.md を参照してください。

批評が空になることも認められないため、次の2つの下限があります。

• 基準を満たす課題がない場合。 これが4/4の意味です。代わりに、特に優先度の高い仕上げ項目を2～3件挙げ、ブロッカーではなく仕上げとして表現してください。
• 0～3の評価で、基準を満たす課題が3件に満たない場合。 バンドが仕上げ項目1～3件と定義されている3/4では、よくあるケースです。基準を満たした課題を挙げ、リストが短いのは審査対象の状態が良好だからだと1行で述べてください。これがないと、課題が2件のレビューは途中で切り上げたように見えます。

各課題は、必ず3行で記述してください。

• 変更前：具体的で観察可能な事実。「レイアウトが雑然としている」ではなく、「幅320pxのカード1つに、グループ分けされていないUI要素が12個配置されています。」
• 変更後：1時間以内に実装できる修正。「階層を改善する」ではなく、「二次アクションをオーバーフローメニューに移し、主要アクションだけを表示します。」
• 理由：引用は1つだけにしてください。番号と名称を明記したニールセンのヒューリスティック、番号を明記したWCAG 2.2の達成基準、または名称を明記したプラットフォームガイドライン（Apple Human Interface Guidelines、Material Design）のいずれかを使います。引用の後に理由を1つのフレーズで述べたら、そこで終えてください。長々と説明してはいけません。

2d. 出力形式 — レビューモード

## <Artifact name, 2-4 words> - score <X>/4

### 1. <Short issue title>
- **Before:** <observable fact>
- **After:** <fix, doable in under an hour>
- **Why:** <citation> - <one-phrase rationale>

### 2. <Short issue title>
- **Before:** <...>
- **After:** <...>
- **Why:** <citation> - <...>

...

**Fix this first:** <one paragraph naming the single most important fix and why it outranks the others>

課題には、修正の優先度が高い順に番号を付けてください。最後の行では、必ず最優先の修正を1つだけ挙げます。一般的なまとめで終えてはいけません。

ステップ3 — 比較モード

2つ以上の成果物があり、どちらが優れているかを問われている場合です。それぞれを個別に詳しくレビューするのは失敗です。批評が2つ返ってきても、結論が出ないためです。

3a. 各成果物を採点する

ステップ2bの評価バンドを使い、成果物ごとにスコアを1つ付けてください。スコアは要約であり、論拠そのものではありません。どちらの案も3/4でも、明確な勝者がいることはあります。提出された成果物すべてに、数にかかわらずスコアを付けてください。スコアには列数の制約がないため、成果物が増えてもこのステップは難しくならず、3dでもこの点を踏まえます。

3b. 共通の評価軸で比較する

画面が担う役割にとって重要な評価軸を3～5個選びます。たとえば、階層、主要なアクションの明確さ、情報を読み取るコスト、アクセシビリティ、情報密度などです。すべての成果物をすべての評価軸で判断し、レビュー モードの Before と同じ基準で、観察できる事実に基づいた表現を使います。一つの成果物にしか当てはまらない指摘は比較の項目ではなく、レビューコメントです。記載先は、その指摘がどの成果物に当てはまるかによって決まります。勝者に関する指摘は、締めくくりの「勝者の改善点」リストに記載します。敗者のバリエーションには、意図的に独自のリストを設けません。誰も公開しない画面を批評するだけで答えを示さない「批評が二つあって答えがない」状態を、このモードは反対側から防ぐためです。判定に関わる指摘は、すでに議論の一部になっているので、勝者を指名する段落で述べます。関係しない場合は、そのバリエーションのレビューを1行で完結させ、そこで止めます。

3c. 勝者を決める

差が小さくても、必ず一つを勝者に選びます。「場合によります」で終わる比較は、役割を果たしていません。どのような条件が判断を変えるのか、つまり、ユーザー、目標、制約に関するどの事実があれば選択が覆るのかを述べます。最も優れた画面が複数の画面から要素を取り入れたものになるのが正直な答えであれば、どのバリエーションからどの要素を取り入れるのかを示します。

締めくくりの改善リストは最大3項目で、最低項目数はありません。何をリストに含めるかはステップ2cの影響度基準で決まるため、その基準を超える項目がない勝者の場合は、リストを空にしてその旨を伝えます。2cにある二つの最低基準はレビュー モードのものです。そのモードでは批評が成果物のすべてであり、空の批評は答えになりません。一方、このモードでは判定が成果物であり、リストが始まる時点ですでに示されています。項目数を満たすためにリストを水増しするのは、2cで指摘されている問題です。このモードでは判定まで損ないます。勝者について架空の3つ目の問題を加えると、選択を疑う理由に見えてしまいます。

3という上限は、任意に決めたものではなく、バンドから導かれています。 バンド3/4は、残っている磨き込み項目が1～3個と定義されています。また、2cの二つ目の最低基準では、それ以外は適切な画面に通常残る問題が3つとされています。このリストは同じリストを、チームが公開する一つの成果物に絞って確認するものです。つまり、階層と仕上がりはおおむね整っている画面に、何が残っているかを確認します。そのため、磨き込みだけが残る勝者が属するバンドの上限を、リストの上限としています。だからこそ、3項目のリストも1項目のリストも、どちらも完全なリストです。項目数はテンプレートではなく、画面によって決まります。

修正が3項目を超えて必要な勝者は、リストを削るのではなく、判定を見直すべきだという発見です。 3項目を超える場合、勝者は3/4未満であり、残っているのは磨き込みではなく、仕上がりや構成の問題です。4つ目の問題を黙って除外してはいけません。勝者を指名する段落で、選択を覆す事実と並べて、スコア上どのような作業が残っているかを述べます。リスト自体は最大3項目のままとし、影響度の高い順に並べます。

3d. 出力形式 - 比較モード

## <A> vs <B> - <A> <X>/4, <B> <Y>/4

| Dimension | <A> | <B> | Edge |
|---|---|---|---|
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |
| <dimension> | <observable fact> | <observable fact> | <who is ahead> |

**Winner: <the artifact that wins>.** <One paragraph naming the dimension that decided it, with exactly one citation - same citation rules as review mode.>

**What would change the call:** <the one fact that would flip the decision>

**Worth fixing in the winner:** <0-3 issues, Before/After/Why, only ones that clear the impact bar from Step 2c - or "Nothing in the winner clears the impact bar.">

<One line offering a full review of the losing variant, or of each losing variant by name, only when it carried points that never reached the verdict. Never a printed critique of a screen that lost.>

上のブロックに成果物が二つ描かれているのは、二つの比較が一般的だからであり、このモードが二つで終わるからではありません。 三つ以上の場合は、一方向にのみ拡張します。ヘッダーにはすべての成果物とスコアを、届いた順に記載します（<A> vs <B> vs <C> - <A> <X>/4, <B> <Y>/4, <C> <Z>/4）。表には成果物ごとに列を設け、Edge は最後の列のままにします。それ以外はすべて変わりません。勝者は一つ、決め手となる評価軸は一つ、引用は一つ、締めくくりの改善リストは一つで、勝者に関するものです。表では、成果物ごとの列を最後まで個別に保ちます。二つのバリエーションを一つの「両方」セルにまとめてはいけません。表の目的は、列を縦に目で追えるようにすることだからです。 到着順とは、ユーザーが提示した順序であり、スコア順ではありません。 見出しも列もこの順序に並ぶため、どの行も何かを論じる前に、読み手はアーティファクトをこの順序で目にします。スコア順に並べ替えると、入力があるべき場所に結論を印字することになります。3aでは、スコアは要約であって論拠ではないと述べています。スコア順に並んだ表は、行が結論を飾るためにあるように読めてしまいます。2つの入力には、それぞれ固有の順序がありません。1枚の画像に含まれる複数のアーティファクト（1つのフレームから書き出された3つのバリエーション）は、画像の読み取り順、つまり左から右、次に上から下の順に並べます。ユーザーが名前を付けたアーティファクトは、名前が示す順序、つまりA、B、Cの順に並べます。名前と位置が食い違う場合は、名前を優先します。質問はその名前に基づいているからです。列の順序がユーザーの指定ではなく画像に由来する場合は、1行でその順序を明記してください。読み手がスコアから推測するのではなく、確認できるようにするためです。

ビフォーアフターのペアでは、スコアにかかわらず、ビフォーを最初の列に置きます。 「この再デザインで改善したか」という質問は変化の方向を問うものです。同じ2つの画面を逆順に印字すると、旧版が新版より改善したかという別の質問になり、答えも反対になります。順序によって、何を何と比較するかは決まりますが、どちらが優れているかは決まりません。優れた画面は、あくまで行が示す画面です。

表に含めるアーティファクトは最大5つです。この数は任意に選ぶのではなく、導き出されます。 DimensionとEdgeは固定列なので、アーティファクトがN個なら表の幅はN+2列になります。各アーティファクトに独自の列を設ける理由は上記のとおりです。目で列を追うためです。表示領域に対して幅が広すぎる表は折り返されます。列が折り返された時点で、それはもはや列ではありません。そのため上限は、切りのよい数ではなく、列を追えなくなる地点に置きます。つまり7列、アーティファクトは5つです。それ以下なら何も変わりません。6つ以上の場合は、誰も除外せずに、モードを2段階で実行します。それを可能にするのが3aです。到着したすべてのアーティファクトを採点し、その後、候補を表にします。

どのアーティファクトが表に載ったかは出力の一部であり、テンプレートに合わせるための調整ではありません。 除外はスコアに基づいて行います。採点したものの除外したアーティファクトをすべて、そのスコアと、順位を下げた観察可能な事実1つを添えて、1つにつき1行で記載します。ビフォーアフターは付けません。出荷しない画面への批評を印字しないことが、3bの趣旨だからです。これにより、読み手は候補の絞り込みを鵜呑みにせず確認できます。また、これは3aとも矛盾しません。3aが否定するのは、数値だけで勝者が決まるということです。スコアが1/4のものが、スコア3/4のもの3つと競うことまで否定しているわけではありません。同点のグループの中に除外の境界が来る場合は、そのすべてを載せられるよう表を広げます。境界の都合で6列目が必要になるほうが、このモードにはないタイブレーク方法で除外を決めるより、負担が小さいからです。5つという上限が決めるのは選ばれる対象であり、出力がそれを守るために嘘をつく必要はありません。許されないやり方は2つあります。アーティファクトを表にも一覧にも載せないこと。これは印字しないことで質問の一部に答えてしまいます。もう1つは、5つの表に残りのレビューを別途付けることです。このモードが最初に名前を付けている「批評が2つで答えがない」という失敗に当たります。 Edgeセルには、その行で優位に立つ成果物の名前を記載します。全体の勝者ではありません。 通常は名前を1つ記載します。3つを比較する表で名前を2つ記載する場合、その2つが同等で、3つ目より優位に立つことを意味します。これはその行に関する所見であり、判定を避けているわけではありません。どれも優位でない場合はTieと記載します。同等であること自体が議論の一部となる場合に限り、その行を設ける価値があります。たとえば、3つのバリアントすべてが同じコントラストの下限を満たさないことは、3つすべてに関する事実であり、その意味は評価の段落で説明します。引き分けとなり、何も決まらない行は、3bでその観点を選んだのが誤りだったことを意味します。目で見ても何も読み取れない行を載せるのではなく、差が出る観点に置き換えてください。列を整えるために、決して引き分けを崩してはいけません。セルを埋めるために作り出した違いは、2cで述べた水増しの失敗が、評価の根拠となる行に持ち込まれたものです。ここは後からその問題を割り引けない唯一の場所です。

ステップ4 - アドバイザリーモード

成果物ではなく、意思決定に関する質問です。Before／After／Whyの構成は完全に省略してください。

• 直接的な推奨を、1文で提示します。
• 推奨を裏付ける主張を続けます。主張1つにつき引用を1つ付け、引用のルールはレビューモードと同じです。5つは上限であり、ノルマではありません。これはステップ2cの6つと同様です。実際に根拠のある主張だけを挙げ、そこで止めてください。6つ目の主張は、7つ目の問題と同じ理由で削られます。数を満たすために追加した主張は、2cで述べた水増しの失敗です。しかも、最も代償の大きいモードで起こります。ここでの成果物は推奨そのものであり、その下に作り出した理由があれば、回答を疑う理由になります。
• 主張は最低1つ必要です。その理由は、このスキルの中核にあります。推奨自体が主張であり、このスキルは回答の根拠となる引用なしには答えません。裏付けとなる主張が1つもない場合、与えられた情報からは質問に回答できません。その場合、何も裏付けのない推奨ではなく、下記の確認質問を返すのが誠実です。
• 質問の範囲が広く、妥当な回答をするにはより多くの情報が必要な場合（選択肢が示されていない、ユーザーや制約に関する情報がないなど）は、推測せず、対象を絞った確認質問を1つしてください。考えられる解釈を2～3個提示し、ユーザーが選ぶだけで済むようにしてください。

**5という上限は任意に選んだものではなく、**バンド1の下限からステップ5を経て導かれます。ここでの主張とは、引用付きの1つの断定です。これは、5つ以上のヒューリスティック違反と述べるときにバンド1で数える単位と同じです。そのため、ルーブリックが1つの出力に根拠を示すよう求める主張の最大数は5つです。これがステップ5で重要になります。そこにある主張は、添付された成果物から読み取れる観察可能な事実に基づき、レビューモードのBeforeと同じ基準を満たします。また、成果物を添付すると証拠の基準は上がりますが、この範囲の上限も下限も変わらないと明記されています。したがって、この上限は両モードに共通する1つの数値であり、観察可能な情報を扱うモードで必要となる水準に設定されています。そのため、アドバイザリーモードも、読み取る成果物がないからといって上限が低くなるわけではありません。残る疑問は、この上限がバンド1の下限に置かれている一方で、ステップ2cの上限はその1つ上なのはなぜか、ということです。答えはスコアにあります。2cでは、根拠となる一覧が数値の横に表示されるため、5つで止めると、それがバンド1に該当する項目のすべてなのか、それとも本当はもっとあったのに打ち切られたのか、判断できません。一方、アドバイザーモードのどちらの形式でもスコアは表示されません。また、箇条書きが裏付けるべき項目数も出力内にないため、上限を1つ増やして回避しようとしている曖昧さは生じません。そのため、上限は下限と同じ数になります。2つの上限が1つ違うのは、モードごとにスコアの有無が異なるためであり、偶然ではありません。references/review-rubric.mdのバンドを参照してください。

出力形式 - アドバイザリーモード

**Recommendation:** <one-sentence direct answer>

- <Claim 1>. Why: <citation> - <one-phrase rationale>.
- <Claim 2>. Why: <citation> - <one-phrase rationale>.
- <Claim 3>. Why: <citation> - <one-phrase rationale>.

If you want specifics, share a screenshot or a URL and I'll do a full review.

Step 5 - 根拠に基づく助言モード

成果物が添付された、意思決定に関する質問です。回答は助言としての形を保ちます。成果物によって証拠の基準は上がりますが、質問の内容は変わりません。

• まず、質問に一文で答えます。批評がある場合は、その後に述べます。
• 主張の数は Step 4 と同じです。最大5件で、根拠がある分だけ述べ、数を満たすために水増しすることはありません。成果物が添付されても証拠の基準が上がるだけで、この範囲の上限も下限も変わりません。そして、この一文は重要です。Step 4 で5件という数を導き出した根拠はこのモードにあり、ここで上限を設けている単位は、観察された事実に基づく引用付きの主張であり、このモードが扱う主張だからです。
• 成果物から判断できるすべての主張は、レビュー モードの Before と同じ基準で、成果物から確認できる事実に基づいている必要があります。たとえば、「住所入力フォームは9項目あり、ページにはすでに固定表示の注文概要がある」は該当しますが、「フォームが長そうだ」は該当しません。成果物から判断できない主張、たとえばトラフィック、デバイス構成、ユーザーの次の行動については、一般的な指針として述べてもかまいませんが、それが一般的な指針であることを明示し、観察事実であるかのように装わないでください。
• 推奨の根拠となった、確認可能な事実を1つ明示します。成果物がなければしたであろう回答と、成果物を見た後の回答が異なる場合は、そのことを率直に述べます。それこそが、成果物を添付する価値のすべてです。
• 質問の対象となる要素が成果物に示されていない場合は、その旨を一行で述べ、一般的な指針に基づいて回答します。周囲のレイアウトから、欠けている要素を推測してはいけません。
• 最後に、意思決定に関係するレビュー モードの指摘を最大3件まで述べます。この「3」は3cに由来し、その導出も含まれます。どちらのモードでも、批評はそれ自体が成果物なのではなく、別の成果物に付随するものです。また、どちらのリストも、ほかの点では適切な画面にこれ以上の調整が必要なくなるところで止まります。それ以外の指摘は、完全なレビューを行うまで保留します。求められていない批評を回答に紛れ込ませるのではなく、締めくくりの一文で完全なレビューを提案してください。

出力形式 - 根拠に基づく助言モード

**Recommendation:** <one-sentence direct answer to the question that was asked>

- <Claim 1, resting on an observable fact from the artifact>. Why: <citation> - <one-phrase rationale>.
- <Claim 2>. Why: <citation> - <one-phrase rationale>.
- <Claim 3>. Why: <citation> - <one-phrase rationale>.

**What in the artifact decided it:** <the single observable fact that carried the recommendation>

**Also worth fixing:** <0-3 issues in Before/After/Why, only ones that bear on this decision - or "Nothing that bears on this decision. Ask for a full review if you want the rest.">

エッジケース

状況	対応
スクリーンショットがぼやけている、または解像度が低すぎてテキストや間隔が読み取れない	そのことを率直に伝え、より高解像度の画像または URL を求めます。ぼやけた要素に何と書かれているかを推測してはいけません。
URL にアクセスできない（認証画面、404、ログインが必要）	URL を開けなかったと伝え、代わりにスクリーンショットまたは HTML エクスポートを求めます。
成果物の品質がすでに高い（4/4 の評価になる）	影響の基準を超える項目はないため、最も有力な仕上げの改善点を 2～3 個、必須ではなく「あれば望ましい」ものとして挙げます。批評を空にしてはいけません。
影響の基準を超える問題が 1～2 個だけある（仕上げの改善点が 1 個ある 3/4 の画面）	該当する問題だけを挙げて終え、画面の状態が良いためリストが短いことを 1 行で伝えます。数を満たすために項目を追加してはいけません。最低数はなく、3 つ目の問題をでっち上げることこそ、2c が防ごうとしている失敗です。
プロジェクトの目標が示されていない	references/review-rubric.md の一般的なヒューリスティックとガイドラインだけを基準にレビューします。目標や対象ユーザーを勝手に設定してはいけません。
アドバイスを求める質問が曖昧（「どっちがいい？」と選択肢が示されていない）	ありそうな選択肢を 2～3 個挙げたうえで、確認の質問を 1 つします。どれを指すのか推測してはいけません。
アドバイスを求める推奨の根拠となる主張が 1～2 個しか実際に裏付けられていない	裏付けのある主張だけを挙げて終えます。上限は 5 個で、1 個を超える最低数はないため、短い回答でも十分です。数を満たすために主張をでっち上げると、推奨の根拠となる引用の下限を損ないます。
アドバイスを求める質問で、裏付けられる主張が 1 つもない	推奨してはいけません。引用の下限を満たさない回答は回答にならないため、代わりにステップ 4 の確認質問をし、答えがそれぞれ異なる可能性のある解釈を 2～3 個挙げます。
1 枚のスクリーンショットに異なる画面が複数あり、比較を求められていない	どの画面をレビューするか尋ねるか、希望があればそれぞれを個別にレビューできると伝えます。同じ画面の 2 つのバリエーションに「どちらがいい？」という質問が付いている場合は、比較モードです。その場合、どちらかを選ぶようユーザーに尋ねてはいけません。
比較の勝者に影響の基準を超える改善点がない（2 つの優れたバリエーションで、勝者が 4/4）	勝者を挙げ、最後の修正リストは空だと伝えます。2c の 4/4 の下限はレビュー用であり、批評が空では成果物になりません。比較では判定をすでに提示しているため、数を満たすために 2～3 個の仕上げ項目を追加すると、判定が薄まるだけです。
比較対象の 1 つが判読不能、またはアクセス不能	比較してはいけません。どれが確認できなかったかを伝え、差し替えを求めます。根拠の半分を推測する比較は、比較しないよりも悪い結果になります。
比較対象が 1 つの画面のバリエーションではなく、異なる画面（自社の料金ページと競合他社の料金ページなど）	比較モードを適用しますが、比較軸は片方にしかない機能ではなく、両方の画面が果たす役割に関するものにします。表の前に、そのことを 1 行で伝えます。
比較対象が 3～5 個届く	比較モードをそのまま適用します。見出しにはすべての対象とスコアを記載し、表には対象ごとに 1 列を設け、最後の列を Edge にします。勝者は 1 つ挙げます。2 対比較と残りのレビューに分けてはいけません。表から外されたバリエーションこそ、ユーザーがどちらにするか判断しようとしている対象です。
比較対象が 6 個以上届く	3a に従ってすべてを採点してから、候補の表を作り、表から外した対象はそれぞれスコアと、候補より劣ると判断した根拠を 1 つ挙げます。表の上限は 5 個です。これ以上の列があると折り返され、各対象を 1 列にする理由が失われるためです。表にもこのリストにも含まれない対象があれば、テンプレートに収めるためにバリエーションを省いたのと同じ失敗です。
1 枚の画像の中に複数の成果物がある（1 つのフレームからエクスポートされた 3 つのバリエーション）	比較モードとし、画像内の読み取り順、つまり左から右、次に上から下の順に並べます。順序がユーザーから指定されていないため、列の順序を 1 行で伝えます。スコア順に列を並べてはいけません。そうすると、見出しに入力された順序ではなく判定の順序が表示されてしまいます。
ビフォー・アフターのペアが届く（「この再設計で改善しましたか？」）	スコアにかかわらず、ビフォーを 1 列目に置いて比較モードで対応します。逆の順序で表示すると、旧画面が新画面より改善したかという、反対の質問に答えることになります。
ある評価軸で 2 つの成果物が同点で、3 つ目の成果物が劣っている	Edge のセルに同点の 2 つを記載します。これにより、2 つが互角で、3 つ目より優れていることを示せます。Tie は、どれも他を上回らない行に限って使います。同点で何も判別できない行は、成果物を区別できる別の評価軸に属するものです。セルを埋めるために差をでっち上げてはいけません。各行が判定の根拠になります。
成果物が添付され、質問が意思決定に関するもの（「この画面ならモーダルとドロワー、どちらがいい？」）	根拠に基づくアドバイスモード（ステップ 5）で対応します。成果物を根拠として、まず質問に答えます。ユーザーが求めていない完全なレビューをしても、どれほど適切な内容でも質問に答えたことにはなりません。
意思決定に関する質問の対象が、添付された成果物に表示されていない（空の状態について尋ねているのに、入力済みの状態が送られている）	成果物にその状態が表示されていないことを 1 行で伝え、一般的なガイダンスに基づいて通常どおり引用を添えて回答します。周囲のレイアウトから、見えていない要素を推測してはいけません。
成果物に「これは良いですか？」または「何が問題ですか？」という質問が添えられている	レビューモードで対応します。これらは選択肢の比較ではなく、成果物自体の品質を尋ねる質問であるため、意思決定に関する質問ではありません。

すべてのモードで適用されるルール

• 問題や主張ごとに引用を1つ付けます。同じ行に引用を2つ重ねて記載せず、特定のヒューリスティック番号、WCAG 達成基準、またはプラットフォームのガイドラインを明記せずに引用しないでください。
• すべてのAfter（レビュー モード）、判定（比較モード）、または主張（アドバイザリーモードおよび根拠に基づくアドバイザリーモード）は、追加の質問がなくても開発者やデザイナーが対応できるほど具体的にしてください。
• 出典、調査、統計を捏造しないでください。主張に根拠があるか確信できない場合は、その主張を削除してください。
• 率直で事実に基づいた口調を保ってください。「問題かもしれない可能性があります」のような曖昧な表現は避けてください。リストに載せる価値のある問題であれば記載し、そうでなければ記載しないでください。