ux-research-discovery-testing

UXリサーチによるディスカバリーテスト

目的

ユーザーの目標、観察された行動、ビジネス成果、検証可能な証拠を根拠として、エージェントがより適切なプロダクト、UX、UI、フロントエンドの提案を行えるようにします。このスキルを使って、必要十分なリサーチ手法を選び、インタビューやユーザビリティテストの計画を作成し、調査結果を統合し、機会を特定し、証拠に基づくプロダクトの意思決定を説明します。

これは、実際のプロダクトの制約下で実践的なリサーチを行うための運用マニュアルです。

このスキルを使う場面

ユーザーから次の依頼があった場合に、このスキルを使います。

• ディスカバリー、顧客インタビュー、現地訪問、コンテクスチュアル・インクワイアリー、ステークホルダーインタビューを計画する。
• ユーザー行動、タスクの達成度、アクセシビリティ、またはプロダクト成果が重要なUIをレビュー、批評、再設計、または作成する。
• インタビューガイド、スクリーナー、ユーザビリティテストの台本、リサーチ計画、統合フレームワーク、機会マップ、ジャーニーマップ、ペルソナ、タスクフロー、または証拠に基づく提案を作成する。
• 次に何を構築、改善、削除、またはテストするかを決める。
• プロトタイプ、実際のUI、デザインシステムのコンポーネント、オンボーディングフロー、フォーム、ナビゲーションモデル、ダッシュボード、空の状態、エラーフロー、またはコンテンツ階層を評価する。
• 定性的なメモ、アナリティクス、アンケート結果、サポートチケット、スクリーンショット、または観察内容をプロダクトの意思決定に結びつける。

このスキルを使わない場面

タスクが次のいずれかだけの場合は、このスキルを主要なツールとして使わないでください。

• ユーザーの目標、タスク、行動、またはプロダクトの意思決定に関係しない、UIのビジュアルスタイリング。
• 利用とは無関係な、ブランドアイデンティティ、イラスト、または美的表現の検討。
• 軽量なプロダクトリサーチの範囲を超えた、厳密なサンプリング、推測統計、または実験計画が必要な統計分析。
• 法務、医療、または規制対象の人を対象とする研究に関する助言。この場合は、適格な専門家によるレビューを勧め、一般的なUX計画のガイダンスのみを提供してください。
• ユーザーがすでにユーザーの課題、行動、アクセシビリティ要件、インタラクションデザインを指定しているプロダクション用フロントエンドのコーディング。

基本原則

1. 方法ではなく、意思決定から始めます。 調査が情報を提供すべきプロダクト、デザイン、またはフロントエンドに関する意思決定を特定します。その意思決定に関する不確実性を減らす調査活動だけを選びます。

2. ビジネス上の問いと調査上の問いを分けます。 「何を作るべきか」を、人々、タスク、動機、状況、制約、現在の回避策に関する、調査可能な問いに変換します。

3. 好みに関する主張より、行動と状況を重視します。 「気に入りましたか？」や「何を望んでいますか？」は、根拠として弱いものと捉えます。最近の具体的な体験談を尋ね、作業を観察し、タスクをテストし、実際の成果物を確認します。

4. 顧客価値とビジネス価値のバランスを取ります。 リリースする機能、経営幹部の好み、個別のユーザー要望だけを最適化の対象にしません。顧客価値を生み出し、ビジネスを支える行動の変化をもたらす成果を軸に取り組みを組み立てます。

5. 信頼できる範囲で、最小の調査サイクルを使います。 次の意思決定に影響を与えられる、軽量で反復的な調査を基本とします。調査は学習を加速させるためのものであり、形だけのものになってはいけません。

6. 前提を明確にします。 調査や批評の前に、ユーザー、状況、動機、制約、アクセシビリティのニーズ、ビジネス目標に関する前提を列挙します。リスクの高い前提は、検証可能な問いに変えます。

7. 複数の種類の証拠を活用します。 定性調査は理由や方法を明らかにし、定量的な証拠は何が、どこで、どのくらいの頻度で起きているのか、また変更が指標に影響したかを示します。あらゆる種類の問いに、単一の手法で答えようとしてはいけません。

