evaluate

評価 — UX 品質の評価

概要

構造化された UX 評価を実施し、具体的で重要度を付けた実行可能な指摘事項を提示します。「ナビゲーションに違和感がある」と誰かが言い、全員がうなずくような曖昧なデザインレビューではありません。確立されたヒューリスティックに照らして体験を検証し、タスクを一つずつ進め、操作を誘導するパターンを確認し、ユーザーが実際に目的を達成できるかを測定する体系的な手法です。

提示する指摘事項にはそれぞれ、問題の内容、発生箇所、重要な理由（ユーザーへの影響）、対処方法（どの Intent スキルを活用するか）の4つを含めます。Intent システムの診断の入り口として、問題を特定して優先順位を付けたうえで、それぞれの修正を担う専門スキルへ振り分けます。

優れた点も特定します。評価は批判だけではありません。強みを把握することは、問題点を把握することと同じくらい重要です。再設計の際にチームが維持すべき要素や、ほかの場所にも展開すべきパターンがわかります。

このスキルを使うタイミング： デザインレビュー、UX 監査、リリース前の評価、リリース後の品質確認、競合 UX 分析、アクセシビリティ監査、ダークパターンの検出、または「この体験の品質はどの程度か」という問いに、率直かつ構造的に答える必要があるとき。

スキルファミリー

Evaluate は、他のすべてのスキルに振り分けるため、Intent システムの中でも独特です。担当するのは診断と優先順位付けであり、改善策の実施は各専門スキルが担います。

• /organize — ナビゲーションがわかりにくいですか？ユーザーが必要な情報を見つけられませんか？情報アーキテクチャが不明瞭、または一貫していませんか？分類体系、ナビゲーション構造、コンテンツ階層の改善には、/organize に振り分けます。

• /articulate — コピーがわかりにくいですか？ラベルが曖昧ですか？エラーメッセージが役に立ちませんか？説明がわかりにくいですか？コンテンツ戦略、トーン、UX ライティングには、/articulate に振り分けます。

• /journey — フローに問題がありますか？タスクの途中でユーザーが離脱しますか？手順の順番に違和感がありますか？インタラクションモデルがユーザーのメンタルモデルに合っていませんか？フローの再設計とインタラクションの順序の改善には、/journey に振り分けます。

• /fortify — エッジケースで失敗しますか？空の状態が役に立ちませんか？エラーからの復旧手段がありませんか？読み込み状態がありませんか？初回利用時の体験が軽視されていますか？レジリエンス設計と状態の網羅には、/fortify に振り分けます。

• /include — アクセシビリティに問題がありますか？キーボードナビゲーションが機能しませんか？スクリーンリーダーでの利用体験が考慮されていませんか？色のコントラストが不十分ですか？タッチターゲットが小さすぎますか？アクセシビリティの方法論とインクルーシブデザインには、/include に振り分けます。

• /blueprint — システムアーキテクチャに問題がありますか？UX の問題の原因が、サービスへの依存関係、チーム間の引き継ぎ、またはバックエンドの制約にありますか？システム分析と構造の再設計には、/blueprint に振り分けます。

• /measure — 指標が定義されていませんか？体験が成功しているか判断する方法がありませんか？成功基準がない、または適切でない項目を測定していますか？指標のフレームワークと測定戦略には、/measure に振り分けます。

• /investigate — さらなる調査が必要ですか？評価によって、ユーザーに話を聞かなければ答えられない疑問が見つかりましたか？調査の計画と実施には、/investigate に振り分けます。

• /strategize — 問題の定義が不明瞭ですか？体験はよくできているように見えるものの、対象とする問題が間違っていますか？5 つの基礎的な問いがまだ問われていませんか？戦略の再構成には、/strategize に振り分けます。

• /specify — 調査結果をエンジニアリング仕様にする必要がありますか？改善に詳細な引き継ぎドキュメントが必要ですか？実装にすぐ使えるドキュメントの作成には、/specify に振り分けます。

• /philosopher — 何かがおかしいと感じるものの、言葉にできませんか？技術的には問題のない体験なのに、感情に訴えるものがありませんか？デザインは優れているのに、印象に残りませんか？診断する前に、その違和感と向き合うには、/philosopher モードに入ります。

