review-ux-ui

UX/UI のレビュー

ユーザビリティ、アクセシビリティ、有効性の観点から、ユーザーエクスペリエンスとインターフェースデザインを評価します。

使用する場面

• リリース前にアプリケーションのユーザビリティレビューを実施する
• アクセシビリティへの準拠状況（WCAG 2.1 AA または AAA）を評価する
• ユーザーフローの効率性とエラー防止を評価する
• 使いやすさとコンバージョンの最適化に向けてフォームデザインをレビューする
• 既存のインターフェースをヒューリスティック評価する
• 認知負荷と情報アーキテクチャを評価する

入力

• 必須：レビュー対象のアプリケーション（URL、プロトタイプ、またはソースコード）
• 必須：対象ユーザーの説明（役割、技術的な習熟度、利用状況）
• 任意：ユーザー調査の結果（インタビュー、アンケート、分析データ）
• 任意：WCAG 準拠目標（A、AA、または AAA）
• 任意：評価する特定のユーザーフローまたはタスク
• 任意：テストに使用する支援技術（スクリーンリーダー、スイッチアクセス）

手順

ステップ 1：ヒューリスティック評価（Nielsen の 10 ヒューリスティック）

各ヒューリスティックに照らしてインターフェースを評価します。

#	ヒューリスティック	主な質問	評価
1	システム状態の可視性	システムは、現在何が起きているかを常にユーザーに知らせていますか？
2	システムと現実世界の一致	システムは、ユーザーになじみのある言葉や概念を使っていますか？
3	ユーザーのコントロールと自由	ユーザーは、操作を簡単に元に戻したり、やり直したり、望まない状態から抜け出したりできますか？
4	一貫性と標準	類似した要素は、全体を通じて同じように動作しますか？
5	エラーの防止	デザインは、エラーが起きる前に防いでいますか？
6	想起より認識	選択肢、操作、情報は、表示されているか、簡単に確認できますか？
7	柔軟性と効率性	初心者を混乱させることなく、経験豊富なユーザー向けのショートカットが用意されていますか？
8	美的でミニマルなデザイン	すべての要素に役割がありますか？不要な情報が含まれていませんか？
9	ユーザーがエラーを認識し、診断し、回復できるようにする	エラーメッセージは明確で具体的、かつ建設的ですか？
10	ヘルプとドキュメント	必要なときにヘルプを利用でき、簡単に見つけられますか？

各ヒューリスティックについて、違反の重大度を評価します。

重大度	説明
0	ユーザビリティ上の問題ではない
1	表面的な問題 — 時間があれば修正
2	軽微 — 優先度の低い修正
3	重大 — 修正が重要で、優先度が高い
4	致命的 — リリース前に必ず修正

## Heuristic Evaluation Findings
| # | Heuristic | Severity | Finding | Location |
|---|-----------|----------|---------|----------|
| 1 | System status | 3 | No loading indicator during data fetch — users click repeatedly | Dashboard page |
| 3 | User control | 2 | No undo for item deletion — only a confirmation dialog | Item list |
| 5 | Error prevention | 3 | Date field accepts invalid dates (Feb 30) | Booking form |
| 9 | Error recovery | 4 | Form submission error clears all fields | Registration |

期待される結果： 10 項目すべてのヒューリスティックについて、具体的な所見と重大度の評価が示されていること。 失敗時： 時間が限られている場合は、ユーザーエクスペリエンスに最も大きな影響を与える 1、3、5、9 に重点を置きます。

ステップ 2：アクセシビリティ監査（WCAG 2.1）

知覚可能

• 1.1.1 テキスト以外のコンテンツ：すべての画像に代替テキストがある（装飾画像には alt="" を指定）
• 1.3.1 情報と関係性：セマンティック HTML が使用されている（見出し、リスト、テーブル、ランドマーク）
• 1.3.2 意味のある順序：DOM の順序が視覚的な順序と一致している
• 1.4.1 色の使用：情報を伝える手段が色だけに限られていない
• 1.4.3 コントラスト：テキストのコントラスト比が 4.5:1 以上（通常の文字）、3:1 以上（大きな文字）
• 1.4.4 テキストのサイズ変更：機能を損なうことなく、テキストを 200% まで拡大できる
• 1.4.11 非テキストのコントラスト：UI コンポーネントとグラフィックのコントラスト比が 3:1 以上
• 1.4.12 テキストの間隔：テキスト間隔を広げてもコンテンツが適切に表示される（行の高さ 1.5 倍、文字間隔 0.12em、単語間隔 0.16em）

操作可能

