usability-testing

ユーザビリティテスト

ユーザーが本番環境で問題に直面する前に、ユーザビリティの問題を見つけるテストを計画して実施します。技術スタックやツールを問いません。

このスキルは、既存のデザインやプロトタイプをテストするためのものです。より幅広い探索的調査には、ux-researchを使用してください。本番環境でのコンバージョンテストには、cro-optimizationを使用してください。

---

使用するタイミング

• 新しいフローや大規模なデザイン変更を公開する前
• デザイン変更後、新たな問題が生じていないことを確認するとき
• 分析で離脱が見られるものの、原因が分からないとき
• 特定の UI 領域に関するカスタマーサポートへの問い合わせが繰り返されているとき
• 公開前のユーザー検証
• 2つのデザイン案を比較するとき

使用しないタイミング

• 探索的調査／生成的調査（ux-researchを使用）
• リリース後のコンバージョン最適化（cro-optimizationを使用）
• より広い体験をマッピングするとき（journey-mappingを使用）
• 純粋な定量測定（analytics-strategyを使用）

---

必要な入力

• テストするデザインまたはプロトタイプ（機能するもの、またはほぼ機能するもの）
• ユーザーが実行する具体的なタスク
• 対象者（誰をテストするか）
• テスト環境（モデレーター付きツール、非モデレーター型ツール、対面でのセットアップ）

---

フレームワーク：5つのフェーズ

1. テスト内容を決める

製品全体をテストするのではなく、具体的なタスクをテストします。

タスクの選定基準：

• 実際のユーザーの目標を表している（「クリックして見て回る」ではない）
• 明確な開始点と終了点がある
• 2〜10分で完了できる
• 次のいずれかに当てはまる：最もよく行われる、最も戦略的である、または最も問題が多い

テスト可能なタスクの例：

「近くでフェンスを設置できる業者を探しています。このサイトでの探し方を見せてください。」

「初めてこのサイトを訪れました。この製品が自分のニーズに合うか知りたいと思っています。どのように評価するか、順を追って見せてください。」

「チームでプロジェクト管理用の新しいツールが必要です。12人のチームに適したプランを、このサイトで探してください。」

タスクの提示ルール：

• システム上の操作ではなく、ユーザーの目標を伝える（「宿泊先を探す」であり、「検索ボタンをクリックする」ではない）
• 背景を説明する（なぜそれをするのか）
• 進むべき道筋を明かさない
• タスクの提示に製品用語を使わない

2. モデレーター付きか、モデレーターなしかを選ぶ

モデレーター付き（調査担当者がリアルタイムで参加）：

• 調査担当者がリアルタイムで観察し、質問を掘り下げます
• 初期段階のプロトタイプ、複雑なタスク、斬新なコンセプトに最適です
• コストは高く、サンプル数は少なめです（通常、参加者5〜8人）
• 想定外のことを捉え、さらに深く掘り下げられます

モデレーターなし（録画、非同期）：

• 参加者が単独でタスクを完了します。多くの場合、ツール（UserTesting、Maze、Lookback）を使用します
• 安定したデザイン、単純なタスク、より大きなサンプルに最適です
• コストは低く、サンプル数は多めです（通常、参加者15〜30人）
• 大規模な傾向を捉えられますが、セッションごとの深さは劣ります

ほとんどのチームでは、初期段階の重要な判断にはモデレーター付き、継続的な検証にはモデレーターなしを使用します。

3. 参加者を募集する

都合のよい人ではなく、対象となるユーザーを選びます。

募集基準：

• 実際のユーザーに合致している（対象者であり、「誰でも」ではない）
• 製品の利用経験に幅を持たせる（該当する場合は、新規ユーザーと既存ユーザー）
• 関連するデバイスの種類に幅を持たせる（該当する場合は、モバイル、デスクトップ、タブレット）
• 友人、家族、従業員を除外する

サンプルサイズ：

• モデレーター付き：参加者5〜8人（Nielsenの「5人のユーザーで、最も一般的なセグメントにおけるユーザビリティの問題の85％を発見できる」）
• モデレーターなし：参加者15〜30人（掘り下げが少ない分、参加者を増やして補います）
• 複数セグメントのテスト：セグメントごとに5〜8人

4. テストを実施する

事前準備：

• 録画が機能することを確認します
• 参加者に概要を説明します（目的、匿名性、録画、「間違った答えはありません」）
• 口頭で同意を得ます
• リモートの場合は、参加者に画面を共有してもらいます

モデレーター付きセッションの構成：

1. ウォームアップ（2～3分）。参加者がリラックスできるよう、簡単な質問をします。
2. テスト前の質問（3～5分）。背景情報や、類似製品を現在どのように使っているかを確認します。
3. タスク1（5～10分）。タスクを説明します。参加者に考えを声に出してもらいながら、実際に試してもらいます。
4. タスク後の質問（1～2分）。簡単だった点、難しかった点、わかりにくかった点がないかを尋ねます。
5. タスク2、3、4について繰り返します（通常、60分のセッションで3～5個のタスクを実施します）。
6. 全体の振り返り（5～10分）。全般的な印象、代替製品との比較、その他の意見を尋ねます。
7. 終了（2分）。

モデレーションの原則：