• ダークパターンが検出されましたか？ — 該当するパターンを明示し、Intent のアンチパターンカタログを参照して、重大度を割り当て、規制上の影響を記載します。ダークパターンの調査結果は、常に P0 または P1 です。体験の低下にとどまらず、ユーザーに危害を与えるおそれがあるためです。

適切に振り分ける： 評価で 6 つのカテゴリにまたがる 12 件の問題が見つかった場合、単に列挙するだけではいけません。改善を担当するスキルごとに整理し、各グループ内で優先順位を付け、チームが改善を進める順序を明確に示します。目指すのは、問題の羅列ではなくロードマップです。

---

ストーリーテリングのパターン：失敗点に適用する主人公のアーク

デザインを評価するときは、ストーリーテリングの規律における protagonist-arc パターンを用います。ただし、ユーザーのストーリーが成功する場所ではなく、途切れる場所に適用します。

目標： 共感です。ヒューリスティック上の問題だけでなく、ユーザーが実際につまずく箇所をチームに実感してもらいます。

構成： 正式な主人公のアークと同じく、目標を持つユーザー、段階、緊張、転換点を描きます。ただし、分析では次の点に焦点を当てます。

• ユーザーのストーリーはどこで途切れますか？ アークが崩れるのは、どのステップですか？
• どの目標状態に到達できませんでしたか？ 具体的に述べてください。「ユーザーが混乱した」ではなく、「住所の検証で有効な海外の郵便番号が拒否され続けたため、ユーザーはチェックアウトを完了できなかった」のように記述します。
• その破綻をユーザーはどのように感じますか？ フラストレーション、利用の断念、競合への乗り換え、サポートへの電話など、失敗したアークの感情的な結末を捉えます。

避けるべき病理： 正式なパターンと同じく、誤った一貫性です。根底にあるデータでは、3人のユーザーがそれぞれ異なる方法でつまずいているのに、「ユーザーはXに苦労した」と一つにまとめてしまうことです。ばらつきを示してください。

これが重要な理由： ヒューリスティック評価に合格しても、デザインがユーザーを裏切ったときにユーザーが実際にどう感じるかを見逃すことがあります。失敗に適用するアークは、評価結果をユーザーの実体験につなげます。問題の一覧を、チームのデザインが本来支援するはずだった人々をどこで失ったのかを伝えるストーリーに変えます。

実践での語り口：

「評価では、重大度の高い問題が3件特定されました。ユーザーのチェックアウト体験がどこで途切れるのかを示すストーリーとして、これらを捉え直してみましょう。どの問題がユーザーに最大の損失をもたらすかが分かれば、チームの関心も高まり、優先順位も明確になります。」

パターンライブラリと基本姿勢の詳細については、storytelling を参照してください。

---

主な機能

1. ヒューリスティック評価

Nielsen のユーザビリティに関する10のヒューリスティックを、体系的な評価フレームワークとして適用します。各ヒューリスティックについて、エクスペリエンスを体系的に調べ、証拠を添えて具体的な違反を記録し、各違反を重大度尺度の P0〜P3（以下の出力形式で定義）で評価したうえで、そのヒューリスティックの判定を示します。

各ヒューリスティックの判定（言葉で表記）： 問題なし（指摘事項なし、またはP3の微調整のみ）。要注意（最悪の指摘がP2：ユーザーが対処できる摩擦）。破綻（P0またはP1の指摘が少なくとも1件ある：タスクを妨げる、危害をもたらす、または規制に違反する）。判定を決めた指摘事項を明記してください。判定は数値ではなく言葉で示します。自らの判断を合算すると、実際にはない精度をレポートに与えてしまうためです。

適用する10のヒューリスティック：

H1：システムの状態を視覚的に伝える。 システムは、適切なフィードバックを妥当な時間内に提供し、何が起きているかを常にユーザーに知らせる必要があります。確認する項目：待機中のローディングインジケーター、複数ステップのプロセスにおけるプログレスバー、操作後の確認、現在の状態（選択済み、有効、保存済みなど）の明確な表示。よくある違反：送信しても反応がない（ユーザーが「保存」をクリックしても、目に見える変化が何もない）、API呼び出し中にローディング状態が表示されない、切り替え状態が曖昧、確認なしで送信されるフォーム。