• 2.1.1 キーボード：すべての機能をキーボードで操作できます
• 2.1.2 キーボードトラップなし：コンポーネント内にフォーカスが閉じ込められることはありません
• 2.4.1 スキップリンク：キーボードユーザーが利用できるナビゲーションスキップリンクがあります
• 2.4.3 フォーカス順序：Tab キーによる移動順序は、論理的で予測しやすい順序になっています
• 2.4.7 フォーカスの可視性：キーボードのフォーカスインジケーターが明確に表示されます
• 2.4.11 フォーカスが隠れない：フォーカスされた要素が、固定ヘッダーやオーバーレイの背後に隠れていません
• 2.5.5 ターゲットサイズ：操作対象のサイズは 24x24px 以上です（タッチ操作では 44x44px を推奨）

理解可能

• 3.1.1 ページの言語：<html> に lang 属性が設定されています
• 3.2.1 フォーカス時：フォーカスによって予期しない変化が発生しません
• 3.2.2 入力時：警告なしに入力によって予期しない変化が発生することはありません
• 3.3.1 エラーの特定：エラーがテキストで明確に説明されています
• 3.3.2 ラベルまたは説明：フォーム入力項目に表示ラベルがあります
• 3.3.3 エラーの修正方法：エラーメッセージに問題の修正方法が示されています

堅牢

• 4.1.1 構文解析：HTML が有効です（ID の重複がなく、適切にネストされています）
• 4.1.2 名前、役割、値：カスタムコンポーネントに ARIA のロールとプロパティが設定されています
• 4.1.3 ステータスメッセージ：動的なコンテンツの変更がスクリーンリーダーに通知されます

期待される結果： WCAG 2.1 AA の各基準を体系的に確認し、基準ごとに合格または不合格を判定します。 失敗した場合： 初期スキャンには自動ツール（axe-core、Lighthouse）を使用し、人による判断が必要な基準については手動でテストします。

ステップ 3：キーボードとスクリーンリーダーの監査

キーボードナビゲーションのテスト

Tab、Shift+Tab、Enter、Space、矢印キー、Escape のみを使用します。

## Keyboard Navigation Audit
| Task | Completable? | Issues |
|------|-------------|--------|
| Navigate to main content | Yes — skip link works | None |
| Open dropdown menu | Yes | Arrow keys don't work within menu |
| Submit a form | Yes | Tab order skips the submit button |
| Close a modal | No | Escape doesn't close, no visible close button in tab order |
| Use date picker | No | Custom date picker not keyboard accessible |

スクリーンリーダーのテスト

NVDA（Windows）、VoiceOver（macOS/iOS）、または TalkBack（Android）でテストします。

## Screen Reader Audit
| Element | Announced As | Expected | Issue |
|---------|-------------|----------|-------|
| Logo link | "link, image" | "Home, link" | Missing alt text on logo |
| Search input | "edit, search" | "Search products, edit" | Missing label association |
| Nav menu | "navigation, main" | Correct | None |
| Error message | (not announced) | "Error: email is required" | Missing live region |
| Loading spinner | (not announced) | "Loading, please wait" | Missing aria-live or role="status" |

期待される結果： キーボードのみの操作とスクリーンリーダーを使って、タスクの一連の流れをすべてテストします。 失敗した場合： スクリーンリーダーを利用できない場合は、代替手段として ARIA 属性とセマンティック HTML を確認します。

ステップ 4：ユーザーフローを分析する

主要なユーザーフローを洗い出して評価します。

## User Flow: Complete a Purchase

### Steps
1. Browse products → 2. View product → 3. Add to cart → 4. View cart →
5. Enter shipping → 6. Enter payment → 7. Review order → 8. Confirm

### Assessment
| Step | Friction | Severity | Notes |
|------|---------|----------|-------|
| 1→2 | Low | - | Clear product cards |
| 2→3 | Medium | 2 | "Add to cart" button below the fold on mobile |
| 3→4 | Low | - | Cart icon updates with count |
| 4→5 | High | 3 | Must create account — no guest checkout |
| 5→6 | Low | - | Address autocomplete works well |
| 6→7 | Medium | 2 | Card number field doesn't auto-format |
| 7→8 | Low | - | Clear order summary |

### Flow Efficiency
- **Steps**: 8 (acceptable for e-commerce)
- **Required fields**: 14 (could reduce with address autocomplete + saved payment)
- **Decision points**: 2 (size selection, shipping method)
- **Potential drop-off points**: Step 4→5 (forced account creation)

期待される結果： 重要なユーザーフローを洗い出し、操作上の障害を特定して評価します。 失敗した場合： ユーザー分析データを利用できない場合は、タスクの複雑さと手順数に基づいてフローを評価します。

ステップ 5：認知負荷を評価する

• 情報密度：画面ごとの情報量は適切ですか？
• 段階的な開示：複雑な情報は段階的に表示されますか？
• チャンク化：関連項目は視覚的にグループ化されていますか（ゲシュタルト原則）？
• 想起より認識：ユーザーは選択肢を覚えておくのではなく、画面上で確認できますか？
• 一貫したパターン：類似したタスクに、類似した操作パターンが使われていますか？
• 意思決定疲れ：一度に多くの選択肢を提示していませんか？（ヒックの法則）
• ワーキングメモリー：ユーザーは手順をまたいで情報を記憶しておく必要がありますか？