8. 行動、役割、対比を考慮して参加者を募集します。 対象のタスクや状況に関する経験を持つ人々を募集します。制約や機会を明らかにできる場合は、関連する職種、非ユーザー、最近利用をやめた人、競合製品のロイヤルユーザー、極端なユーザー、影響を受けるステークホルダーも含めます。

9. 調査はチームで取り組むものです。 有用な場合は、プロダクト、デザイン、エンジニアリング、コンテンツ、アクセシビリティ、サポート、営業などの関係者を巻き込みます。ユーザーと直接接することは、長いレポートよりも説得力があります。

10. 統合した知見を見える形にします。 マップ、親和図、機会ツリー、タスクフロー、ジャーニーマップ、スクリーンショット、短い証拠メモを使って、共通認識を築きます。

11. 参加者を守ります。 目的、同意、録画、機密保持、謝礼、調査結果の利用方法を説明します。同意はNDAや謝礼とは分けて扱います。参加者の時間と福祉を尊重します。

12. 調査結果だけでなく、行動を提案します。 調査結果は、優先順位付けされた意思決定、リスク、次のテスト、プロダクトの変更につながるものでなければなりません。

各原則を再利用可能なカードとしてまとめたものについては、references/principle-cards.md を参照してください。

デフォルトの推奨事項

ユーザーからより具体的な背景情報が示されない限り、以下をデフォルトとして使用します。

領域	デフォルトの推奨事項	通常、これが最善である理由	変更する場合
調査の目標	手法を選ぶ前に、1つの意思決定と1つの主要な調査質問を定義します。	焦点の定まらない調査や、質問のしすぎを防げます。	ユーザーが幅広い製品分野を明示的に探索している場合。
探索手法	最近の実体験を軸とした、5～8件の半構造化インタビューまたは状況に即したセッションから始めます。	製品開発に十分な速さで進められ、行動、状況、言葉遣い、前提を明らかにするのに十分な情報が得られます。	安全性が極めて重要な場合、高度な規制対象である場合、または統計的な確度が必要な場合。
インタビューの頻度	継続的に製品を開発するチームでは、毎週顧客との接点を設けます。単発の調査では、次の意思決定に役立つ最小限の回数を実施します。	継続的に顧客と接することで、古くなった前提に頼るのを防げます。	チームが参加者にアクセスできない場合。その場合は、二次調査、サポートログ、分析データ、社内の専門家を活用し、確度が低くなることを明記します。
インタビューの進め方	ガイドを用意しつつ、柔軟に進めます。最近の出来事、具体例、資料、工夫、状況について尋ねます。	抽象的な意見より、具体的な経験のほうが有益です。	参加者間で比較可能な指標が必要な調査の場合。
ユーザビリティテスト	代表的な参加者、または学びの多い参加者に現実的なタスクを試してもらいます。タスクを歪めない場合に限り、考えながら声に出してもらいます。	タスクの実行状況から、意見よりも多くのユーザビリティ上の問題が明らかになります。	製品の利用状況により、考えながら声に出す方法が危険、非現実的、または過度な妨げとなる場合。
サンプルサイズ	少人数から始め、反復しながら参加者を募集し続けます。小規模なテストは問題の発見に使い、母集団における発生率の推定には使いません。	小規模な実施を重ねることで、影響の大きい問題をすばやく見つけられます。	ユーザーが発生率、セグメンテーション、または統計的な確度を必要としている場合。
参加者の条件	属性だけでなく、行動、タスク、状況、製品との関係に基づいて参加者を募集します。	属性だけでは、達成すべき仕事やメンタルモデルを十分に表せないことが多いためです。	属性がアクセス、安全性、ニーズ、文化、公平性に直接影響する場合。
統合と分析	複数のチームメンバーとともに、セッションの直後に分析します。観察した事実と解釈、推奨事項を分けます。	記憶の薄れやバイアス、レポートだけを渡す形の引き継ぎを減らせます。	機密保持やチーム構成の都合で、幅広い参加ができない場合。
機会の整理	調査結果を、成果、機会、解決策の候補、前提、テストに整理します。	チームが1つの発言からすぐに機能の実装へ飛びつくのを防げます。	ユーザーが簡潔なユーザビリティ上の不具合一覧だけを必要としている場合。
エビデンスの強さ	観察された行動、タスクの成功、分析データ、統制されたテストを、好みに関するアンケートより強いエビデンスとして扱います。	安易な信頼や自己申告バイアスを減らせます。	認知度、感情、ブランドイメージ、または明示された期待が調査の問いである場合。
報告	簡潔な意思決定メモを作成します。意思決定、エビデンス、確度、推奨する対応、代替案、リスク、次のテストを含めます。	ステークホルダーが必要としているのは、調査資料のアーカイブではなく、行動につながる情報です。	ユーザーが正式なレポートまたはコンプライアンス文書を求めている場合。
アクセシビリティ	最初から、アクセシビリティのニーズを調査の条件とテスト可能な要件に含めます。	アクセシビリティは、タスクの状況、操作の負担、実装の選択肢に影響するためです。	完全に省略することはありません。プロジェクトの範囲に応じて深さを調整します。