H2：システムと現実世界を一致させる。 システムは、システム寄りの用語ではなく、ユーザーにとってなじみのある言葉、表現、概念を使って話す必要があります。確認する項目：ラベルや説明で使われる自然な言葉、情報の論理的な順序、ユーザーの期待に合ったメタファー。よくある違反：エラーメッセージに開発者向けの専門用語を使う（「Error 403: Forbidden」）、データベースのフィールド名をラベルに使う（「created_at」）、出現頻度順のほうが適切なのにアルファベット順に並べる、内部知識がないと意味が分からないアイコン。 H3：ユーザーの主導権と自由。 ユーザーは誤って操作することが多く、明確に示された「緊急退出手段」が必要です。確認する項目：元に戻す機能、処理中のキャンセルボタン、状態を維持する「戻る」ナビゲーション、システムが開いたものを閉じたり、表示を消したりできる機能。よくある違反例：削除後に元に戻せない、複数ステップのフローに「戻る」ボタンがない、Escape キーで閉じられないモーダル、サポートに連絡しないと取り消せない操作。

H4：一貫性と標準。 異なる言葉や状況、操作が同じ意味なのかどうかを、ユーザーに考えさせてはいけません。確認する項目：用語の一貫性（同じ操作にはどこでも同じラベルを使用）、操作パターンの一貫性（ビューが異なってもボタンの動作が同じ）、プラットフォームの慣習の尊重。よくある違反例：同じ操作なのに、ある場所では「保存」、別の場所では「送信」と表示される、ページごとに異なるナビゲーションパターン、正当な理由もなくプラットフォームの慣習を無視した独自の UI。

H5：エラーの予防。 優れたエラーメッセージを表示するよりも、問題を未然に防ぐ慎重な設計のほうが優れています。確認する項目：破壊的な操作の確認ダイアログ、送信前のインライン検証、無効な入力を防ぐ制約、エラーを減らすスマートなデフォルト値。よくある違反例：削除前の確認がない、送信時にしか検証せずインライン検証がない、選択式にすればエラーを防げるのに自由記述フィールドを使用する、文字数制限を超えるまで制限が表示されない。

H6：想起ではなく認識。 オブジェクト、操作、選択肢を見えるようにして、ユーザーの記憶への負担を最小限に抑えます。確認する項目：表示された選択肢（メニュー、ドロップダウン、候補）、最近使った項目や履歴、状況に応じたヘルプ、アイコンのラベル。よくある違反例：ツールチップのないアイコンのみのツールバー、閲覧手段のない検索のみのナビゲーション、ユーザーが覚えておかなければならない参照番号、現在の値がわからない設定ページ。

H7：柔軟性と効率性。 初心者には見えないアクセラレーターを使うことで、熟練ユーザーの操作を速められる場合があります。確認する項目：キーボードショートカット、一括操作、カスタマイズ可能なワークフロー、保存された設定、初心者の使いやすさを損なわないパワーユーザー向け機能。よくある違反例：頻繁に行う操作にキーボードショートカットがない、リスト管理で一括操作ができない、既知のステップをスキップできない強制的な直線フロー、デフォルト値を設定する方法がない。

H8：美的でミニマルなデザイン。 インターフェースに情報が増えるたびに、関連情報と競合し、その相対的な視認性が低下します。確認する項目：明確な視覚的階層、コンテンツの優先順位付け、効果的な余白の活用、状況に応じた関連情報のみの表示。よくある違反例：すべてを一度に表示する煩雑なダッシュボード、同じ画面上で競合する複数の行動喚起、コンテンツの妨げになる装飾要素、テーブルやリストでの情報過多。

H9：ユーザーがエラーを認識、診断し、回復できるようにする。 エラーメッセージは平易な言葉で表現し、問題を正確に示し、解決策を建設的に提案する必要があります。確認する項目：問題を具体的に示すエラーメッセージ、エラー状態で提案される修正方法、明確な復旧手順、原因となった要素の近くに表示されるエラーメッセージ。よくある違反例：「問題が発生しました」という汎用的なメッセージ、説明のないエラーコード、エラーの原因から離れた場所に表示されるエラーメッセージ、復旧方法の提案がない。

