ux-heuristics-audit

ユーザビリティヒューリスティック監査スキル

このスキルがデフォルトの動作と比べて変えるもの

このスキルがない場合、ユーザビリティレビューはフレームワークも重大度も、なぜそれが問題なのかという根拠もない、一般的な提案（「もっとすっきりさせましょう」「CTA を改善しましょう」）の平坦なリストを生みがちです。このスキルは次の 4 点を強制します。

1. すべての指摘は、違反しているヒューリスティックを明示する — 曖昧な意見ではありません。
2. すべての指摘に、頻度 × 影響 × 持続性に基づく重大度評価を与える — そのためリストは等しく重み付けされるのではなく、優先順位が付けられます。
3. すべての指摘には、具体的で明確な修正案がある — 「改善を検討する」ではありません。
4. 監査は過剰な指摘に抵抗する。 ヒューリスティックは原則であり、達成すべきチェックリストではありません。指摘は、実際のユーザーの時間、信頼、またはタスク完了を現実的に損なう場合にのみ、価値を持ちます。

スコープの規律。 直接呼び出された場合（ユーザーがこの監査を指定した場合）、この関心事のみをレビューします — 姉妹監査を引き込まないでください。オーケストレーター（ux-design-review）または生成スキルが docs/orchestration-policy.md の下でこれを呼び出す場合にのみ、他のレンズと並行して実行され、そこでは Tier A — 常に関連性があり、自動実行される に位置します。明示的なスコープが常に優先されます。

---

10 のヒューリスティック — 何を確認し、違反がどのように見えるか

それぞれを順に確認してください。すべての問題について、違反したヒューリスティック、重大度、何が問題か、修正案を記録します。

1. システム状態の可視性

システムは、タイムリーなフィードバックを通じて、何が起きているかを常にユーザーに知らせるべきです。優れたインターフェースは次の問いに答えます: 何が起きたのか？ 自分はどこにいるのか？ 今何が起きているのか？ 次は何か？

指摘すべき場合: アクションが何のフィードバックも生まない（状態変化のないボタンクリック、確認のないフォーム送信）、読み込みや処理にインジケーターがない、フロー内でのユーザーの現在位置が不明確、バックグラウンド操作（保存、同期、アップロード）が無言で行われる。

• ❌ ユーザーが「保存」をタップしても目に見えて何も変わらない — うまくいったのか？
• ✅ 「保存」はスピナーを表示し、その後チェックマーク + タイムスタンプ付きの「保存しました」を表示する。

2. システムと現実世界の一致

ユーザーの言語で話しかけてください — システムや開発者の専門用語ではなく、なじみのある言葉、フレーズ、概念を用います。現実世界の慣習と期待される順序に従ってください。

指摘すべき場合: コピーが内部用語や技術用語（「認証に失敗しました: トークンが期限切れです」）、なじみのないアイコン、またはユーザーの期待に合わないメタファーを使用している、情報が不自然な順序で表示される。

• ❌ 「エラー 0x80: 無効な資格情報オブジェクトです。」
• ✅ 「そのパスワードは一致しません。もう一度試すか、リセットしてください。」

3. ユーザーの制御と自由

ユーザーは間違いを犯し、気が変わります。明確に示された「緊急出口」 — 元に戻す、やり直す、戻る、キャンセル、閉じる — を、長々とした対話を強いることなく提供してください。

指摘すべき場合: 破壊的なアクションに元に戻す手段がない、状態やモーダル、フローから抜け出す明らかな方法がない、複数ステップのプロセスが戻るオプションなしでユーザーを閉じ込める、出口が隠されている、または曖昧にラベル付けされている。

• ❌ 項目の削除が即座かつ永続的で、復元手段がない。
• ✅ 削除は数秒間「元に戻す」を表示する、または削除された項目は 30 日間復元できる。

4. 一貫性と標準

同じ言葉、アクション、要素は、全体を通して同じ意味を持つべきであり（内部一貫性）、プラットフォームの慣習に従うべきです（外部一貫性）。視覚的、機能的、配置、データ形式の一貫性を網羅します。

指摘すべき場合: 同じアクションが場所によって異なるラベルで表示される、プライマリボタンが画面間で位置を変える、類似のコンポーネントが異なる動作をする、日付・電話番号・数値の形式がフォーム間で異なる、プラットフォームの慣習が破られている（例: 非標準の戻る動作）。

• ❌ 「削除」「取り消し」「ゴミ箱」がすべて、画面間で同じアクションに使われている。
• ✅ 1 つのアクションには 1 つの動詞を、どこでも一貫した位置とスタイルで。

5. エラーの防止