必須のユーザー質問

回答によって調査計画、批評、または推奨事項が大きく変わる場合に限り、質問します。まず推奨されるデフォルトを使用し、一般的なベストプラクティスについて定型的な質問はしません。

製品に関する意思決定が不明確な場合に尋ねる

question({
  question: "What decision should this research or UX critique help you make?",
  recommended_default: "Decide the next product/design change that best improves the user's primary task while supporting the business outcome.",
  options: [
    "Decide what problem or opportunity to pursue",
    "Decide which solution or concept to build",
    "Find usability issues in an existing UI/prototype",
    "Prioritize improvements for a shipped product",
    "Other / custom"
  ]
})

対象ユーザーまたは利用状況が不明確な場合に尋ねる

question({
  question: "Who is the primary user or participant group, and what real-world context should we design or test for?",
  recommended_default: "Recruit people who recently tried to complete the target task, plus one adjacent or contrasting group if it may reveal hidden constraints.",
  options: [
    "Current users performing the target task",
    "Prospective users or non-users",
    "Competitor users / recent switchers",
    "Internal users, operators, support, or admins",
    "Other / custom"
  ]
})

成功の成果が不明確な場合に尋ねる

question({
  question: "What user behavior or business outcome should improve if this work succeeds?",
  recommended_default: "Use one user behavior metric tied to a business outcome, such as task completion, activation, retention, conversion, reduced support contact, or successful self-service.",
  options: [
    "Task completion / fewer errors",
    "Activation or onboarding success",
    "Conversion or revenue action",
    "Retention or repeat use",
    "Support reduction or operational efficiency",
    "Other / custom"
  ]
})

参加者へのアクセス、または調査上の制約が不明確な場合に尋ねる

question({
  question: "What access do we have to users, artifacts, analytics, and the product/prototype?",
  recommended_default: "Use the best available evidence now, flag confidence, and propose the next smallest research loop.",
  options: [
    "Can interview or observe users directly",
    "Can run moderated or unmoderated usability tests",
    "Have analytics/support tickets/session recordings",
    "Only have stakeholder knowledge right now",
    "Other / custom"
  ]
})

アクセシビリティのニーズによって計画が変わる可能性がある場合は尋ねます

question({
  question: "Are there known accessibility needs, assistive technologies, language needs, or situational constraints that must be included?",
  recommended_default: "Plan for keyboard, screen reader, magnification, color contrast, reduced motion, cognitive load, mobile constraints, and diverse language proficiency unless the product scope clearly narrows this.",
  options: [
    "Known assistive technology users",
    "Known cognitive/language/access constraints",
    "No known data; include baseline accessibility coverage",
    "This is an accessibility-specific study",
    "Other / custom"
  ]
})

判断項目の全セットについては、references/decision-prompts.mdにある、質問ツールですぐに使えるプロンプトを使用してください。

ワークフロー

1. 依頼をトリアージする

次の項目を特定します。

• 製品または機能領域。
• 段階：探索、コンセプト、プロトタイプ、リリース済み UI、再設計、または継続的な最適化。
• 行うべき判断。
• 対象ユーザー、影響を受ける役割、コンテキスト。
• 既存のエビデンスと成果物。
• リスク：アクセシビリティ、プライバシー、安全性、信頼、ビジネスへの影響、技術的制約。
• 期限と調査へのアクセス。

不可欠な項目が欠けている場合は、焦点を絞った質問を一つ尋ねます。それ以外の場合は、前提を置いて進め、その前提を明示します。