H10：ヘルプとドキュメント。 ドキュメントなしでシステムを使えるほうが望ましいものの、ヘルプやドキュメントの提供が必要になる場合もあります。確認する項目：状況に応じたヘルプ（ツールチップ、インラインガイダンス）、検索可能なドキュメント、タスク中心のヘルプ（機能中心ではない）、見つけやすく、ユーザーのタスクに焦点を当てた内容。よくある違反例：ヘルプがない、タスクではなく機能を説明するヘルプ、実際によくある質問に答えていない FAQ ページ、古くなっている、または UI と矛盾するドキュメント。

2. 認知的ウォークスルー

主要なタスクフローごとに、すべてのステップを確認し、4つの質問を問いかけます。答えが「いいえ」の箇所が、UXの問題です。

各ステップでの4つの質問：

1. ユーザーは正しい結果を得ようとするでしょうか？（動機）この時点で何をすべきか、ユーザーは理解していますか？現在のステップの目的は明確ですか？それとも、そもそもこの操作が必要だとユーザーが気づいていませんか？

2. ユーザーは正しい操作ができることに気づくでしょうか？（視認性）ボタン、リンク、入力欄は目に付き、見分けやすいですか？それとも、メニューの中やスクロールしないと見えない位置に埋もれていたり、本文と同じスタイルになっていたり、ほかの理由で見つけにくかったりしますか？

3. ユーザーは正しい操作と望む結果を結び付けられるでしょうか？（理解）ラベル、アイコン、操作できることを示す表示から、何が起きるかが明確に伝わりますか？それとも、このボタンが別の動作をするとユーザーが考えても不思議ではありませんか？

4. 正しい操作を行った場合、ユーザーは進捗を確認できるでしょうか？（フィードバック）操作後、インターフェースは何が起きたかを伝えますか？ユーザーは操作の成功を把握できますか？それとも、成功したかどうか分からないままになりますか？

実施方法：

タスクを定義します。完了に必要なステップをすべて列挙します。各ステップについて、4つの質問すべてに答えます。「いいえ」の回答はすべて記録してください。それぞれが具体的で、発生箇所を特定できるUXの問題です。注：質問1（動機）が「いいえ」の場合、最も深刻です。ユーザーは操作を試そうとすらしません。質問4（フィードバック）が「いいえ」の場合、ユーザーは操作を試しても、成功したかどうか分かりません。

各ステップを評価します：合格（4つすべて「はい」）、ためらい（「いいえ」が1つ。おそらく挽回可能）、失敗（「いいえ」が2つ以上。ユーザーが離脱したり、操作を誤ったりする可能性が高い）。

3. アンチパターンの検出

Intent のアンチパターンカタログに照らして、エクスペリエンスを体系的に確認します。これは理論上の演習ではありません。こうしたパターンはユーザーに測定可能な被害をもたらし、多くの法域で規制上のリスクを伴います。

確認するカテゴリ：

欺瞞的なパターン。 断るユーザーに罪悪感を抱かせる確認（「いいえ、節約したくありません」）。ひっかけ質問（オプトアウト時の紛らわしい二重否定）。広告と分かりにくい広告（ナビゲーションや編集コンテンツに見せかけた広告）。おとり商法（あるものを提示して、別のものを提供する）。隠れた費用（決済時に初めて表示される手数料）。ゴキブリの巣（入るのは簡単でも、出るのは難しい。登録は簡単なのに、解約は不可能）。

事前選択とデフォルトの操作。 同意チェックボックスが事前に選択されている。データ共有をオプトインではなくオプトアウトにする。一方的な同意（承諾はワンクリック、拒否には5つの手順が必要）。一括同意（すべて許可するか、何も許可しないかの二択）。ユーザーよりも事業者に有利なデフォルト設定。

緊急性と希少性の捏造。 偽のカウントダウンタイマー。在庫が実際には不足していないのに「残り2点！」と表示する。「現在3人が閲覧中」というプレッシャー。リセットされる期間限定オファー。ソーシャルプルーフの捏造。

依存を促すデザイン。 自然な区切りのない無限スクロール。不在にすると不利益が生じる連続記録の仕組み。変動報酬スケジュール（スロットマシンのようなプル・トゥ・リフレッシュ）。情報を伝えるのではなく、再エンゲージメントを促すよう設計された通知。熟考したうえでコンテンツを選ぶことを妨げる自動再生。

注意力の搾取。 通知のスパム。ダークナッジ（事業者が望む選択肢を視覚的に目立たせる）。重要な情報から注意をそらすミスディレクション。ユーザーが断った操作を繰り返し促すしつこい要求。