優れたエラーメッセージよりも、ミスを防ぐことの方が重要です。スマートなデフォルト値、入力制約、寛容な書式、サジェスチョン、そしてコストの高い操作に対する確認を使用してください。スリップ（偶発的なもの）とミステイク（誤ったメンタルモデル）を区別しましょう。

指摘すべきケース: フォームが防ぎやすい不正入力を許容している。送信前にインライン検証がない。破壊的・不可逆的な操作に確認がない。厳格な入力形式が有効なデータを拒否する（「カード番号からスペースを削除してください」）。

• ❌ フォームが、ユーザーが「送信」を押した後に初めて5件のエラーを明らかにする。
• ✅ ユーザーが各フィールドを離れるたびにインライン検証が指摘する。カード番号フィールドは任意のスペースを許容する。

6. 想起ではなく認識

記憶の負荷を最小限に抑えましょう。ユーザーにコンテキストをまたいで覚えておくことを強いるのではなく、選択肢、アクション、情報を見えるようにします。

指摘すべきケース: 現在の画面で操作するために、ユーザーが前の画面の情報を覚えていなければならない。役立つ場面でオートコンプリート／サジェスチョン／最近の項目がない。ユーザーがすでに入力したデータが事前入力されていない。機能が存在すると知らなければ見えない。

• ❌ 請求フォームが、ユーザーがたった今入力した配送先住所を再入力させる。
• ✅ 「配送先住所と同じ」が事前に選択されている。最近の検索や閲覧した項目が再表示される。

7. 使用における柔軟性と効率性

初心者と熟練者の両方に応えましょう。一般的な機能はデフォルトで表示し、経験豊富なユーザーにはアクセラレーター（ショートカット、ジェスチャー、マクロ、カスタマイズ）を提供します。

指摘すべきケース: タスクを完了するための柔軟性のない一本道しかない。頻繁に使うユーザーやパワーユーザー向けのショートカット／アクセラレーターがない。繰り返すワークフローのための設定をカスタマイズまたは保存する方法がない。コンテキストの注記: 生産性／プロ向けツールではこれを重視し、シンプルな消費者向けまたは単発のフローでは軽く扱います。

• ❌ パワーユーザーが毎回同じ6ステップのメニューパスをクリックして進まなければならない。
• ✅ メニューパスと並んで、キーボードショートカットと保存済み／お気に入りのアクションが存在する。

8. 美的でミニマルなデザイン

インターフェースには、ユーザーのタスクを支えるものだけを含めるべきです。価値を加えないすべての要素は、価値を加える要素と競合します。ミニマル＝機能的なことであり、素朴なことではありません。

指摘すべきケース: 画面が低価値な要素で雑然としている。装飾的なコンテンツがタスクに不可欠なコンテンツを押しのけている。すべてが強調されている（そのため何も強調されていない）。段階的な開示ではなく、あまりに多くの選択肢が一度に表示されている。

• ❌ 6つのバッジ、3つの影、30行の機能が注意を奪い合う料金カード。
• ✅ 強調された要素が1つ、主要な機能のみ、残りは「すべて表示」の背後に。

ヒューリスティックの緊張: #8（ミニマリズム）と #9／#10（より多くのヘルプ、より多くのドキュメント）、そして #7（より多くの選択肢）は互いに引っ張り合います。ヘルプテキスト、選択肢、コンテンツを追加することを勧めながら、同時に雑然さを指摘してはいけません。ユーザーの主要なタスクに向けて解決しましょう。

9. ユーザーがエラーを認識、診断、回復できるようにする

エラーメッセージは平易な言葉で、何がうまくいかなかったのかを述べ、建設的な進む道を丁寧に示すべきです。

指摘すべきケース: エラーメッセージがコードや専門用語を示している。メッセージが問題を述べているが解決策を述べていない。口調が非難的または機械的である。メッセージがすべて大文字を使用している（読みにくく、叫んでいるように感じられ、アクセシビリティを損なう）。エラーが、それを引き起こしたフィールドの隣に配置されていない。

• ❌ 「INVALID INPUT.」
• ✅ 「このメールアドレスはすでに登録されています。代わりにログインするか、別のアドレスを使用してください。」（フィールドの隣に）

10. ヘルプとドキュメント

理想的には、デザインに説明は不要です。しかし、ユーザーが行き詰まったときに見つけやすいヘルプを提供しましょう。プロアクティブなヘルプ（オンボーディング、状況に応じたヒント）とリアクティブなヘルプ（検索可能なドキュメント、チュートリアル）を区別します。

指摘すべきケース: 複雑な機能に状況に応じたガイダンスがない。ヘルプが埋もれている、または検索できない。オンボーディングをスキップまたは閉じることができない。ヒントが現在のタスクに関連していない。

