私は小規模なチームのスタートアップに取り組んでいます。私たちは、主要なユーザーフローのプロトタイプを作成しました。これを実際の顧客でテストし、最大の洞察を得て繰り返します。
私の質問:(製品またはタスクについて)ユーザーにどの程度のコンテキスト/紹介を与える必要がありますか?
私はライブユーザビリティテストを一度も行ったことがなく、彼らを導いたくありませんが、彼らが達成しようとしていることを知るのに十分なことを確認し、そこから生じる設計の問題を評価したいと思っています。
この状況でユーザーが提供する必要がある唯一のコンテキストは、ユーザーが到達するコンテキストです。それ以外のものは結果を混乱させます。多くの場合、テスターが適切にスクリーニングされれば、説明はまったく必要ありません。
糖尿病患者に新しい検査メカニズムを提供しているクライアントがいて、Type-IとType-IIの糖尿病患者のグループを画面に座って、ランディングページと行動を促すフレーズを確実に理解してもらう場合は、コンテキストを与える必要はありません。彼らがボートに乗り遅れると、あなたは間違いを犯したことになります。
一方、大学のWebサイトで作業していて、秋学期に追加された、以前には提供されなかった新しいクラスを学生が見つけられるようにしたい場合は、それらを提供する必要があります。コンテキストのビット。テスターとして学校に大学生がいますが、それは良いことですが、適切なコンテキストの量はどれくらいですか。
これは、いくつかのタイプのユーザーテストが行うように設計されているものです。あなたは文字通りテスターにタスクを与えます:
「専攻に新しく追加されたコースを見つけて、そのうちの1つに登録する」(コンテキストが組み込まれました)
注:適切にスクリーニングされたため、サイトの内容を彼らに伝える必要はありませんでした。特により複雑なサイトでは、私が彼らに何をしてもらいたいかを彼らに伝える必要があるかもしれません。
ただし、原則として、結果を汚染してタイプ1またはタイプ2のエラーが発生するのを避けるために、説明はできるだけ簡潔にしたいと思います。
思考を大声で試してみる場合、必要なのは最小限のコンテキストだけです。これは、ユーザーの応答にバイアスをかける可能性を減らすためです。理想的には、標準のユーザビリティテストの免責事項(システムではなくシステムをテストしています。応答は機密情報であるなど)と、達成したいタスクについて少しだけ提供します。 Xを達成するために。」
これを行うことで、システムがどれほど使いやすいかを実際に確認できます。オフコースを実際に乗り越えているユーザーに説明とプロンプトを提供する必要があるかもしれませんが、これは最小限に抑える必要があります。