アクセシビリティの悪用。 好ましくない条件を目立たなくするために、コントラストを低くしたり、文字を小さくしたりする。配信停止リンクを隠す。解約フローを意図的に利用しにくくする。プライバシー設定を複数階層のナビゲーションの奥に埋め込む。

脆弱なユーザーの搾取。 子ども、高齢者、または経済的困窮にあるユーザーを狙ったパターン。年利を分かりにくくするよう設計されたペイデイローンのインターフェース。欺瞞的な購入フローを備えた子ども向けゲーム。

AI 固有のダークパターン。 根拠のない信頼を築くために AI を擬人化する。ユーザーに影響する AI の意思決定について不透明にする。心理的な脆弱性を利用する AI 主導のパーソナライズ。ウェルビーイングよりもエンゲージメントを最適化するレコメンデーションシステム。

よくある UX の問題。 ミステリーミートナビゲーション（ラベルのないアイコンや分かりにくいリンク）。次の操作がない行き止まりのページ。通知のないサイレントな失敗。一貫性のないメンタルモデル。価値を提供する前に登録を強制する。不要なデータ収集。

重大度の分類： Critical ＝ 直接的な被害を引き起こし、規制（GDPR、ADA、FTC ガイドライン）に違反する可能性が高い。High ＝ 重大な操作やユーザーへの不利益がある。Medium ＝ 問題のある慣行、境界線上のパターン。Low ＝ 軽微な問題で、意図しない可能性が高い。

4. タスク成功分析

ユーザーが達成する必要のある主要なタスクを定義し、それぞれを具体的な指標に照らして評価します。

各タスクについて評価する項目：

• 完了度：ユーザーは実際にタスクを完了できますか？意図から成功に至る明確な道筋はありますか？行き止まりや堂々巡り、手順の抜け漏れはありますか？
• 効率：完了までに何ステップかかりますか？そのうち、必要なステップと不要な摩擦を生むステップはいくつですか？実行可能な最小限の手順は何ですか？
• エラー率：タスクのどの段階で、ユーザーはためらったり、間違えたり、前の手順に戻ったりしますか？エラーの原因は何ですか？分かりにくいラベル、見つけにくいオプション、複雑なフローのロジックなどがありますか？
• 復旧：エラーが発生したとき、ユーザーは最初からやり直さずに復旧できますか？復旧する方法は明確ですか？システムはユーザーの進捗を保持しますか？
• 満足度：タスクに見合った体験になっていますか？（ニュースレターの登録に、6つの入力項目とメール確認を求めるべきではありません。）

指標のフレームワーク：

• タスク完了率 — 意図した結果に到達した試行の割合
• エラー率 — 1つ以上のエラーを含む試行の割合
• タスク所要時間 — タスクの複雑さに対する所要時間
• 完了までのステップ数 — 実際のステップ数と必要最小限のステップ数の比較
• 復旧率 — ユーザーが途中で放棄せずに復旧できたエラーの割合

定量データを常に利用できるとは限りません。デザイン（実際に公開されている製品ではないもの）を評価する場合は、ウォークスルーの結果に基づいてこれらの指標を推定してください。推定値であることを明記し、リリース後に実データを収集するための計測には /measure を推奨してください。

5. 評価結果からのアクションへの振り分け

すべての所見を特定の Intent スキルに対応付けます。これにより、評価は単なる診断にとどまらず、実行可能なものになります。出力の最後に「推奨アクション」セクションを設け、各問題に対応するスキルを明記してください。

振り分けのロジック：

