usability-testing

ユーザビリティテスト

対象範囲

対象

• 特定のプロダクト上の意思決定に結び付いた、タスクベースのユーザビリティ調査を設計する
• 実際のフロー、プロトタイプ、「見せかけの」実装（フェイクドア、Wizard of Oz）をテストする
• モデレーター付きセッション（リモートまたは対面）を実施し、質の高いエビデンスを収集する
• 調査結果を優先順位付けした修正リストにまとめる（ROI の高いマイクロコピー／CTA の改善を含む）

使用する場面

• 「 のユーザビリティテスト計画とスクリプトを作成してください。」
• 「来週、5〜8 人のユーザーでプロトタイプをテストする必要があります。」
• 「構築前に価値提案を検証してください（フェイクドア／Wizard of Oz）。」
• 「ユーザビリティ調査の結果を、優先順位付けしたバックログにまとめるのを手伝ってください。」

使用しない場面

• 統計的に信頼できる推定値や因果関係の影響が必要な場合（アナリティクス／実験を使用してください）
• オープンエンドな探索が必要な場合（「ユーザーはどんな課題を抱えているか？」）→ conducting-user-interviews を使用してください
• 適切な承認／トレーニングなしで、リスクの高い集団や機微なトピック（医療、法律、未成年者）を扱う場合
• 評価する具体的なシナリオ／フローがない場合（まず意思決定を明確にしてください）

入力

最低限必要な情報

• プロダクトと対象ユーザーセグメント（対象者、利用状況）
• このテストで判断する事項（何を変更するか）とスケジュール
• テスト対象（フロー／機能）とプロトタイプ／ビルドへのリンク（または「刺激物を提案」）
• プラットフォームと環境（Web／モバイル／デスクトップ、リモート／対面）
• 制約：セッションの種類、参加者数、謝礼、録画ポリシー、プライバシー上の制約

不足情報への対応方針

• references/INTAKE.md から最大 5 つの質問をします。
• それでも不明な場合は、明示的な前提を置いて進め、計画を変更する可能性のある未解決の質問を列挙します。

出力（成果物）

Markdown 形式のユーザビリティテストパックを作成します（チャット内、または依頼された場合はファイルとして作成します）。

1. コンテキストの概要（意思決定、ユーザー、テスト対象、制約）
2. テスト計画（手法、プロトタイプ戦略、仮説／リスク、成功基準）
3. 参加者計画（条件、募集チャネル、スケジュールと予備候補）
4. モデレーターガイド＋タスクスクリプト（中立的なタスク、掘り下げる質問、まとめ）
5. 記録用テンプレート＋課題ログ（深刻度／影響、エビデンス）
6. 統合結果レポート（調査結果、優先順位付けした課題、推奨事項、すぐに実施できる改善）
7. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md
拡張ヒューリスティック：references/WORKFLOW.md

ワークフロー（8 ステップ）

1) 意思決定と「今行う理由」を明確にする

• 入力： ユーザーのコンテキスト、references/INTAKE.md。
• アクション： 意思決定、主な未確定事項、判断を下すために最低限知るべきことを定義します。
• 出力： コンテキストの概要＋調査の質問／仮説。
• 確認事項： 「このテストの後、何を変えるか？」に答えられること。

2) 適切な刺激物を選ぶ（実物 vs プロトタイプ vs 見せかけ）

• 入力： テスト対象、制約。
• アクション： 実際のプロダクト、クリック可能なプロトタイプ、フェイクドア、Wizard of Oz、またはコンシェルジュ型のフローから、妥当性を保てる最も低コストな設定を選びます。
• 出力： プロトタイプ戦略＋実際のものとシミュレーションするもの。
• 確認事項： 設定によって中核的な価値／行動をテストできること（ピクセル単位の完璧さを目指さない）。

3) タスクと成功基準を定義する（中立性を保つ）

