usability-heuristics

概要

このスキルは、Nielsenのユーザビリティに関する10のヒューリスティックをユーザーインターフェースのコードに適用し、レビューと監査を行います。次の2つの目的があります。

1. 監査モード：既存のUIコードを10のヒューリスティックすべてに照らして体系的に評価し、重大度評価、根拠、修正方法を含む構造化された問題ログを作成します。
2. ガイダンスモード：新機能の構築時にヒューリスティックを先回りして適用し、リリース前にユーザビリティの問題を防ぎます。

このスキルは、評価方法と構造化されたレポートに焦点を当てています。ヒューリスティックがUXの法則と重複する場合は、ガイダンスを重複させず、該当する法則を相互参照します。包括的に対応するには、両方のスキルを併用してください。

• usability-heuristics（このスキル）＝監査方法＋構造化された問題ログ
• laws-of-ux＝理論的な基盤＋詳細なUXの原則

コードをレビューする際は、まず監査チェックリストで、特に関連性の高いヒューリスティックを特定してから、詳細なセクションでガイダンスと例を確認してください。調査結果は必ず、以下の問題ログ形式で作成してください。

キーワード：ヒューリスティック評価、ユーザビリティ監査、nielsen heuristics、ui audit、ユーザビリティレビュー、ヒューリスティックレビュー、ux compliance、ユーザビリティの問題

---

問題ログ形式

ヒューリスティック評価を行う際は、すべての調査結果をこの構造化された形式で作成してください。

サマリーテーブル

すべての監査は、重大度のサマリーから始めてください。

## Heuristic Evaluation Summary

| Severity | Count |
|----------|-------|
| Critical | X     |
| Major    | X     |
| Minor    | X     |
| Advisory | X     |
| **Total** | **X** |

重大度の定義

• Critical（致命的）：ユーザーが主要なタスクを完了できません。例：フォームの送信時にエラーから回復できない、破壊的な操作を取り消す方法がない、非同期処理に対してシステムからまったくフィードバックがない。
• Major（重大）：ユーザーが大きな不便や混乱を感じます。例：非同期処理の読み込み状況がフィードバックされない、ページ間でナビゲーションのパターンに一貫性がない、エラーメッセージに技術用語がそのまま表示される。
• Minor（軽微）：ユーザーは不便を感じますが、問題を回避できます。例：プレースホルダーテキストがない、タブの順序が最適でない、アイコンのみのボタンにツールチップがない。
• Advisory（参考）：タスクの完了を妨げるものではありませんが、エクスペリエンスを向上させる改善の機会です。例：上級ユーザー向けのキーボードショートカットを追加する、空の状態にガイダンスを追加する、確認メッセージの文面を改善する。

指摘事項の形式

各指摘事項は、次の構造に従います。

### [H#] Heuristic Name — Finding Title

- **Severity**: Critical | Major | Minor | Advisory
- **Heuristic**: #N — Heuristic Name
- **Location**: `file_path:line_range` or component/view name
- **Description**: What the issue is and why it matters for usability.
- **Evidence**:
  ```html
  

• 推奨事項：

• 相互参照：laws-of-ux：法則名（該当する場合）

### Audit Completion

End every audit with:

```markdown
## Recommendations Priority

1. **Fix immediately** (Critical): List critical findings by ID
2. **Fix soon** (Major): List major findings by ID
3. **Plan for next iteration** (Minor): List minor findings by ID
4. **Consider for enhancement** (Advisory): List advisory findings by ID

---

監査チェックリスト

すばやく確認するには、この表を使用してください。各チェック項目はヒューリスティックに対応しており、コードで確認すべき点を示しています。