2. 調査モードを選ぶ

判断内容に合った調査モードを使用します。

• 生成的／探索的： チームが適切な問題や機会をまだ把握していない場合に使用します。インタビュー、現地訪問、日記調査／ログ記録、ステークホルダーへのインタビュー、二次調査、サポートチケットのレビュー、競合の観察を行います。
• 記述的／説明的： 問題は存在するものの、ワークフロー、コンテキスト、ユーザーグループ、メンタルモデル、タスク、制約を理解する必要がある場合に使用します。
• 評価的： テスト対象となるコンセプト、プロトタイプ、UI、フロー、または競合の体験がある場合に使用します。タスクベースのユーザビリティテスト、ヒューリスティックレビュー、アクセシビリティレビュー、認知的ウォークスルー、プロトタイプテストを行います。
• 因果的／定量的： リリース済みの製品で測定可能な行動データがあり、変更が指標に影響するかを把握する必要がある場合に使用します。分析、A/B テスト、ファネル分析、タスク指標を用い、定性的な調査でその理由を明らかにします。

3. 判断内容と前提を明確にする

計画や提案を書く前に、次の項目を明示します。

1. ビジネス上の成果を示します。
2. その成果につながるユーザー行動を示します。
3. 対象ユーザー／コンテキストを示します。
4. 判明している事実を列挙します。
5. 前提を列挙します。
6. 最もリスクの高い前提を特定します。
7. そのリスクを軽減できる、最小限の手法を選びます。

4. 軽量な探索を計画する

探索やインタビューでは、次の項目を作成します。

• 調査目的。
• 調査の質問。
• 行動／コンテキストに基づく参加者の条件。
• リクルート方法とスクリーニング質問。
• インタビュー／セッションガイド。
• 同意取得と録画の計画。
• 役割：モデレーター、記録係、オブザーバー、リクルーター、分析担当者。
• スケジュールと統合計画。
• 判断の成果物：機会マップ、調査結果メモ、ジャーニー／タスクマップ、または提案。

5. インタビューまたはコンテキストセッションを実施する

モデレーションでは、次のルールを守ります。

• 同意、目的、所要時間、機密保持、録画、質問への回答を控える許可について、最初に説明します。
• 必要な範囲で雑談をして、信頼関係を築きます。
• 「最後に〜したときのことを教えてください」のように、最近の具体的な出来事について尋ねます。
• 次に進む前に、追加の質問をします。
• 質問した後と回答の後に、沈黙の時間を設けます。
• 参加者の言葉を使います。
• 成果物、ツール、環境、中断、回避策、きっかけ、人間関係、制約について尋ねます。
• 質問の中に答えを含めないようにします。
• セッション中にデザインを教えたり、修正したり、売り込んだり、擁護したりすることは避けます。
• 参加者からの質問やトラブルシューティングは、最後に行います。
• インターフェースの文言に役立つ場合は、参加者の正確な表現を記録します。

6. ユーザビリティテストを計画する

ユーザビリティテストでは、次の項目を作成します。

• テストの目的と製品に関する判断。
• テスト対象の成果物：スケッチ、プロトタイプ、実際の UI、競合のフロー、またはコンポーネント。
• 参加者と、その参加者から多くを学べる理由。
• 現実的な表現で記述した重要なタスク。
• 成功基準：完了、エラー、時間／労力、自信、理解度、アクセシビリティ、重大な摩擦。
• モデレーター用スクリプト。
• データ収集計画。
• 深刻度の評価基準。
• テスト後の結果の統合と次のアクション。

タスクの文言では、UI の操作手順ではなく、参加者の目標を説明します。特定のボタンを見つけること自体がテスト対象でない限り、参加者に特定のボタンを探すよう求めないでください。

7. エビデンスを統合する

統合の際は、次の手順に従います。

1. メモと録音を手早く確認します。
2. まず解釈ではなく、観察した内容を記録します。
3. 行動、引用、障害、動機、回避策、ツール、きっかけ、環境、関係性を分類します。
4. 何が起きたのか、その意味は何か、次に何をすべきかを区別します。
5. 調査結果を機会、前提、テスト候補に対応づけます。
6. 顧客への影響、事業への影響、頻度／確信度、リスク、アクセシビリティへの影響、実装工数に基づいて優先順位を付けます。
7. 確信度と、どのような情報があれば考えを改めるかを明示します。