期待される結果： 認知負荷を評価し、過負荷または負荷不足がある具体的な箇所を特定します。 失敗した場合： 認知負荷を客観的に評価するのが難しい場合は、「目を細めるテスト」を使います。画面に目を細めて、構造と階層がまだ判別できるか確認します。

ステップ 6：フォームの使いやすさを確認する

アプリケーション内の各フォームについて、次の項目を確認します。

• ラベル：すべての入力項目に、関連付けられた視認可能なラベルがある
• プレースホルダーテキスト：ラベルではなく、入力例としてのみ使用されている
• 入力タイプ：モバイルキーボードに適した HTML 入力タイプ（email、tel、number、date）が指定されている
• 検証のタイミング：エラーはフォーカスが外れたとき、または送信時に表示される（キー入力ごとには表示されない）
• エラーメッセージ：一般的な内容（「入力が無効です」）ではなく、具体的な内容（「メールアドレスには @ を含める必要があります」）になっている
• 必須項目：必須項目が明確に示されている（必須項目が大半の場合は、任意項目にもその旨が示されている）
• フィールドのグループ化：関連するフィールドが視覚的にグループ化されている（氏名、住所、支払いなどのセクション）
• オートコンプリート：標準的なフィールド（氏名、メールアドレス、住所、クレジットカード番号）に autocomplete 属性が設定されている
• タブ順序：視覚的なレイアウトに沿った論理的な順序になっている
• 複数ステップのフォーム：進行状況インジケーターに現在のステップと総ステップ数が表示されている
• データの保持：ユーザーがページを離れて戻ってきた場合も、フォームのデータが保持される

期待される結果： 各フォームがチェックリストに照らして評価され、具体的な問題点が記録されていること。 失敗した場合： フォームが多数ある場合は、利用頻度が最も高いフォーム（登録、チェックアウト、お問い合わせ）を優先します。

ステップ 7：UX/UI レビューを作成する

## UX/UI Review Report

### Executive Summary
[2-3 sentences: overall usability, most critical issues, strongest aspects]

### Heuristic Evaluation Summary
| Heuristic | Severity | Key Finding |
|-----------|----------|-------------|
[Summary table from Step 1]

### Accessibility Compliance
- **Target**: WCAG 2.1 AA
- **Status**: [X of Y criteria pass]
- **Critical failures**: [List]

### User Flow Analysis
[Key friction points with severity and recommendations]

### Top 5 Improvements (Prioritised)
1. **[Issue]** — Severity: [N] — [Specific recommendation]
2. ...

### What Works Well
1. [Specific positive observation]
2. ...

期待される結果： レビューに、重大度の評価を付けた、優先順位が明確で実行可能な推奨事項が含まれていること。 失敗した場合： レビューで問題が多く見つかった場合は、「必ず修正」（重大度 3～4）と「修正を推奨」（重大度 1～2）に分類します。

検証

• ニールセンの 10 のユーザビリティヒューリスティックすべてを、重大度を評価して確認した
• WCAG 2.1 の基準を確認した（最低限：1.1.1、1.4.3、2.1.1、2.4.7、3.3.1、4.1.2）
• 主要なユーザーフローでキーボード操作をテストした
• スクリーンリーダーをテストした（または代替手段として ARIA／セマンティック HTML を確認した）
• 少なくとも 1 つの重要なユーザーフローを分析し、操作上の障壁を確認した
• 認知負荷を評価した
• フォームの使いやすさを評価した
• 実行可能な推奨事項とともに、重大度に基づいて問題点に優先順位を付けた

よくある落とし穴

• UX とビジュアルデザインを混同する：UX は使いやすさ、ビジュアルデザインは見た目に関するものです。インターフェースが美しくても、UX が非常に悪い場合があります。どちらも評価しつつ、区別してください。
• 問題なく進むケースだけをテストする：エラー状態、空の状態、読み込み中の状態、エッジケースには、UX の問題が潜んでいます。
• 実機を無視する：ブラウザーの開発者ツールにあるレスポンシブモードは、実機テストの代替手段です。実機でテストすると、タッチ操作、パフォーマンス、ビューポートに関する問題を発見できます。
• アクセシビリティを後回しにする：アクセシビリティの問題は、発見が遅れるほど修正コストが高くなります。早い段階から継続的に評価してください。
• 個人的な好みを UX のフィードバックにする：「私はこうしたい」は UX のフィードバックではありません。ヒューリスティック、調査、または確立されたパターンを根拠として示してください。

関連スキル

• review-web-design — ビジュアルデザインのレビュー（レイアウト、タイポグラフィ、色 — UX を補完します）
• scaffold-nextjs-app — Next.js アプリケーションのスキャフォールディング
• setup-tailwind-typescript — デザインシステムの実装に向けた Tailwind CSS