チェック項目	ヒューリスティック	確認する内容
すべての非同期アクションで読み込み／進行状況をフィードバックする	H1：システム状態の可視性	スピナー、スケルトンスクリーン、disabled 状態、aria-busy、aria-live 領域、data-disable-with
システムが開発者向けの専門用語ではなく、平易な言葉を使っている	H2：システムと現実世界の一致	エラーメッセージ、ラベル、ヘルプテキスト — HTTP コード、モデル名、技術用語が含まれていないか確認します
取り消し／戻る／キャンセルの手段が、破壊的な操作や複数ステップの操作で利用できる	H3：ユーザーによる操作の自由と制御	キャンセルボタン、取り消しパターン、data-turbo-confirm、モーダルを閉じる操作（X ＋ Escape）、戻るリンク
UI 要素のスタイルと動作に一貫性がある	H4：一貫性と標準	ボタンのクラス、フォームのレイアウト、用語、ナビゲーションのパターン、デザイントークンの使用状況
危険な操作には確認を求め、入力では無効な値を制限する	H5：エラーの防止	data-turbo-confirm、disabled 状態、入力の type／required／min／max／pattern
ラベル、アイコン、操作できることを示す要素が常に表示されている	H6：思い出すより見て分かる	表示されているラベル、パンくずリスト、常に表示されるナビゲーション、アイコンとテキストの組み合わせ、オートコンプリート
経験豊富なユーザー向けのショートカットやアクセラレーターがある	H7：柔軟性と効率性	キーボードショートカット、accesskey、検索、一括操作、カスタマイズ可能なビュー
UI に必要不可欠な情報のみが表示されている	H8：美的で最小限のデザイン	コンテンツの密度、競合する CTA、装飾要素と機能要素、開閉可能な表示
エラーメッセージが何が起きたかを説明し、解決策を提案している	H9：ユーザーによるエラーからの回復を支援	フラッシュメッセージ、インライン検証、エラーの概要、フィールド単位のエラー表示
必要な場所で状況に応じたヘルプを利用できる	H10：ヘルプとドキュメント	ツールチップ、aria-describedby、ヘルプテキスト、空の状態に表示する案内、<details> 要素

---

10 のユーザビリティヒューリスティック

H1：システム状態の可視性

定義：適切なフィードバックを適切な時間内に提供し、何が起きているかをユーザーに常に知らせるようにデザインする必要があります。

重要なポイント：ユーザーの操作にはすべて、目に見えるフィードバックを返す必要があります。非同期処理には読み込み状態が必要です。状態の変化は視覚的に確認できる必要があります。「操作は成功したのか」とユーザーに考えさせてはいけません。

コードで確認する内容：

• フォームの送信ボタン：data-disable-with、または読み込み状態を表示する Stimulus コントローラーがあるか確認します
• 非同期のデータ読み込み：スケルトンスクリーン、スピナー、aria-busy="true" があるか確認します
• ライブ領域：動的なコンテンツの更新に aria-live="polite" または aria-live="assertive" があるか確認します
• 状態の変化：操作後にトースト通知、フラッシュメッセージ、インライン確認が表示されるか確認します
• Turbo Frames：フレームの置き換え中に読み込みインジケーターがあるか確認します
• ファイルアップロード：プログレスバーまたはパーセント表示があるか確認します

例：

GOOD

<form data-controller="form-submit" data-action="submit->form-submit#disable">
  <button type="submit" class="btn btn--primary"
          data-disable-with="Saving..."
          data-form-submit-target="button">
    Save Changes
  </button>
</form>

<div aria-live="polite" class="notification-area">
  
</div>

BAD

<form>
  <button type="submit" class="btn btn--primary">Save Changes</button>
  
  
</form>

送信時にフィードバックがありません。ユーザーが複数回クリックして、送信が重複する可能性があります。

レビュー時の確認事項：

• 読み込み中または無効状態にならないフォーム送信ボタンを指摘します
• 目に見える読み込みインジケーターがない非同期処理（fetch、Turbo Frame の読み込み）を指摘します
• 確認のフィードバックがない状態変更（追加、削除、更新）を指摘します
• 動的な状態更新用の aria-live 領域がないページを指摘します
• 進行状況の表示がないファイルアップロード入力を指摘します

相互参照： laws-of-ux：ドハティの閾値（400ms 以内の応答）、目標勾配効果（進行状況の可視化）

---

H2: システムと現実世界の一致

定義：デザインにはユーザーの言葉を使います。内部の専門用語ではなく、ユーザーにとってなじみのある単語、フレーズ、概念を使います。現実世界の慣習に従い、情報を自然で論理的な順序で表示します。

重要なポイント：ラベル、エラーメッセージ、説明には、ユーザーが理解できる平易な言葉を使います。情報はシステムの視点ではなく、ユーザーの視点から論理的な順序で並べます。

コードで確認すること：

• エラーメッセージ：HTTP ステータスコード、モデル名／属性名、スタックトレース、データベース用語が含まれていないか確認します
• フォームのラベル：データベースのカラム名がラベルとして使われていないか確認します（例：「Date created」ではなく created_at）
• ナビゲーションの順序：データベーススキーマの順序ではなく、ユーザーのタスクの流れに沿っているか確認します
• アイコン：誰もが理解できる比喩を使っているか確認します
• 日付／時刻の形式：ユーザーのロケールに合った形式か確認します

例：

GOOD

<div class="alert alert--error" role="alert">
  <p>We couldn't save your changes. Please check the highlighted fields below.</p>
</div>

<label for="start_date">Start date</label>
<input type="date" id="start_date" name="project[start_date]">

BAD