役立つ場合は、次のような視覚的な成果物を活用します。アフィニティダイアグラム、ジャーニーマップ、タスクフロー、機会解決ツリー、スクリーンショットのフォレンジック分析、メンタルモデルマップ、ワークフローダイアグラム、重大度マトリクス。

8. 調査に基づく提案を行う

すべての提案に、次の内容を含めます。

• プロダクトに関する決定または変更。
• 根拠として用いたエビデンス。
• ユーザーの課題または機会。
• 期待される行動の変化。
• 事業価値。
• アクセシビリティとインクルージョンへの影響。
• フロントエンド／デザインシステムへの影響。
• トレードオフとリスク。
• 確信度。
• 次のテストまたは指標。

「ユーザーは X を望んでいると言っていました」ではなく、「エビデンスに基づくと、次に X を実行すべきです。なぜなら……」という表現を優先します。

意思決定フレームワーク

エビデンスの段階

確信度を伝えるために、次の段階を使います。

1. 状況下で観察された行動： フィールド訪問、コンテキスト調査、ユーザビリティテスト、サポート／セッションのエビデンス。
2. プロダクトの行動データ： アナリティクス、ファネル、検索ログ、タスクの成功率、A/B テスト。
3. 成果物と回避策： スクリーンショット、スプレッドシート、メモ、チケット、フォーム、実際に使われているツール。
4. 体系的な自己申告： 最近の行動に関するインタビュー、日記調査、適切に設計されたアンケート。
5. 根拠の弱い選好の主張： 好み、仮定の話、機能のリクエスト、一般的なアンケート回答。

根拠の弱いエビデンスも捨てず、適切に明示して、他のエビデンスと照合します。

手法の選択

• ユーザーがどのような人で、何をしているかを知りたい場合：インタビュー、観察、コンテキスト調査、ステークホルダー／サポートのレビュー。
• UI が機能するかどうかを知りたい場合：タスクベースのユーザビリティテスト、アクセシビリティレビュー、ヒューリスティック評価。
• リリース後に何が変わったかを知りたい場合：アナリティクス、ファネル、A/B テスト、サポート件数の変化、タスク指標。
• 指標が変化した理由を知りたい場合：アナリティクスを、インタビュー、セッションレビュー、ユーザビリティテスト、サポート分析と組み合わせます。
• 次に何を開発すべきかを知りたい場合：機会の発見、エクスペリエンスマップ、機会解決ツリー、前提のマッピング、コンセプトテスト。
• 優先順位の付け方を知りたい場合：解決策だけでなく機会を比較し、顧客への影響、事業成果、可逆性、リスク、工数を用います。

優先順位付けのルール

• 解決策より先に機会の優先順位を付けます。
• 可能な限り、初期のプロダクトに関する決定は変更可能なものとして扱います。
• アイデアを単独で評価するのではなく、機会や解決策の候補を複数まとめて比較します。
• 小規模なテストでリスクを減らせる場合は、アイデア全体ではなく前提を検証します。
• 影響の大きいユーザビリティとアクセシビリティの障害から着手します。
• 完璧なデータを待つ間、あらゆる対応を先送りにしないようにします。

実践的なルール

調査計画

• ガイドやテストスクリプトを作る前に、問題を一段落で記述します。
• 意思決定を支える手法だけを含めます。
• スクリプト、タスク、プロトタイプ、実施準備に不確実な点がある場合は、パイロットまたは事前パイロットから始めます。
• 既知の前提と潜在的なバイアスを記録します。
• データを収集する前に、統合の計画を立てます。

インタビューガイド

優れたガイドには、次の内容が含まれます。

1. 導入、同意、目的、所要時間。
2. タスクに関連する参加者の背景。
3. 調査の質問ごとに整理した主要な質問。
4. 最近の具体的な体験談と実演。
5. 成果物／環境についての掘り下げ。
6. 将来予測または理想の体験に関する任意の質問。探索的な内容であることを明確にします。
7. 締めくくり：聞き漏らしたトピック、参加者からの質問、謝礼／次のステップ。

ユーザビリティテストのスクリプト

よいスクリプトには、次の内容が含まれます。