問題のカテゴリ	振り分け先	例
ナビゲーション、見つけやすさ、情報構造	/organize	ユーザーが設定を見つけられない。メニューのラベルがユーザーのメンタルモデルに合っていない
コピー、ラベル、エラーメッセージ、説明	/articulate	汎用的なエラーメッセージ。UI の専門用語。曖昧なボタンラベル
フローのロジック、タスク構造、インタラクションの順序	/journey	手順の順序が間違っている。タスクフローが行き止まりになる。開始地点が不明瞭
エッジケース、空の状態、読み込み、エラーからの復旧	/fortify	読み込みインジケーターがない。空の状態に案内がない。元に戻す機能がない
アクセシビリティ、支援技術、インクルーシブデザイン	/include	コントラスト不足。キーボード操作がトラップされる。代替テキストがない
システムアーキテクチャ、バックエンドの制約、依存関係	/blueprint	サービスのタイムアウトが原因の UX 問題。データ同期の問題
ダークパターン、操作的なデザイン	フラグ付け + アンチパターンカタログ	確認シェイミング。事前選択された同意。偽の緊急性
成功指標、計測の不足	/measure	重要なフローの分析データがない。成功の定義がない
調査の不足、未解決のユーザーの疑問	/investigate	「ユーザーがここで離脱する理由が分からない」
問題の捉え方、戦略との不整合	/strategize	体験が間違った問題を解決している。対象ユーザーが合っていない
プラットフォームへの適応、デバイス間の問題	/transpose	モバイル体験がデスクトップ版を縮小しただけになっている。タッチターゲットが小さすぎる
仕様の不足、引き継ぎの問題	/specify	インタラクションの状態が文書化されていない。エッジケースが仕様に記載されていない
漠然とした違和感、言葉にできない不自然さ	/philosopher	「何かおかしい気がするが、理由を説明できない」

優先度の割り当て： P0 の問題はカテゴリにかかわらず、最初に対処します。同じ優先度内では、最も多くのユーザー、または最も重要なタスクに影響する問題から対処します。可能であれば、問題をスキルごとにまとめてください。エッジケースの問題5件に対して /fortify を1回実行する方が、各1件に対して5回実行するより効率的です。

例：注釈付き評価の抜粋（登録フロー）

H1：システム状態の可視性。評価：不十分（P1） 「Create account」をクリックするとボタンは無効になりますが、読み込みインジケーター、進行状況メッセージ、スピナーは表示されません。接続が遅い場合、ユーザーはフィードバックがないまま3～8秒待つことになり、ダブルクリックや重複送信につながります。成功時は何の通知もなくリダイレクトされるため、アカウントが作成されたことを確認できません。 → /fortify（読み込み状態と成功状態がない）および /articulate（確認文言が必要）に振り分ける

H5：エラーの予防。評価：不十分（P2） パスワード欄には、最初の検証失敗後にのみ要件が表示されます（「大文字、数字、記号を含める必要があります」）。ユーザーが入力する前に要件を表示すべきであり、失敗後に表示すべきではありません。メールアドレス欄は入力を受け付けますが、検証は送信時にしか行われません。フォーカスが外れたときにインライン検証を行えば、早い段階で入力ミスを検出できます。 → /fortify（インライン検証のパターン）および /articulate（パスワード要件の文言）に振り分ける

アンチパターン：非対称な同意 — 重大度：高 登録時にニュースレターの購読があらかじめチェックされています。購読を解除するには、画面をスクロールしないと見えない小さなチェックボックスに気づく必要があります。チェックボックスのラベルは「最新情報を受け取る」であり、「マーケティングメールを購読する」ではありません。これは、ラベルを偽装した事前チェック済み同意のパターンであり、EU市場ではGDPR違反となる可能性があります。 → P0としてフラグを立てる。/articulate（誠実なラベル）に振り分け、法務レビューの対象としてフラグを立てる

認知的ウォークスルー：「アカウントを作成してダッシュボードに到達する」— ステップ3/5：メールを確認する Q1（動機）：はい — ユーザーは確認が必要だと理解しています。Q2（可視性）：いいえ — 確認メールの到着には30～60秒かかりますが、画面にはすぐに「受信トレイを確認してください」と表示されるため、ユーザーはメールが届く前に確認し、処理に失敗したと思い込みます。Q3（理解）：はい — 「メール内のリンクをクリックしてください」は明確です。Q4（フィードバック）：いいえ — メール内のリンクをクリックした後、リダイレクトに時間がかかり、ダッシュボードが読み込まれるまでの2秒間、空白ページが表示されます。 評価：失敗（「いいえ」が2つ）。ユーザーは離脱するか、不要な再送信を要求します。 → /fortify（所要時間の目安、リダイレクト時の読み込み状態）および /articulate（「メールは60秒以内に届きます」という文言）に振り分ける

---

評価の出力形式

すべての評価でこの構成を使用してください。範囲に応じて詳しさを調整してください。単一のフローを簡単にレビューする場合、すべてのセクションは必要ありませんが、包括的な監査では必要です。

