参加者にユーザビリティテストをどのように紹介すればよいですか？
私はここ数年、さまざまな製品やインターフェースのユーザビリティテストを実施しています。これらは、対面型でリモートであり、忠実度が高く、忠実度が低く、構造化されたものと構造化されていないものがあります。私は、個人的な使用や同僚と共有するための一般的なベストプラクティスの参加者紹介スクリプトに取り組んでいます。
不足しているものはありますか？何か問題があるのか、それともそれほど良くないのですか？参照すべき確立されたベストプラクティスはありますか？
一般的なユーザビリティ調査の紹介：
- お時間を割いていただきありがとうございます。
今日は、新しい体験のプロトタイプを見せ、フィードバックを求めます
- これをユーザビリティ調査と呼びます
- このプロトタイプはまだ構築されていないラフなモックアップです
- これを表示する理由は、チームが実際のバージョンを構築する前にフィードバックを得るためです
- 実際にはどのバックエンドシステムにも接続されておらず、その一部は完全には機能していません
- 何かを壊す心配はありません
- ガイド付きテストの場合：プロトタイプを使用するときにロールプレイするいくつかのタスクを提供します
プロトタイプを使用する際は大声で考えてください
- 思考プロセスについて話す
- 自宅で使用するのと同じようにプロトタイプを使用するか、他の使い慣れた設定
- あなたが好きなものを指摘してください
- 間違いなく気に入らない点を指摘し、問題点をお知らせください
- 専門家の場合：また、改善や機能不足について考えているかどうかをお知らせください
- 物事を行うための正しい方法や間違った方法はありません、やりたいようにできるはずだと思うことを実行してください
- 行き詰まったと感じた場合は、私に知らせてください。そうすれば、どのように進められると期待できるかについてお話しします
- テスターがプロトタイプを設計しなかった場合：私はテストを実施している人なので、自由にあなたの心を話してください
- 私たちは決してあなたをテストしていません;これはすべてプロトタイプと何が機能し何が機能しないかについてです
質問をすると、なんらかの形で「どうすればいいと思いますか？」
- また、さまざまな段階であなたが考えていることをあなたに尋ねるかもしれません
- これは少し迷惑になるかもしれませんので、前もって謝罪します:)
- 私たちの目標は、あなたが物事についてどう考えているかを見ることです
- 途中で立ち止まったり、休憩したい場合はお知らせください
- 始めても大丈夫ですか？
あなたのスクリプトは素晴らしいスタートを切っています。 Joe DumasとBeth Loringによる モデレートユーザビリティテスト の プレテストブリーフィングのチェックリスト （図5.7）を参照します。
さらに、ここにいくつかのベストプラクティスがあります：
- マークが示唆するように、単語「テスト」の使用には注意が必要です。これは参加者のテストではないことを明確にしているので、「私たちは決してあなたをテストするわけではありません。これはすべてプロトタイプと何が機能し何が機能しないかについてです」といいます。参加者についても数回繰り返します。
- 声を出して考える方法を示します。 XMattersの記事 で、Mike Hughesは、参加者に家の窓を数えるよう提案しています。次に、参加者に「ウィンドウの数にはあまり興味がありませんが、このタスクをどのように実行するのか興味があります。」と伝えます。同様に、 モデレートユーザビリティテスト では、Joe DumasとBeth Loringは、ホッチキスの操作方法をユーザーに説明するよう提案しています。
- 視覚的なデザインの提案を求めないでください。あなたは問題を特定しようとしていますが、参加者から視覚的なデザインの推奨を得ることはありません。
- 参加者に、あなたが彼または彼女のフィードバックに興味があることを伝えます。
- ユーザーがタスクを実行する方法を明確にします。彼らはそれぞれを大声で読み、家で（または実際の環境で）行っているかのようにそれらを完成させようとする必要があることを説明します。また、参加者は、各タスクを完了した、または可能な限り行ったと思ったときに通知する必要があることに注意してください。
注：信頼関係の確立と指示の提供にどれだけの時間を費やす必要があるかについては、現場で議論があります。 Rolf Molichは、UPA 2011で「泡立ち率とユーザビリティテスト評価からのその他の観察」と題した講演を行いました。彼は、実務家がチャットや物事の説明に衝撃的な時間を費やしていることを発見しました。
「彼らが何を考えているかを知らせる」ように依頼する代わりに、「プロトタイプを使用するときは大声で考えてください」と表現する方が役立つ場合があります。私が言及するもう1つのことは、「私はテストを実施している人なので、自由にあなたの心を話してください」ということです。たぶん、あなたがただ観察しているだけであることを彼らに知らせることは役に立つでしょう。
私が常に言及している別のステートメントは、「最終目標を達成するための正しいアプローチや正しい方法はないと考えてはいけません。タスクにアプローチするすべての方法と、それがユーザーがこのアプリケーションをどのように使用するかを示します。タスクを実行する方法が複数ある場合は、特定のアプローチについて何が好きか、嫌いかをお知らせください。」
このステートメントの利点は、好きな方法でタスクを実行する自由があり、各アプローチの問題について質問することで、アクションボタンの配置やリンクの複製などの詳細を把握できることです。ヘッダーとフッター）
ここにあるものが好きです。これは、以前使用したものと非常によく似ています。私の唯一の提案は、「ユーザビリティテスト」というフレーズでさえ、可能な限り「テスト」という言葉を使用しないことです。それは（私の経験では）すぐに人々にSATを履行していると思い込ませ、彼らが失敗するつもりであり、失敗した場合は残りの人生の間マクドナルドで働かなければならないことをトリガーする言葉です。
さて、多分それは少し過大すぎるかもしれませんが、私は多くの人々がユーザビリティテストの参加者であることについて非常に神経質になるのを見てきました。したがって、私はWordテスト（絶対に「これはテストではない」と明示的に言うことを除く）を絶対に言わないように最善を尽くし、代わりに「ユーザビリティスタディ」と言います。
ささいなことですが、神経質な参加者は悲惨な研究をします！
テストの最初に補償料を支払うことは、ユーザーがお金を得るために聞きたいと思うものに向けて取り組む義務を感じないようにするのに役立つことがわかりました。
私たちは常に、補償は現れることだけのためのものであり、テストされるのは彼らではないことを強調します。