<div class="alert alert--error" role="alert">
  <p>422 Unprocessable Entity: Validation failed: start_date can't be blank,
     end_date must be after start_date</p>
</div>

<label for="project_created_at">project_created_at</label>
<input type="text" id="project_created_at" name="project[created_at]">

生の技術的なエラーメッセージとラベルにデータベースのカラム名を使用しています。システム内部の情報をユーザーに見せてはいけません。

レビュー時のチェック項目：

• HTTP ステータスコード、モデル名、属性名を含むエラーメッセージを指摘します
• データベースのカラム名と完全に一致するフォームラベル（snake_case、略語）を指摘します
• テキストもツールチップもなく、ドメイン固有の比喩を使ったアイコンのみの操作を指摘します
• ユーザーのタスクの流れではなく、システムのロジック（フィールド名のアルファベット順など）で並べられたコンテンツを指摘します
• ユーザーのロケールに合わない日付／数値の形式を指摘します

相互参照： laws-of-ux：ヤコブの法則（ユーザーは使い慣れたインターフェースの慣習を期待します）

---

H3: ユーザーの制御と自由

定義：ユーザーは操作を誤ることがよくあります。望まない操作から、長い手順を経ずに抜け出せる、明確に示された「緊急出口」が必要です。

重要なポイント：破壊的な操作や確定を伴う操作には、必ず抜け道を用意します。ユーザーは、いつでも不利益を被ることなく、元に戻す、キャンセルする、戻る、閉じるといった操作ができる必要があります。

コードで確認すること：

• 破壊的な操作（削除、除去、アーカイブ）：確認ダイアログ（data-turbo-confirm）があるか確認します
• 複数ステップのフォーム／ウィザード：戻るボタンと、前のステップに戻る機能があるか確認します
• モーダル／ダイアログ：閉じるボタン（X）、Escape キーのハンドラー、背景クリックで閉じる機能があるか確認します
• 一括操作：実行前の取り消し機能または確認機能があるか確認します
• ナビゲーション：フォームページや編集画面にキャンセル／戻るリンクがあるか確認します
• フィルター／検索：クリア／リセット機能があるか確認します

例：

GOOD

<a href="/projects/5" data-turbo-method="delete"
   data-turbo-confirm="Delete this project? This cannot be undone."
   class="btn btn--danger">
  Delete Project
</a>


<dialog class="modal" data-controller="modal"
        data-action="keydown.esc->modal#close click->modal#closeOnBackdrop">
  <button class="modal__close" data-action="click->modal#close" aria-label="Close">
    &times;
  </button>
  <div class="modal__body">
    
  </div>
  <div class="modal__footer">
    <button class="btn btn--outline" data-action="click->modal#close">Cancel</button>
    <button class="btn btn--primary">Confirm</button>
  </div>
</dialog>

BAD

<a href="/projects/5" data-turbo-method="delete" class="btn btn--danger">
  Delete
</a>


<div class="modal">
  <div class="modal__body">
    <p>Are you sure?</p>
    <button class="btn btn--primary">Yes, continue</button>
    
  </div>
</div>

確認なしの破壊的な操作です。モーダルには進む以外の選択肢がなく、ユーザーを閉じ込めています。

レビュー時のチェック項目：

• 確認ダイアログのない削除／除去／アーカイブ操作を指摘します
• 閉じるボタン、Escape キーのハンドラー、キャンセル विकल्पのないモーダルを指摘します
• 戻る／前へボタンのない複数ステップのフローを指摘します
• 前の画面に戻るキャンセルリンクのないフォームページを指摘します
• 取り消し機能も確認機能もない一括操作を指摘します
• クリア／リセット विकल्पのないフィルター／検索 UI を指摘します

相互参照： laws-of-ux：ピーク・エンドの法則（エラーからの回復は、体験における重要な「ピーク」の瞬間です）

---

H4：一貫性と標準

定義：異なる単語、状況、操作が同じ意味なのか、ユーザーが迷わないようにします。プラットフォームや業界の慣習に従います。

重要なポイント：内部の一貫性（アプリ全体で同じパターンを使うこと）と外部の一貫性（プラットフォームの慣習に従うこと）の両方を保ちます。同じ機能は、どこでも同じ外観と動作にします。

コードで確認すること：

• ボタンのスタイル：同じ種類の操作で、すべての画面で同じ CSS クラスが使われているか確認します
• 用語：同じ操作に対して、どこでも同じラベルが使われているか確認します（ある場所では「保存」、別の場所では「送信」になっていないか）
• フォームのレイアウト：ラベルの配置（上か横か）、フィールドの順序、バリデーションのパターンに一貫性があるか確認します
• ナビゲーションのパターン：ページ間でメニュー構造、リンクのスタイル、アイコンの使い方に一貫性があるか確認します
• デザイントークン：トークンとハードコード値の使い方に一貫性があるか確認します（optics-context スキルを参照）
• コンポーネント構造：BEM の命名規則と HTML 構造に一貫性があるか確認します（bem-structure スキルを参照）