• シンクアラウドを促します（「今、どんなことを考えていますか？」）
• 参加者が本当に行き詰まるまでは手助けしません（その場合も、長く止まってからにします）
• 誘導しません（「メニューを探していますか？」は避けます）
• 参加者がためらう、スクロールする、前の画面に戻る箇所を記録します
• 参加者の言葉と製品で使われている言葉を記録します
• 感情的な反応を記録します

アンチパターン：

• 話しすぎる（リサーチャーが話すのは、全体の20％程度に抑えます）
• 参加者が苦戦したときにデザインを擁護する
• 早まって手助けする
• 参加者に将来の行動を予測するよう求める
• 参加者の提案を機能要望として扱う（「ユーザーはXを求めている」場合、Xの需要は別途テストします）

5. 統合して報告する

参加者間に見られるパターンは有意な兆候です。1人の参加者だけの不満は根拠として弱いものの、調査する価値はあります。

統合の手順：

1. 問題の一覧化。 観察したすべての問題について、該当する参加者、タスク、深刻度を記録します。
2. グループ化。 根本原因が同じ問題をまとめます。
3. 深刻度。
   • 重大： タスクの完了を妨げます。ほとんどのユーザーが遭遇します。
   • 大： タスクを大幅に遅らせます。多くのユーザーが遭遇します。
   • 小： 操作上の摩擦があります。一部のユーザーが遭遇します。回避策があります。
   • 軽微： 仕上げに関する問題です。タスクには影響しません。
4. 推奨事項。 各問題に対して、具体的な修正案を提示します。
5. 優先順位付け。 深刻度と作業量に基づいて順位を付けます。

レポートの構成：

# Usability Test: [Design / flow]

## Summary
[2 to 3 paragraphs covering: what was tested, headline findings, top 3 priorities]

## Method
[Moderated/unmoderated, sample size, audience, dates, tasks]

## Critical findings
[Each with description, frequency, supporting evidence (quotes/clips), recommendation. Where evidence was not obtained, state the gap per the data-availability rule]

## Major findings
[Same structure]

## Minor findings
[Brief]

## Cosmetic findings
[Briefest]

## What worked well
[Calibration: capture successes too]

## Recommendations
[Prioritized list with effort estimates]

## Next steps
[Test re-run schedule, design iteration plan]

---

ワークフロー

1. 目標を定義します。 どのような意思決定に関わりますか？ 最も重要なタスクは何ですか？
2. タスクを設計します。 目標を意識した、具体的で現実的なタスクを3～5個用意します。
3. モデレーター付きか、モデレーターなしかを選びます。 調査段階と必要な深さに合わせます。
4. 参加者を募ります。 対象者を具体的に定めます。
5. パイロットを実施します。 本番のセッションの前に1～2回実施します。必要に応じてタスクを調整します。
6. 実施します。 プロトコルに従い、規律を保ちます。
7. 実施中に統合します。終了後だけにしないでください。 4回目または5回目のセッションまでにパターンが見えてきます。
8. 報告します。 書面のレポートとハイライト動画など、複数の形式を使います。
9. 修正を追跡します。 重大な問題には、必ず担当者と期日を設定します。
10. 修正後に再テストします。 修正が機能し、新たな問題を引き起こしていないことを確認します。

---

失敗パターン

• 特定のタスクではなく、製品全体をテストする。 結果が曖昧になります。
• 解決への道筋を示してしまうタスク。 （「メニューをクリックして探してください」など）
• 友人や家族を参加者にする。 偏りがあり、代表性がありません。
• リサーチャーが参加者を誘導する。 調査結果がリサーチャーの見解を反映します。
• 参加者が苦戦したときにデザインを擁護する。 実際の問題を見逃します。
• 早く手助けしすぎる。 参加者が操作上の摩擦を体験できません。
• 参加者の提案を機能要望として扱う。 ユーザーは問題を解決しようとし、解決策はプロダクトチームが設計します。
• 参加者1人の意見をデータとして扱う。 1人の強い意見は、調査結果ではありません。
• 深刻度の評価を省略する。 すべての調査結果が同等に扱われ、チームが優先順位を付けられません。
• 誰も読まないレポート。 80ページの資料よりも、ハイライト動画やライブでの説明が効果的です。
• 一度だけテストし、再テストしない。 新たな問題を引き起こす修正を見逃します。

---

出力形式

デフォルトの出力：

1. テスト計画（テスト前） - usability-test-plan-[topic].md
2. タスクスクリプト（各セッション用） - usability-tasks-[topic].md
3. 調査結果レポート（統合後） - usability-findings-[topic].md
4. ハイライトクリップ（別途作成）

---

必要なデータを入手できない場合

このスキルの出力は、このスキルだけでは生成できないデータ、測定値、またはツールの結果に依存します。必須の入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、正式に認められる出力は、不足している情報を明記した成果物です。必要だったもの、実際に取得または検証できたもの、および出力のどの部分が影響を受けるのかを記載してください。成果物を完成させるために必須の数値を捏造、推定、または補間することは認められません。不足を明記すれば、それで完全な回答となります。

---

参考ファイル

• references/task-script-patterns.md - 一般的な製品タイプ別のタスク設計パターン。良い例と悪い例を掲載しています。