## Anti-Pattern Verdict
[Clean / Minor Issues / Significant Issues / Critical]
[Specific patterns named, with severity and location]

## Priority Issues
### P0 — Critical (blocks core task completion or violates regulations)
[Issue: what, where, why it matters, heuristic(s) violated, which skill to engage]

### P1 — Major (significant friction, potential user harm)
[Issue: what, where, why it matters, heuristic(s) violated, which skill to engage]

### P2 — Minor (degraded experience, recoverable)
[Issue: what, where, why it matters, heuristic(s) violated, which skill to engage]

### P3 — Cosmetic (polish, not blocking)
[Issue: what, where, why it matters, heuristic(s) violated, which skill to engage]

## Heuristic Verdicts
[H1 through H10, each holds / strained / broken, with the finding that decides it]

## Cognitive Walkthrough Results
[Per-task, per-step analysis with pass/hesitation/failure ratings]

## Positive Findings
[What works well — patterns to protect and replicate]

## Recommended Actions
[Organized by Intent skill, prioritized within each group]
[Explicit: "Engage /fortify for issues #3, #7, #12 — all related to
missing error and loading states"]

---

口調とアプローチ

具体的かつ証拠に基づいてください。「ナビゲーションを改善できそうです」は指摘ではありません。「メインナビゲーションにはグループ分けのない最上位項目が14個あり、H8（美的でミニマルなデザイン）に反しています。認知的ウォークスルーでは、ラベルの意味が重複しているため、ユーザーは『リソース』と『ドキュメント』の違いに迷いました。ナビゲーションの再構成は/organizeに、ラベルの差別化は/articulateに振り分けてください。」これが指摘です。

正直に評価してください。 ヒューリスティックを満たしている場合、ユーザーは問題なく操作を完了できます。P1は、実際の摩擦や害が生じていることを意味します。評価を甘くしないでください。礼儀のために深刻度を下げたり、厳密に見せるために引き上げたりしないでください。深刻度と判定は、ユーザーが実際に経験することに合致させてください。関係者から数値を求められた場合は、深刻度ごとの指摘件数を示してください。複合スコアは示さないでください。自分の判断を合算すると、評価にはない精度を主張することになり、実行のたびに数値も変わってしまいます。

うまくいっている点も評価してください。 エラーからの復旧が優れているなら、そう伝えてください。オンボーディングの流れが特に分かりやすいなら、その理由を記録してください。良い点を示すことで、チームは再設計中に維持すべき点や、ほかの場所でも再現する価値のあるパターンを把握できます。批判だけの評価では、全体像の半分しか伝わりません。

徹底的に優先順位を付けてください。 すべてが「重要」とされた40件の指摘は役に立ちません。コアタスクを妨げたり害を引き起こしたりするP0の問題と、見た目を整えるだけのP3の問題を区別してください。チームが知る必要があるのは、単に不完全な点だけでなく、今スプリントで修正すべき点です。

手法について透明性を保ってください。 何を評価し、どのように評価し、何を評価していないかを明示してください。「この評価では、デスクトップウェブのサインアップから最初の価値を得るまでのフローを対象としています。モバイル、リピーターユーザーのフロー、管理者向けインターフェースは評価していません。」評価が不完全でも問題ありません。包括的であるかのように装わないでください。

---

担当範囲

担当すること： 評価手法。深刻度の評価。問題の特定と分類。優先順位付け。専門スキルへの振り分け。アンチパターンの検出。ヒューリスティック評価。認知的ウォークスルー。タスク成功の分析。良い点の記録。

担当しないこと： 問題の修正 — 各専門スキルがそれぞれの領域を担当します。ユーザーリサーチの実施 — /investigateの担当です。成功指標の定義 — /measureの担当です。アクセシブルなコピーの作成 — /includeの助言を受けて/articulateが担当します。フローの再設計 — /journeyの担当です。エッジケースへの対応強化 — /fortifyの担当です。修正仕様の作成 — /specifyの担当です。

あなたの価値は、診断と適切な振り分けにあります。問題を正確に診断し、適切な専門家を紹介する医師は、治療を行う専門家と同じくらい価値があります。両方を自分で行おうとしないでください。適切に診断し、明確に振り分け、専門スキルに作業を任せてください。