例：

GOOD

<div class="actions">
  <a href="/projects/5/edit" class="btn btn--primary">Edit</a>
  <a href="/projects" class="btn btn--outline">Back</a>
</div>


<div class="actions">
  <a href="/tasks/12/edit" class="btn btn--primary">Edit</a>
  <a href="/tasks" class="btn btn--outline">Back</a>
</div>

BAD

<div class="actions">
  <a href="/projects/5/edit" class="btn btn--primary">Edit</a>
  <a href="/projects" class="btn btn--outline">Back</a>
</div>


<div class="task-buttons">
  <button class="btn btn--secondary" onclick="location='/tasks/12/edit'">Modify</button>
  <a href="/tasks" class="link">Return to list</a>
</div>

同じ概念の操作（「編集」と「戻る」）に、異なるラベル、異なる HTML 要素、異なる CSS クラス、異なる操作パターンが使われています。

レビュー時の確認事項：

• 同じ操作に対して、画面ごとに異なるラベル（「保存」「送信」「更新」「確認」）が使われている場合は指摘します
• 同じ種類の要素に対して、画面ごとに異なる CSS クラスや HTML 構造が使われている場合は指摘します
• 同じプロパティに対して、デザイントークンとハードコード値が混在している場合は指摘します
• アプリのセクション間でナビゲーションのパターンが異なる場合は指摘します
• ネイティブの動作に一致しない標準的なプラットフォームコントロールの独自実装（独自のセレクトボックス、日付ピッカーなど）がある場合は指摘します

相互参照： laws-of-ux：ヤコブの法則（プラットフォームの慣習に従う）、類似性の法則（一貫したスタイルは関連性を示す）、美的ユーザビリティ効果（視覚的な一貫性は品質の印象を高める）。デザイントークンの一貫性については optics-context、CSS の命名規則の一貫性については bem-structure も参照してください。

---

H5：エラーの防止

定義：適切なエラーメッセージは重要ですが、優れたデザインは、そもそも問題が起きないように慎重に防止します。エラーが起こりやすい条件を排除するか、条件を確認して、ユーザーが操作を確定する前に確認できる選択肢を提示します。

重要なポイント：入力値を有効な値に制限します。破壊的な操作の前に確認を求めます。適切な入力タイプを使います。システムは、誤った操作をしにくい設計にする必要があります。

コードで確認すること：

• 入力タイプ：フィールドに適切な type 属性（email、tel、url、number、date）が使われているか確認します
• 制約：required、min、max、minlength、maxlength、pattern、step 属性が設定されているか確認します
• 破壊的な操作：取り消せない操作の前に確認ダイアログが表示されるか確認します
• インラインバリデーション：フォーム送信前にリアルタイムでバリデーション結果が表示されるか確認します
• 無効状態：必須フィールドが入力されるまで送信ボタンが無効になっているか確認します
• デフォルト値：エラーの可能性を減らす、適切なデフォルト値が設定されているか確認します

例：

GOOD

<form data-controller="form-validation">
  <label for="email">Email address</label>
  <input type="email" id="email" name="user[email]" required
         aria-describedby="email-hint"
         data-action="blur->form-validation#validate">
  <span id="email-hint" class="hint">We'll send a confirmation to this address.</span>
  <span class="field-error" data-form-validation-target="error" hidden></span>

  <label for="age">Age</label>
  <input type="number" id="age" name="user[age]" min="13" max="120" required>

  <label for="start_date">Start date</label>
  <input type="date" id="start_date" name="project[start_date]"
         min="2024-01-01" max="2030-12-31">
</form>

BAD

<form>
  <label for="email">Email</label>
  <input type="text" id="email" name="user[email]">
  

  <label for="age">Age</label>
  <input type="text" id="age" name="user[age]">
  

  <label for="start_date">Start date (YYYY-MM-DD)</label>
  <input type="text" id="start_date" name="project[start_date]">
  
</form>

すべてのフィールドで、制約なしの type="text" が使われています。入力エラーはすべて、サーバーへの送信後にしか検出されません。

レビュー時の確認事項：

• email、tel、url、number、date を使うべきフィールドに type="text" が設定されている場合は指摘します
• 入力必須のフィールドに required 属性がない場合は指摘します
• 数値フィールドに min／max の制約がない場合は指摘します
• クライアント側のバリデーションがなく、すべてのバリデーションをサーバー側に任せているフォームがある場合は指摘します
• 確認なしで破壊的な操作（削除、公開、送信）を行う場合は指摘します
• 妥当なデフォルト値が存在するのに設定されていない場合は指摘します

