ユーザーテストでできるだけ早くタスクを完了するようにユーザーに依頼する必要がありますか？
3〜4ページのフォームに記入する保険の自動見積もりプロセスを評価する必要があります。 2つのバリエーションを持つプロトタイプを設計しましたが、どちらが使いやすいかをテストしたいと思います。したがって、私は標準的なユーザーテストを音声で行うプロトコルで行い、1つのバリエーションで10人のユーザーをテストし、他のバリエーションで10人のユーザーをテストすることを計画しています。
問題は最も有効で価値のあるデータを取得するために、できる限り早くタスクを完了するように依頼するか、しないかですです。
タスクの完了時間などの統計をマネージャーに提示できるように、データを定量化する必要があります。
彼らにできるだけ早く記入するように指示すると、貴重な洞察の共有を省略してしまう可能性があると私は考えています。
あなたの経験では、長所と短所は何ですか？
前もって感謝します。
編集：
問題は、統計を追跡してA/Bテストを実行できる実際のシステムがないことです。それは利用できません。私たちは、さまざまなルールが適用されるさまざまな国で実装される保険ソフトウェアを構築しているため、フォーム入力プロセスの抽象的な発見を引き出す必要があります。したがって、保険フォームの記入プロセス全体として、抽象的な結果が必要です。
私はノーだと思います。あなたは彼らが彼らの行動に沿って彼らの行動の背後にある推論を発声するように彼らに頼んでいます（発声プロトコルを考えてください）-彼らは物事をスピードアップする1つの方法は逆効果である多くを言わないことを決定するかもしれません。
私はまた、定性的な観測手法と定量的な測定を混合しようとすることにも注意を払います。遅いユーザーは、より多くのことを観察し、Think-Aloudテストでより多くのことを伝えているだけかもしれません。管理者がチャートの数値を必要とする場合、行われた間違いの数および/または収集された観察の数に関するデータを収集します。別のテストのために速度測定値を保存します。
いいえ、できるだけ早くタスクを完了するようにユーザーに依頼するべきではありません。
ユーザーテストは、効率を正確に読み取るには、あまりにも人工的な設定です。また、比較のために統計的に有意なデータを取得するのに十分なテスターを確保することも困難です。
実際のシステムでメトリックを追跡することで、完了までの時間をより適切に分析できます。 2つのレイアウトについて、システムのA/Bテストを設定する必要があります。
他の人が述べたように、できるだけ早くタスクを実行するようにユーザーに要求しないことが最善です。いくつかの理由があります。1つは既に述べたとおりですが、ユーザーが声を出して話している間、より多くの時間を共有するほど、タスクを完了するのに時間がかかります。ユーザビリティテストを行って声を出して話すことは、参加者にとって自然なことではなく、人々が自分のコンテキストでタスクを実行する場合と比較して、より多くの認知リソースを必要とします。ラボ環境で話していると、時間がかかり、間違いが増える可能性があります。
使いやすさを評価し、より直感的なデザインを理解することが目標である場合、音声によるプロトコルが理由を理解するのに役立ちます。使いやすさと使いやすさは、時間のかかる作業をはるかに超えていますが、マネージャがそれらを同義的に考える可能性があります。一方、あなたの目標が定量的なデータを取得することである場合、A/Bテストがより良いアプローチかもしれません。その場合、10人は統計的に有意ではありません。
定量的研究と定性的研究を分離しますが、1つの研究で両方のタイプのデータを取得する必要がある場合は、参加者が通常行うようにタスクを実行するという情熱的なタスクから始めて、その後think-aloudでフォローアップすることはできません悪い考えになります。情熱的な課題については、できるだけ早く進むように求めるのではなく、すばやく行動する必要があるシナリオ/状況で自分自身を想像するように求めることをお勧めします。
他の人が言ったように、ユーザビリティテストのために特定の方向にユーザーに影響を与えようとするべきではありません。これを見てください テストスクリプト 、私は、ユーザビリティテストのフレーミングやユーザーに大声で考えるように指示するなどの点で、非常に役立つことがわかりました。
ユーザビリティテストの分析/データに関しては、 Canvas Flip を使用してみることができます。これまで使用したことがありませんが、面白そうです！
テストから何を取得したいかについて、計画と思考に多くの時間を費やす必要があります。ユーザビリティテストを実行するときは、定量的または定性的なデータを収集する必要があります。
経験則として、時間に関しては、一般的なユーザビリティテストは3つのフェーズに分類できます。
計画-時間の45％
テストの実行-時間の10％
結果の評価/レポートの作成-時間の45％
したがって、時間を評価する場合は、ビジネスニーズのためにユーザーが目標をすばやく達成できることが重要であるため、タスクをできるだけ早く完了するように依頼することは許容されます。あなたはスピードと正確さに気づくでしょう。ただし、これはユーザビリティテストの1つの側面にすぎません。あなたが探している他のものを追加するかもしれません、例えば。特に彼らが考えていることについて声を出して話すように人々に求めている場合、彼らは彼らがちょうど完了したタスクについてどのように感じ、そしてあなたはテスト中に起こる他のことに気付くかもしれません。
これが、計画フェーズが非常に重要な理由です。
ユーザーに指示することは絶対にないと思います、彼の流れに任せて、その過程でUXデザイナーが彼を観察する必要があるので、各ユーザーはあなたにとって重要なペルソナになる可能性があります。調査に基づいて、フォームに取り組み、ユーザーとのセッションを中断している間に観察した問題点を減らします。
時間の制限について話す場合は、ベンチマークのユーザビリティテストをご覧ください。
価値のある洞察を提供したい場合は、ユーザーに話してもらい、見ているもの、何をしているのか説明してもらいます。
それでもユーザーに「できるだけ早く」タスクを完了させたい場合は、次のようなシナリオを提示します。地下鉄に乗るのに1分かかりますが、エスカレーターを下りている間は、「タスクを完了してください」 "そして、地下鉄に乗ります。