• ❌ ツールチップも、オンボーディングも、見つけられるドキュメントもない複雑な機能。
• ✅ 初回使用時に閉じることができる状況に応じたヒント + 検索可能でタスク別に分類されたヘルプ。

---

重大度の評価

各指摘は、ヒューリスティック評価と同様に、3つの要素を組み合わせて評価します（Nielsenによる）：

• 頻度 — ユーザーはどのくらいの頻度でこれに遭遇するか？（まれ ↔ 常時）
• 影響 — 遭遇したときに克服するのはどのくらい困難か？（不快 ↔ 阻害要因）
• 持続性 — 一度きりか（ユーザーは回避策を学習する）、それとも毎回繰り返されるか？

これらを4つのレベルのいずれかに集約します：

重大度	意味
Critical	タスクの完了を阻害する、またはデータ損失／不可逆的なエラーを引き起こす。出荷前に修正すること。
Major	頻繁かつ摩擦が大きい。ユーザーは回復できるが、時間を浪費するか信頼を失う。
Minor	気づく程度の摩擦で、頻度が低いか克服が容易。
Cosmetic	仕上げ。時間があれば修正する。これらでレポートを水増ししないこと。

問題がアクセシビリティ違反（コントラスト、キーボード、スクリーンリーダー、代替テキスト）かつユーザビリティの問題でもある場合は、それを記載しつつ、アクセシビリティの詳細は accessibility-audit スキルに委ねるようにし、重複させないでください。完全な a11y チェックが必要な場合は、そのスキルを呼び出してください。

---

監査の出力形式

## Usability Heuristic Audit — [Screen / Flow Name]
Context: [platform · audience · primary user task, if known]

### Critical
- [Issue] — what's wrong → fix. (Heuristic #N: name)

### Major
- [Issue] — what's wrong → fix. (Heuristic #N: name)

### Minor
- [Issue] — what's wrong → fix. (Heuristic #N: name)

### Working well ✓
- [What already satisfies the heuristics — name them]

**Top 3 priorities:** the three fixes with the highest frequency × impact.

常に優先順位付けされたトップ3で締めくくってください。長く平坦なリストは、誰の行動にもつながりません。

---

優れた監査の実施方法（チェックリストの垂れ流しにしない）

1. まずコンテキストを確立する。 プラットフォーム（モバイル／ウェブ／デスクトップ）、対象読者（初心者／熟練者）、および主要タスクによって、どのヒューリスティックが重要か、どの程度重み付けるかが変わります。不明であり、それが指摘に実質的に影響する場合は、指摘する前に1つ質問してください。
2. 実際のコストのみを指摘する。 指摘は、実際のユーザーの時間、信頼、または完了を現実的に損なうものでなければなりません。「もう少し綺麗にできる」は指摘ではありません。
3. ヒューリスティック間の緊張を尊重する。 ミニマリズムと、より多くのヘルプ／オプション／フィードバックは、設計上対立します。両方を同時に推奨しないでください。主要タスクに向けて解決してください。
4. 列挙せず、優先順位付けする。 3つの Critical な指摘は、25の Cosmetic な指摘に勝ります。重大度評価とトップ3は、これを強制するために存在します。
5. 修正は具体的に。 「フィードバックを追加する」→「保存ボタンにスピナーを表示し、その後『保存しました』の確認を表示する」。

---

よくある do/don't パターン

❌ しない	✅ する
「この画面のユーザビリティを改善する」	問題ごとにヒューリスティック、重大度、正確な修正を明記する
すべての問題を等しく重要として扱う	Critical/Major/Minor/Cosmetic で評価し、トップ3を提示する
雑然さを指摘しつつ、より多くのヘルプテキスト／オプションを推奨する	ミニマリズムとヘルプの緊張を主要タスクに向けて解決する
ここでアクセシビリティの指摘を再導出する	重複を記載し、詳細は accessibility-audit スキルに委ねる
プラットフォーム／対象読者を知らずに監査する	コンテキストを確立し、それに応じてヒューリスティックを重み付ける
Cosmetic な重箱の隅でレポートを水増しする	実際のユーザーの時間や信頼を損なう問題のみを報告する
「Error 0x80 / INVALID INPUT」を未指摘のままにする	専門用語、コード、全大文字、非難する口調を指摘する（ヒューリスティック #9）
出口のない永続的な破壊的操作	元に戻す／キャンセル／戻るの欠如を指摘する（ヒューリスティック #3）

---

出典元のレッスン（Uxcel）

• 10 Usability Heuristics by Jakob Nielsen
• Usability Heuristics
• Mental Models & User Control
• Writing Problem Messages
• Minimizing Cognitive Load
• Understanding Design Audit Types