相互参照： laws-of-ux：テスラーの法則（システムがユーザーに代わって複雑さを引き受ける）、ポステルの法則（柔軟な入力形式を受け入れる）

---

H6：想起ではなく認識

定義：要素、操作、選択肢を見えるようにして、ユーザーの記憶への負荷を最小限に抑えます。ユーザーは、インターフェースのある部分から別の部分へ移動する際に、情報を覚えておく必要はありません。デザインを利用するために必要な情報は、表示されているか、簡単に確認できる状態にします。

重要なポイント：覚えさせるのではなく、見せましょう。ラベルは表示します（プレースホルダーだけにしない）。ナビゲーションは常に利用できるようにします。以前入力した情報は、その場で確認できるように表示します。

コードで確認する項目：

• ラベルとプレースホルダー：フォームフィールドに、placeholderテキストだけではなく、表示される<label>要素があることを確認します
• パンくずリスト：階層が深い場合、パンくずナビゲーションがあることを確認します
• 常時表示されるナビゲーション：デスクトップでメインナビゲーションがハンバーガーメニューの背後に隠れておらず、常にアクセスできることを確認します
• アイコンのラベル：アイコンのみのボタンに、表示されるテキストラベル、または少なくともaria-labelとツールチップがあることを確認します
• オートコンプリート：検索フィールドや選択フィールドに、入力候補表示やオートコンプリートがあることを確認します
• コンテキスト：編集フォームに空のフィールドではなく、現在の値が表示されることを確認します

例：

GOOD

<div class="form__group">
  <label for="search" class="form__label">Search projects</label>
  <input type="search" id="search" placeholder="e.g., Marketing website"
         list="recent-searches" autocomplete="on">
  <datalist id="recent-searches">
    <option value="Marketing website">
    <option value="Q4 Report">
  </datalist>
</div>


<button class="btn btn--icon-text">
  <svg aria-hidden="true"></svg>
  <span>Edit</span>
</button>


<nav aria-label="Breadcrumb">
  <ol class="breadcrumb">
    <li><a href="/projects">Projects</a></li>
    <li><a href="/projects/5">Marketing</a></li>
    <li aria-current="page">Settings</li>
  </ol>
</nav>

BAD

<input type="text" placeholder="Search...">



<div class="toolbar">
  <button><svg></svg></button>
  <button><svg></svg></button>
  <button><svg></svg></button>
  <button><svg></svg></button>
</div>

フィールドにフォーカスすると、プレースホルダーのみのラベルは表示されなくなります。アイコンのみのツールバーでは、アイコンの意味を覚えておく必要があります。

レビュー時の指摘事項：

• placeholderはあるものの、表示される<label>要素がないフォームフィールドを指摘します
• aria-label、title、または表示されるテキストがない、アイコンのみのボタンを指摘します
• パンくずナビゲーションがない、階層の深いページを指摘します
• デスクトップのビューポートで、メインナビゲーションがハンバーガーメニューの背後に隠れている場合は指摘します
• 現在の値が入力済みではなく、空のフィールドを表示する編集フォームを指摘します
• ユーザーがコードやIDを覚えておく必要があるドロップダウン／選択フィールドを指摘します

相互参照： laws-of-ux：ミラーの法則（ワーキングメモリーの限界）、系列位置効果（見つけやすさが重要な項目の配置）

---

H7：柔軟性と効率性

定義：初心者には表示されないショートカットを使うと、上級ユーザーは操作を効率化できます。これにより、経験の浅いユーザーと経験豊富なユーザーの両方に対応できます。頻繁に行う操作をユーザーがカスタマイズできるようにします。

重要なポイント：初心者にとってインターフェースを複雑にすることなく、パワーユーザー向けのアクセラレーターを用意します。キーボードナビゲーション、一括操作、カスタマイズをサポートします。

コードで確認する項目：

• キーボードショートカット：accesskey属性、カスタムのキーボードイベントハンドラー、またはショートカットを示すUIがあることを確認します
• 一括操作：リストビューに「すべて選択」や一括操作のパターンがあることを確認します
• 検索：グローバル検索機能またはコンテキストに応じた検索機能があることを確認します
• Tabキーによるナビゲーション：すべてのインタラクティブ要素にTabキーでアクセスできることを確認します
• スキップリンク：キーボードユーザーやスクリーンリーダー利用者向けの「コンテンツへスキップ」リンクがあることを確認します
• カスタマイズ：並べ替え可能な列、設定可能なビュー、または保存済みフィルターがあることを確認します

