ux-review

UX レビュー

ユーザビリティ、アクセシビリティ、インタラクションデザインの観点を総合し、コンポーネント、フロー、機能を徹底的に分析するユーザーエクスペリエンスレビューです。

このスキルを使う場面

• リリース前に新しいコンポーネントや機能をレビューするとき
• 既存のフローにユーザビリティの問題がないか評価するとき
• UI/UX コードに関する PR をレビューするとき
• デザインシステムのコンポーネントをレビューするとき
• オンボーディングフローやチェックアウトフローを最適化するとき
• 純粋に見た目や美しさだけをレビューする場合は使わないでください。その場合は ui-design-aesthetics を使います

ワークフロー

ステップ 1：コンテキストを把握する

レビューを始める前に、次の質問に答えてください。

1. ユーザーは何を達成しようとしていますか？
2. このコンポーネントは、全体のフローの中でどのような役割を果たしていますか？
3. 対象ユーザーは誰ですか？（ペルソナ、スキルレベル）
4. 成功の基準は何ですか？

ステップ 2：ヒューリスティック評価を実施する（Nielsenの10原則）

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

ヒューリスティック	確認項目
システム状態の可視性	ユーザーは常に何が起きているか把握できますか？
現実世界との一致	馴染みのある言葉や概念を使っていますか？
ユーザーの制御と自由	ユーザーは操作を元に戻したり、前に戻ったり、抜け出したりできますか？
一貫性と標準	プラットフォームの慣習に従っていますか？
エラーの防止	間違いが起きる前に防げていますか？
想起より再認	情報は記憶に頼らず、画面上で確認できますか？
柔軟性と効率性	熟練ユーザー向けのショートカットはありますか？
美的でミニマルなデザイン	すべての要素に必要性がありますか？
エラーからの回復	エラーメッセージは役立ち、対処方法が明確ですか？
ヘルプとドキュメント	必要なときにガイダンスを利用できますか？

ステップ 3：複数の視点から分析する

ユーザビリティの視点

• ユーザーフロー：完了までの道筋は明確で効率的ですか？
• 情報アーキテクチャ：コンテンツは論理的に整理されていますか？
• 認知負荷：インターフェースがユーザーに負担をかけすぎていませんか？
• メンタルモデル：ユーザーの期待どおりに動作しますか？

アクセシビリティの視点（WCAG 2.1 AA）

• キーボードナビゲーション：マウスなしですべての操作を行えますか？
• スクリーンリーダー：支援技術を使うユーザーも同等の体験を得られますか？
• 色のコントラスト：すべてのテキストと UI 要素が 4.5:1 の比率を満たしていますか？
• フォーカス管理：フォーカスの順序は論理的で、視認でき、閉じ込められることがありませんか？

<button aria-label="Close dialog" aria-describedby="close-hint">
  <svg aria-hidden="true"></svg>
</button>
<span id="close-hint" class="sr-only">Press Escape to close</span>

インタラクションデザインの視点

• 状態の網羅性：すべての状態（読み込み中、空、エラー、成功）に対応していますか？
• フィードバック：ユーザーは操作が成功したことを把握できますか？
• トランジション：アニメーションには目的があり、300ms 未満ですか？
• プログレッシブディスクロージャー：複雑さは適切なタイミングで提示されていますか？

ステップ 4：指摘事項に優先順位を付ける

すべての指摘事項を分類してください。

優先度	基準	対応
重大	ユーザビリティを妨げる、または WCAG AA に準拠していない	リリース前に必ず修正
高	エクスペリエンスを大きく損なう	現在のスプリントで修正
改善	満足度と効率性を向上させる	次のイテレーションのバックログに追加
将来	長期的な改善	ロードマップで追跡

ステップ 5：レビュー報告書を作成する

## UX Review: [Component/Flow Name]

### Summary
[2-3 sentence executive summary]

### Critical Issues
- [ ] Issue 1: [Description, impact, WCAG criterion if applicable]
- [ ] Issue 2: [Description, impact]

### Recommendations by Category

#### Usability
| Finding | Impact | Recommendation |
|---------|--------|----------------|
| [Issue] | High/Med/Low | [Fix] |

#### Accessibility
| Finding | WCAG Criterion | Recommendation |
|---------|----------------|----------------|
| [Issue] | [2.x.x Level] | [Fix] |

#### Interaction Design
| Finding | Impact | Recommendation |
|---------|--------|----------------|
| [Issue] | High/Med/Low | [Fix] |

### Next Steps
1. Create issues for critical findings
2. Add accessibility requirements to acceptance criteria
3. Schedule follow-up review after fixes

領域別の詳細レビュー

--focus を使ってレビュー範囲を絞り込みます。

• --focus=ux：ユーザーフローのマッピング、タスク効率、エラーからの回復、習得しやすさ
• --focus=a11y：WCAG 2.1 AA の監査、キーボードナビゲーション、スクリーンリーダー、コントラスト、フォーカス管理
• --focus=interaction：状態の網羅性、フィードバックのタイミング、マイクロインタラクション、アニメーションのレビュー

ベストプラクティス

• 実際のコンテンツでテストする — Lorem ipsum では情報アーキテクチャの問題が隠れてしまいます
• すべての状態を確認する — 空、読み込み中、エラー、成功、エッジケースの各状態を確認します
• キーボード操作の流れを検証する — マウスを使わず、コンポーネント全体を Tab キーで操作します
• ブラウザーの開発者ツールを使う — Lighthouse のアクセシビリティ監査で、簡単に修正できる問題を見つけられます
• 優先順位を厳しく付ける — 提案を大量に並べるより、重大な修正に絞ったリストのほうが効果的です