1. 導入と同意。
2. テスト対象は参加者ではなくデザインであることの再確認。
3. シナリオの設定。
4. 現実的なタスク。
5. 成功基準とメモ欄。
6. 誘導的でない質問。
7. タスク後の自信度や期待に関する質問。
8. 締めくくり。

統合

• 可能であれば、グループで分析します。
• 観察結果と解釈を分けます。
• 元のメモまでたどれるようにしておきます。
• 繰り返し見られるパターンをインサイトにまとめます。
• インサイトを、プロダクトの機会、デザイン原則、検証可能な変更につなげます。
• 分析の早い段階で解決策を出すのは避けます。

レポート

簡潔なメモまたは注釈付きの成果物を基本とします。

• 概要。
• 主な発見。
• 根拠と確信度。
• 推奨する判断。
• 優先順位を付けた修正または機会。
• リスクとトレードオフ。
• 次の調査／テスト。
• 付録（有用な場合のみ）。

アクセシビリティとインクルージョンの要件

アクセシビリティは、最後に行うコンプライアンス確認ではなく、ユーザーの状況の一部として常に扱います。

• プロダクトが幅広く利用される場合は、関連する障害、支援技術、デバイス上の制約、言語のニーズ、状況による制約がある参加者を含めます。
• 実際に使用しているツールや設定について尋ねます。キーボード操作、スクリーンリーダー、拡大表示、音声入力、モーションの軽減、字幕、コントラスト、翻訳、モバイル端末の制約、認知負荷などが含まれます。
• UI の動作が関係する場合は、キーボードのみで重要なタスクをテストします。
• フォーカス順序、視認できるフォーカス状態、ラベル、ロール、エラーメッセージ、動的な更新、モーション軽減時の動作、タッチターゲットのサイズを確認します。
• リクルートが不便だからという理由で人々を除外する調査計画は避けます。
• 配慮の提供、アクセシブルなプロトタイプ、明確な同意、柔軟なセッション運営を用意します。
• 調査の根拠にアクセシビリティ面の網羅性が欠けている場合はその旨を示し、追加調査を提案します。

フロントエンド実装のガイダンス

推奨事項がフロントエンド開発に影響する場合は、実装上の影響も含めます。

• コントロール、ナビゲーション、見出し、フォーム、リスト、テーブル、ランドマークにはセマンティック HTML を使用します。
• カスタムコンポーネントが必要な場合を除き、ネイティブの動作を維持します。
• キーボード操作、フォーカス管理、必要な場合に限った ARIA の使用、動的な状態に対するスクリーンリーダーへの通知を明記します。
• 空、読み込み中、エラー、オフライン、成功、権限、データの一部のみがある状態を設計し、テストします。
• 推奨事項を、デザイントークン、コンポーネント API、レスポンシブブレークポイント、既存のデザインシステムのパターンに合わせます。
• 対象の動作を把握するための分析機能やイベント計測を追加します。ただし、判断に役立つ指標がない場合は計測しません。
• 特にタスクの成功や信頼感の認知に関わる UX の変数として、パフォーマンスと遅延を考慮します。
• ラベル、補足テキスト、エラー文、確認メッセージ、段階的な情報開示など、コンテンツ上の要件を含めます。
• 再利用可能なコンポーネントやパターンが適切な場合は、壊れやすい一度限りの UI を必要とする推奨事項を避けます。

評価ワークフロー

既存の UI、プロトタイプ、またはフロントエンド実装をレビューする場合は、次の順序で確認します。

1. ユーザーの目標とプロダクトの成果： どのようなタスクを支援するもので、どのような行動の変化を目指していますか？
2. コンテキストと対象ユーザーとの適合性： 誰が、どこで、どのような制約のもと、どの程度の事前知識を持って利用しますか？
3. エビデンス： 調査、分析、サポート、関係者の知見、または観察された行動から何がわかっていますか？
4. タスクフロー： ユーザーは開始し、進行し、問題から回復し、完了できますか？
5. 情報の階層： 最も重要な判断、コンテンツ、アクションが明確ですか？
6. インタラクションの明確さ： コントロール、状態、入力検証、ナビゲーション、フィードバックはわかりやすいですか？
7. アクセシビリティとインクルージョン： ユーザーは、入力方法、支援技術、言語ニーズ、認知負荷にかかわらず、操作して理解できますか？
8. コンテンツと用語： UI では、ユーザーが置かれた状況で理解できる言葉を使っていますか？
9. 利用を支えるビジュアルデザイン： 余白、コントラスト、グループ化、タイポグラフィ、強調はタスクの理解に役立っていますか？
10. フロントエンドの実現可能性： セマンティックでレスポンシブ、パフォーマンスに優れ、デザインシステムに準拠したコンポーネントを使って、保守しやすく構築できますか？
11. リスクと次のテスト： どのようなエビデンスが不足していますか？リスクを検証できる、最小限で信頼性の高いテストは何ですか？