例：

GOOD

<a href="#main-content" class="skip-link">Skip to main content</a>


<div class="list-controls">
  <label class="checkbox">
    <input type="checkbox" data-action="change->bulk-select#toggleAll">
    Select all
  </label>
  <div class="bulk-actions" data-bulk-select-target="actions" hidden>
    <button class="btn btn--outline" data-action="click->bulk-select#archive">
      Archive selected
    </button>
    <button class="btn btn--danger" data-action="click->bulk-select#delete">
      Delete selected
    </button>
  </div>
</div>


<button class="btn btn--primary" title="New project (N)">
  New Project
  <kbd class="shortcut-hint">N</kbd>
</button>

BAD

<ul class="project-list">
  <li>Project A <a href="/projects/1/edit">Edit</a> <a href="/projects/1" data-method="delete">Delete</a></li>
  <li>Project B <a href="/projects/2/edit">Edit</a> <a href="/projects/2" data-method="delete">Delete</a></li>
  
</ul>

一括操作もキーボードショートカットもスキップリンクもなく、多数の項目を管理するパワーユーザーにとって非効率です。

レビュー時の指摘事項：

• 一括選択や一括操作がないリストビューを指摘します
• 頻繁に行う操作にキーボードショートカットがないアプリケーションを指摘します
• 「コンテンツへスキップ」リンクがないページを指摘します
• Tabキーでアクセスできないインタラクティブ要素を指摘します
• 検索中心のワークフローに検索入力欄がない場合は指摘します
• 並べ替え可能な列や保存済みフィルターの選択肢がないデータテーブルを指摘します

相互参照： laws-of-ux：パレートの法則（利用時間の80％を占める操作の20％を優先する）

---

H8：美的でミニマルなデザイン

定義：インターフェースには、無関係な情報やめったに必要とされない情報を含めるべきではありません。インターフェース内の情報は、余分なものが増えるたびに関連情報と競合し、関連情報の相対的な視認性を低下させます。

要点：現在のタスクに必要なものだけを表示します。二次的な情報は段階的開示の背後に配置します。視覚的なノイズを減らし、主要なアクションやコンテンツを目立たせます。

コードで確認する点：

• コンテンツの密度：ファーストビューにどれだけの情報が表示されているかを確認します
• 競合する CTA：ビューごとに、同程度に目立つアクションボタンの数を数えます
• 段階的開示：<details>／<summary>、展開／折りたたみのパターン、「さらに表示」リンクを探します
• 装飾要素：視覚的な重みは加えるものの、機能的な価値がない要素を確認します
• 余白：スペーシングトークンによってセクション間にゆとりが生まれているかを確認します
• テーブル：列数を確認します。展開表示や詳細ビューの背後に隠せる列はありませんか？

例：

GOOD

<div class="settings-section">
  <h3>Notifications</h3>
  <label class="toggle">
    <input type="checkbox" name="email_notifications" checked>
    Email notifications
  </label>
  <label class="toggle">
    <input type="checkbox" name="push_notifications">
    Push notifications
  </label>

  <details class="settings-advanced">
    <summary>Advanced notification settings</summary>
    <div class="settings-advanced__body">
      
    </div>
  </details>
</div>

BAD

<div class="settings-page">
  <h3>Notifications</h3>
  <label><input type="checkbox" checked> Email notifications</label>
  <label><input type="checkbox"> Push notifications</label>
  <label><input type="checkbox"> SMS notifications</label>
  <label><input type="checkbox"> Slack notifications</label>
  <label><input type="checkbox"> Weekly digest</label>
  <label><input type="checkbox"> Daily summary</label>

  <h4>Email frequency</h4>
  <select><option>Immediate</option><option>Hourly</option><option>Daily</option></select>

  <h4>Quiet hours</h4>
  <input type="time" name="quiet_start"> to <input type="time" name="quiet_end">

  <h4>Per-channel overrides</h4>
  
</div>

階層や段階的開示がなく、すべての設定が1ページに詰め込まれています。高度なオプションが基本設定と同じように注意を引こうとしています。

レビュー時の指摘事項：

• 同程度に目立つ CTA が3つ以上あるビューを指摘します
• 高度なオプションに段階的開示がない設定ページや構成ページを指摘します
• すべてのウィジェットが同じ視覚的な重みを持つダッシュボードを指摘します
• 機能的な目的のない装飾画像、イラスト、アイコンを指摘します
• 6～7列を超えるデータが同時に表示されるテーブルを指摘します
• アクションが中心の場面（フォーム、ダイアログ、ツールバー）で、本文が冗長な箇所を指摘します

