形成的ユーザビリティテスト-スクリプト
最初の実際のユーザビリティテストを実行しています。私はこれを、最終的にSasSとして提供される内部のエンタープライズアプリケーションのために行っています。
文字通り全米のユーザーの100％を占める小さなユーザーグループを募集しました。 （非常にニッチな業界向けの国際的な製品になります。）
私はタスク分析を行っており、状況観察の機会が複数ありました。
私は、現在のシステムを分析し、現在のユーザーにインタビューし、分析とビジネスデータを確認して、ユーザーとビジネスのニーズをよりよく理解しました。
中程度の忠実度のセミインタラクティブプロトタイプを作成して、初期の形成可能なユーザビリティテストを実行しました。
私の質問です。スクリプトはどれほど重要ですか。
タスクの小さなスクリプトを作成しました。つまり）
1)Login, search for Customer "X" by Name.
2)Identify customer's mailing address.
3)Find navigation instruction to customer's address.
これらのタスクは、ユーザーが行う日常のタスクの真の表現に基づいていますが、私が理解しているのは、ユーザビリティテストは、スクリプト化されたバージョンをはるかに踏襲しているということです。
それがユーザーの日常のワークフローの真の表現である場合、タスクベースのスクリプトを実行することに何か問題がありますか？
「あなたはXXXXで働いており、顧客は電話をかけています。この顧客をシステムで見つける必要があります。」のようなことを本当に言う必要がありますか？または、ユーザーに非常に小さな特定のタスクを与えることはできますか？.
これは初めてなので不快に感じるからです。私はむしろ彼らに簡単な仕事と分析を与えたいと思います。しかし同時に、これにより結果が歪む場合は、適切な時間をかけてスクリプトを作成します。
どう思いますか？あなたの経験はどうですか。
以下は、質問のさまざまな部分に対するいくつかの回答と、いくつかのヒントです。
あなたが尋ねる方法はしばしば誤解を招く、または偏見を生み出す可能性があるため、台本は重要です。そのため、パイロットテストを実行し、結果を確認して、必要に応じてスクリプトを調整することをお勧めします。
この種のテストのスクリプトは、あなたが言及した内容をコンテキスト化することから開始する必要があります。「お客様はXXXX、顧客の電話で作業しています...」ユーザーを実際のシナリオにできるだけ近いコンテキスト化し、何も想定しないでください。 。
タスクベースのスクリプトは問題ありませんが、タスクを実行しているときに他の人に声を出して考えるように依頼する必要があります。 「Do task XXXX」などのタスクに関連する質問をフォローアップします。何か難しいことや不明確なことはありましたか？なぜ？'
- ユーザーテストスクリプトは、テストをモデレートするかモデレートしないか（つまり、ユーザー参加者と一緒に住んでいるかどうか）によって異なります。モデレートについては、スクリプトを緩くして、たくさんの 自由回答 フォローアップの質問をするのが良いでしょう。モデレートされていない場合、同じ規則のほとんどが適用されますが、質問の言い回しにさらに注意が必要です。
投稿したスクリプトに基づいた洗練されたスクリプトは次のとおりです。
Imagine you are working for XXXX, a customer phones in. You need to locate this customer in the system. THINK OUT LOUD what you see, how you feel, and what catches your eye or interest as you go through each of the tasks below.
1)Try logging in and searching for Customer "X" by Name. Anything unclear, unexpected or difficult? Why?
2)Identify customer's mailing address. Think out loud as you try to do this.
3)Find navigation instruction to customer's address.
この詳細については、- 私がここに書いた記事 を参照してください。
Junuの回答にさらにいくつかのポイントを追加します。
スクリプトは重要です。あなたが初めてそれをやっていて、私たちの誰もがテストのすべてのステップを覚えている超人ではないからです。詳細なスクリプトを用意して、参照用に印刷します。
タスクとは別に、セッションの記録に同意を求めるなどのいくつかのことから始める必要があります（記録する場合は、記録する必要があります）。記録は設計チームの外部で共有されないことをユーザーに明確に伝えます。単にメモを取る目的で。タスクが完了したら、主観的な質問をいくつかし、時間を割いて感謝の気持ちを伝え、今後同様のセッションを楽しみにしていることを伝えます。