• 入力： ユーザーの目標＋シナリオ。
• アクション： 開始状態、成功基準、主な観察項目（ためらい、エラー、回避策）を含む、現実的なタスクを 5〜8 個作成します。
• 出力： タスクリスト（ドラフト）＋観察計画。
• 確認事項： タスクが UI のラベルを明かしていないこと（「X ボタンをクリックしてください」など）。実際の意図を反映していること。

4) 参加者と募集計画を決める（予備枠を含める）

• 入力： 対象セグメント、ユーザーへのアクセス手段。
• アクション： 参加条件と除外条件を設定します。募集チャネルを選び、欠席者や多忙な参加者に備えた予備枠と余裕を含めてスケジュールを作成します。
• 出力： 参加者計画と募集文／スクリーナー（必要に応じて）。
• 確認事項： 参加者が、単に人口統計上の属性だけでなく、シナリオに合った行動や状況を備えていることを確認します。

5) モデレーターガイドと計測手段を準備する

• 入力： タスクリストとプロトタイプ。
• アクション： 台本（導入／同意、ウォームアップ、タスク、掘り下げ質問、締めくくり）を作成します。記録担当者の役割を割り当て、何を記録するかを決めます。
• 出力： モデレーターガイド、ノートテンプレート、課題ログ。
• 確認事項： ガイドに誘導的な質問がなく、「次に何をしますか？」と尋ねる掘り下げ質問が含まれていることを確認します。

6) セッションを実施して証拠を記録する（任意の「実態確認」）

• 入力： ガイド、実施環境、参加者。
• アクション： セッションを実施し、発言の逐語記録、エラー、タスクにかかったおおよその時間、混乱した場面を記録します。必要に応じて、実環境で同等のフローを観察します。
• 出力： セッションごとの完成したノートと、記入済みの課題ログ。
• 確認事項： すべての課題に、具体例（引用／スクリーンショット／時間／手順）を少なくとも1つ添付します。

7) 調査結果を優先度付きの修正案にまとめる（小さな改善も重要です）

• 入力： ノートと課題ログ。
• アクション： 課題をグループ化し、深刻度と頻度を付与して、ファネルやビジネスへの影響と結び付けます。修正案（マイクロコピーや CTA の調整を含む）を提案します。
• 出力： 調査結果の報告資料と、優先度付きの推奨事項／バックログ。
• 確認事項： 各推奨事項が証拠に基づき、期待される影響（方向性）が示されていることを確認します。

8) 共有し、意思決定を行い、品質ゲートを実施する

• 入力： ドラフト一式。
• アクション： 共有可能な報告資料を作成し、次のステップ（デザインの改良、追加テスト、実験）を提案します。references/CHECKLISTS.md を実施し、references/RUBRIC.md に基づいて評価します。
• 出力： 最終版のユーザビリティテストパックと、リスク／未解決の質問／次のステップ。
• 確認事項： ステークホルダーが非同期で「リリース／修正／再テスト」の判断を下せることを確認します。

品質ゲート（必須）

• references/CHECKLISTS.md と references/RUBRIC.md を使用します。
• 必ず リスク、未解決の質問、次のステップ を含めます。

例

例 1（プロトタイプのテスト）： 「来週、初回利用者6名を対象に、新しいオンボーディングフロー（ウェブ）を評価するためのユーザビリティテスト計画とモデレーターガイドを作成してください。」
期待される内容：中立的なタスク、参加者の募集条件、セッションの実施計画、調査結果をまとめるための構成を含む、完全なユーザビリティテストパック。

例 2（Wizard of Oz）： 「『AI 自動トリアージ』機能を、構築前にテストしたいと考えています。5回のセッション向けに、Wizard of Oz 形式のユーザビリティテスト計画と台本を設計してください。」
期待される内容：何をシミュレーションするかを定めた刺激計画、価値に焦点を当てたタスク、課題ログ、報告資料。

境界例： 「リデザインによって継続率が10％向上することを証明するために、ユーザビリティテストを実施してください。」
回答：小規模サンプルのユーザビリティ調査でできることの限界を説明し、因果関係の検証には計測や実験を組み合わせるよう提案します。また、ユーザビリティ調査は摩擦の原因を診断するために活用します。