相互参照： laws-of-ux：オッカムの剃刀（最もシンプルな解決策）、プレグナンツの法則（視覚的なシンプルさ）、ヒックの法則（選択肢を減らすと意思決定が速くなる）。最小限のトークンベースのスタイルについては、optics-context も参照してください。

---

H9：ユーザーがエラーを認識し、原因を特定して、解決できるようにする

定義：エラーメッセージは平易な言葉で記述し（エラーコードを使わず）、問題を正確に示し、解決策を建設的に提案する必要があります。

要点：エラーが発生したときは、何が問題だったのかをユーザーにわかりやすく伝え、問題の箇所を示し、修正するための明確な手順を提示します。システムの生のエラーを表示してはいけません。

コードで確認する点：

• フラッシュ／トーストメッセージ：エラー内容が具体的で対処可能か、汎用的な表現（「問題が発生しました」など）ではないかを確認します
• フォームのバリデーション：ページ上部の要約だけでなく、フィールドの横にインラインエラーが表示されるかを確認します
• エラーの要約：フォームのエラー要約から、問題のあるフィールドに移動できるかを確認します
• HTTP エラーページ（404、500）：ナビゲーションの選択肢を含む有用なコンテンツがあるかを確認します
• フィールドの強調表示：エラーのあるフィールドに視覚的な目印（赤い枠線、アイコンなど）があるかを確認します
• フォーカス管理：フォーム送信の失敗時に、最初のエラーへフォーカスが移動するかを確認します

例：

GOOD

<div class="error-summary" role="alert" tabindex="-1">
  <h3>There were 2 problems with your submission:</h3>
  <ul>
    <li><a href="#user_email">Email address is not valid</a></li>
    <li><a href="#user_password">Password must be at least 8 characters</a></li>
  </ul>
</div>


<div class="form__group form__group--error">
  <label for="user_email">Email address</label>
  <input type="email" id="user_email" class="input--error"
         aria-describedby="email-error" aria-invalid="true">
  <span id="email-error" class="field-error" role="alert">
    Please enter a valid email address, e.g., [email protected]
  </span>
</div>

BAD

<div class="alert alert--error">
  <p>There were errors.</p>
</div>


<div class="form__group">
  <label for="user_email">Email</label>
  <input type="text" id="user_email">
  
</div>

どのフィールドが間違っているのか、どう修正すればよいのかがわからない汎用的なエラーバナーです。

レビュー時の指摘事項：

• 具体的な説明のない汎用的なエラーメッセージ（「エラー」「問題が発生しました」「入力が無効です」）を指摘します
• インラインのフィールドエラーがなく、ページ上部の要約だけに表示されるフォームエラーを指摘します
• エラーメッセージに関連付ける aria-invalid="true" と aria-describedby がないエラー状態を指摘します
• 問題の修正方法を提案しないエラーメッセージを指摘します
• ナビゲーションの選択肢や検索機能のない 404／500 エラーページを指摘します
• 送信に失敗した際、エラーの要約または最初のエラーフィールドにフォーカスが移動しないフォームを指摘します

相互参照： laws-of-ux：ピーク・エンドの法則（エラーからの回復は、全体的な体験を左右する「ピーク」の瞬間です）、ポステルの法則（柔軟な入力を受け入れることで、そもそものエラーを減らせます）

---

H10：ヘルプとドキュメント

定義：システムには追加の説明が不要であることが理想です。ただし、ユーザーがタスクの完了方法を理解できるよう、ドキュメントの提供が必要な場合もあります。そのような情報は検索しやすく、ユーザーのタスクに焦点を当て、実行すべき具体的な手順を示し、分量が多すぎないようにします。

重要なポイント：ユーザーが必要とする場面で、文脈に沿ったヘルプを提供します。複雑なフィールドのツールチップ、空の状態での案内、オンボーディングのヒントなどです。ヘルプはタスクに焦点を当て、文脈の中に表示し、別のページへの移動を必要としないようにします。

コードで確認する項目：

• ツールチップ：複雑なフィールドに title、aria-describedby、または Stimulus のツールチップコントローラーがあるか確認します
• 空の状態：空のリストやテーブルに、次に何をすればよいかの案内があるか確認します
• オンボーディング：初回起動時のヒント、セットアップチェックリスト、またはガイド付きツアーがあるか確認します
• ヘルプテキスト：複雑なフォームフィールドの下に <span class="hint"> などの要素があるか確認します
• インラインドキュメント：折りたたみ可能なヘルプコンテンツに <details>／<summary> が使われているか確認します
• ドキュメントへのリンク：複雑な機能の近くに、文脈に応じた「詳細はこちら」リンクがあるか確認します

例：

GOOD