作成ワークフロー

調査計画、UX の推奨事項、またはデザイン改善案を作成する場合は、次の手順に従います。

1. 判断すべきことと望ましい成果を明確にします。
2. ユーザー、利用状況、制約を特定します。
3. 前提と不明点を列挙します。
4. リスクを低減できる、最小限の調査またはテスト方法を選びます。
5. ガイド、スクリプト、タスクリスト、または分析の構成を作成します。
6. 参加者の募集、同意、役割、実施上の手配を含めます。
7. 収集するエビデンスと成功基準を定義します。
8. アクセシビリティの対象範囲を含めます。
9. 統合分析と報告の計画を立てます。
10. 次のアクションと、影響の測定方法を提案します。

品質チェックリスト

最終版を仕上げる前に、次の点を確認します。

• プロダクトまたはデザインに関する判断が明示されています。
• 調査の問いに答えられるようになっています。
• 手法が判断の内容に合っています。
• 参加者の条件が、行動や利用状況に基づいています。
• 質問が中立的で、実際の経験に基づいています。
• ユーザビリティのタスクが現実的で、手順を一つずつ指示するものではありません。
• 同意、録画、プライバシー、謝礼、アクセシビリティ上の配慮に対応しています。
• 統合分析で、観察事項、解釈、推奨事項を区別しています。
• 推奨事項が、影響、確信度、リスク、労力に基づいて優先順位付けされています。
• ビジネス価値とユーザー価値の両方が反映されています。
• フロントエンドへの影響が実践的で、アクセシビリティに配慮されています。
• 限界と確信度が明示されています。

references/checklists.md のチェックリスト全体を使用してください。

よくある避けるべき間違い

• ユーザーに何が欲しいかを尋ね、その回答をロードマップとして扱う。
• デザインが気に入ったかどうかをユーザーに尋ねる。
• 判断や機会ではなく、機能のアイデアから始める。
• 既定の結論を正当化するために調査を行う。
• 募集しやすい社内の参加者だけを集める。
• 人口統計と行動を混同する。
• 現実的なタスクを用意せずにユーザビリティテストを実施する。
• テスト中に参加者を手助けする。
• 判断に影響を与えるには遅すぎる、長いレポートを作成する。
• 分析結果を自明なものとして扱う。
• インタビューを統計的に代表性のあるものとして扱う。
• より大きな機会を無視して、現在の UI を局所最適化する。
• デザインや実装の後までアクセシビリティへの配慮を後回しにする。

アンチパターンの一覧は references/anti-patterns.md を参照してください。

• 安全な既定値が利用できるのに、ユーザーに過剰なコンテキストの提示を求める。

推奨事項をユーザーに説明する方法

次の構成を使用します。

1. 推奨事項： アクションを明確に述べます。
2. 理由： ユーザーの行動とビジネス上の成果を結び付けます。
3. 根拠： 情報源と確信度を示します。
4. トレードオフ： 得られるものと残るリスクを説明します。
5. 次のステップ： 最小限のテスト、実装ステップ、または指標を提案します。

例：

チェックアウト全体を再設計する前に、チェックアウトのエラーフローをテストすることをおすすめします。考えられる主なリスクは、見た目の洗練度ではなく、タスクの復旧です。ユーザーは、何が失敗したのか、どうすれば修正できるのか、支払いが処理されたかどうかを理解する必要があります。まず、現在のフローでタスクベースのセッションを5件実施し、上位2つの修正案をプロトタイプ化してください。リリース後は、完了率、エラーからの復旧率、サポートへの問い合わせ件数を測定します。