<div class="empty-state">
  <svg class="empty-state__icon" aria-hidden="true"></svg>
  <h3>No projects yet</h3>
  <p>Projects help you organize your work and track progress with your team.</p>
  <a href="/projects/new" class="btn btn--primary">Create your first project</a>
  <a href="/help/projects" class="link">Learn more about projects</a>
</div>


<div class="form__group">
  <label for="api_key">API Key</label>
  <input type="text" id="api_key" aria-describedby="api-key-help">
  <span id="api-key-help" class="hint">
    Find your API key in your
    <a href="/account/integrations" target="_blank">integration settings</a>.
  </span>
</div>

BAD

<div class="empty-state">
  <p>No projects.</p>
</div>


<div class="form__group">
  <label for="cron">Schedule (cron expression)</label>
  <input type="text" id="cron" name="schedule[cron]" placeholder="* * * * *">
  
</div>

空の状態では、プロジェクトとは何か、またはプロジェクトの作成方法が案内されていません。複雑なフィールドには専門知識が必要ですが、ヘルプがありません。

レビュー時の指摘事項：

• 案内や CTA がなく、「項目がありません」や「結果がありません」としか表示しない空の状態を指摘します
• ヘルプテキストやツールチップのない、複雑または技術的なフォームフィールドを指摘します
• オンボーディングや初回起動時の説明がない機能を指摘します
• 関連するヘルプテキストがあるフィールドに aria-describedby がない場合は指摘します
• 現在のタスクの文脈から離れる必要があるヘルプコンテンツを指摘します
• 例やリンクがない、ドキュメントを多く必要とするフィールド（cron、regex、API 設定など）を指摘します

関連項目： laws-of-ux：ツァイガルニク効果（セットアップとオンボーディングのタスク完了を促す）

---

複数のヒューリスティックにまたがる考慮事項

複数のヒューリスティックは互いに補強し合います。監査時は、同じ問題を複数のヒューリスティックに重複して報告するのではなく、関連する指摘をまとめてください。

フィードバックループ：H1 + H9 + H3

この3つのヒューリスティックは、完全なフィードバックサイクルを形成します。

• H1（可視性）：システムが何が起きているかを示します
• H9（エラーからの回復）：問題が起きたとき、システムが明確に説明します
• H3（ユーザーの制御）：ユーザーが中断、取り消し、または再試行できます

フォームやワークフローを監査するときは、3つをまとめて確認します。読み込み中のフィードバックがなく（H1）、一般的なエラーが表示され（H9）、キャンセルボタンもない（H3）フォームには、使いやすさの問題が重なっています。これらは一連の問題として報告します。

一貫性のまとまり：H4 + H6 + H8

この3つのヒューリスティックは互いに支え合います。

• H4（一貫性）：どこでも同じパターンを使います
• H6（認識）：一貫したパターンは認識しやすくなります
• H8（ミニマリズム）：一貫性によって視覚的なノイズが減ります

一貫性のない UI は、記憶を必要とさせ（H6 に違反）、視覚的な複雑さを増やします（H8 に違反）。一貫性の欠如を見つけた場合は、認識やミニマリズムの問題も引き起こしていないか確認します。

防止と回復：H5 + H9

この2つは、エラー処理の両面です。

• H5（防止）：エラーが起きる前に防ぎます
• H9（回復）：実際に起きたエラーをユーザーが修正できるようにします

エラー処理を監査するときは、両方を確認します。不正な入力を防止せず（H5）、エラーも明確に説明しない（H9）フォームには、問題が重なっています。

言語とヘルプ：H2 + H10

この2つのヒューリスティックは、どちらもコミュニケーションを扱います。

• H2（現実世界との一致）：ユーザーの言葉を使います
• H10（ヘルプとドキュメント）：必要な場面で案内を提供します

システムが専門用語を使うと（H2 違反）、ドキュメントの必要性が高まります（H10）。H2 の問題を修正するときは、H10 による補足も必要かどうか確認します。

---

関連スキル

• laws-of-ux：ヒューリスティック評価での指摘が特定の法則に該当する場合、UX の法則に関する詳細なガイダンスとして使用します。ヒューリスティック評価では監査の手法を提供し、laws-of-ux では理論的な根拠と、コードレベルの追加例を提供します。
• bem-structure：ヒューリスティック違反の修正を実装する際、CSS クラスの命名規則に使用します。特に H4（一貫性）と H8（ミニマリズム）に有用です。
• optics-context：視覚的な修正を実装する際、デザイントークンの使用に関するガイダンスとして利用します。特に H4（一貫性 — トークンとハードコード値の使い分け）、H8（ミニマリズム — すっきりとしたスタイル）、H1（視認性 — フィードバック状態における色と余白）に有用です。