どのようにしてユーザーに声を出して考えさせますか？
ユーザーテストをモデレートするとき、ユーザーに思考プロセスを言葉で説明すること、声を出して考えることは難しい場合があります。
ユーザーは、他のことについての実行中のコメントを私に与えるのが非常に得意です-色が好きかどうか、他のユーザーが苦労するかもしれないと思うもの、またはラベルをどのように言い換えるかなど。彼らは、紫がいかに嫌いであるか、または青緑がアプリをどのように「教育的」に見せるかについて叙情的にワックスをかけ、一般にセッション全体を「意見収集」プロセスとして扱います。しかし、実際にはそうではありません声に出して考えてください。
そう。ユーザーテストでthink-aududプロセスを説明するにはどうすればよいですか？
ゴム製のアヒルを使用します。
ユーザーの近くに小さなゴム製のアヒルを置きます。ゴム製のアヒルの名前をユーザーに伝えます-フィット感が低いほど良いです。鉱山はフランク・ザ・ダックと呼ばれています。
ほら、フランク・ザ・ダックは少しばかげています。 Frankにはシステムの使い方がわからないので、教える必要があります。ただし、問題は、私は技術者なので、日常的に英語で説明する必要があることを説明するのが本当に下手だということです。
だから、今、ユーザーは私と一緒に行う少し滑稽な使命を持っています。私はユーザーに権力の地位を与え、彼に誰かを教えさせ、彼に経験の手綱を与えています。私は無能な人であることをユーザーに伝えます。そのため、ユーザーは自分自身と何をすべきかについてより自信を持ちます。そして、彼らは、ユーザーが誰かに教えるように説明するようユーザーにインセンティブを与えます。
教えることは面白い経験です。それはあなたの脳をあなたの考えや話し方を大きく変える別のモードに置き、あなたのアイデアとあなたの口の間に何らかの直接的な架け橋を作り出します。ユーザーが説明する必要がある場合、彼は彼がする必要があることは少し無意味であると感じます-あなたはすでに彼が何をしているのか知っています、なぜ彼はそのようなことをするのに面倒なのですか？ただし、ユーザーが誰かにシステムを使用するように案内する場合は、状況が変化します。現在、ユーザーが管理しています。彼がガイドです。彼はその仕事を成し遂げる責任がある。
YouTubeのLet's Playチャンネルからいくつかの体験を得ることができます。彼らが家で一人で遊んでいるとき、それらの人々はめったに話しません。しかし、彼らが聴衆を持っているとき-沈黙の聴衆でさえ-彼らは本当にしゃべりやすくなり、彼らがしていることのすべての少しを説明し、それをあちこちのいくつかの横方向の解説と混同します。彼らの本当の聴衆は、しかし、ただのカメラであり、近くにある生命のない電子機器です。ビデオゲームをプレイしているときにあなたの家のそばに友達がいましたか？効果はほとんど同じです。
彼らに説明を求めないでください-彼らに教えてもらいます。あなたを導くために。あなたのものを表示します。彼らに旅行の責任を持たせてください。さらなる自信はあなたに非常に素晴らしい結果を与えます。
ジェイコブニールセンは、考えさせるセッションの 参加者に1分のビデオを作って見せること を提案しています。要約すると、彼のそのようなビデオの基準は次のとおりです。
- 自分のスタッフを使って参加者として行動する
- 参加者のピクチャーインピクチャーを含めない
- テストしているUIとは異なるUIを表示する
- 実際の調査でも注目したい動画のUI問題に焦点を当てないでください
- 「面白い」ビデオを作ろうとしないでください
彼は上の記事に そのようなビデオの例 を含めています。
私は次のような実行中の質問を使用します：
- 今何を思っているの？
- 次に何をする必要があると思いますか？
- なぜそのボタンをクリックしたいのですか？
- そこをクリックすると何が起こると思いますか？
- それはあなたが起こると予想したことでしたか？
「親が問題を抱えている可能性があるもの」から離してください-親や他の人と一緒に製品をテストしているのではありません。
また、私は候補者に設計/構造が私のものではないので、否定的なコメントでこれを怒らせないように伝えることから始めます（これはときどき「私の両親」のコメントのソースです。問題を警告しますが、個人的に気分を害したくありません）。
また、ユーザーではなく製品をテストしているので、できるだけ正常に動作する必要があることも伝えます。正しく機能しない場合や問題が発生した場合は、ユーザーの責任ではありません。これは、製品にバグが見つかったことを意味します。
最後に、聞きたいことを伝えて、準備をしてみてください。彼らが実行しようとしているタスクについての考え、彼らが抱えている問題、決断や混乱の瞬間、あらゆる行動に対する彼らの推論です。
Think-aududプロトコルを使用する目的は、ユーザーが（通常は）なじみのないシステムを使用しているときにユーザーの頭で何が起こっているかを聞くことです。ええ、それは自然に起こる活動ではありません。
@scottishwildcatと同様に、私は通常、自分で声に出して考え、次に、被験者が練習するための短いタスクを与えます。 （私はそのビデオデモが好きです。）
@ Andrew-Martinと同様に、私は被験者が沈黙したときにプロンプトを出します。ほとんどの場合、「画面に何が表示されますか？」 "何を探していますか？" "あなたは何をしようとしているのですか？"
質問をする前に学習目標を定義してください
質問を適切にフレーミングすると、参加者が「紫色が好き」と言わないようにすることができます
（可能であれば）事前にユーザーの目標を理解してください
特に定型テスト（定義済みのタスク）を実行していない場合は、タスクを開始する前に参加者に目標を尋ねることが役立つ場合があります。人々がなぜクリックしているのか、何を探しているのかを理解するのに役立ちます。
参加者に快適に感じさせる-これはテストではありません
参加者は、「テスト」を実行する人々を友好的であると感じ、認識する必要があります。テストの前に適切な期待を設定することで、参加者はよりオープンになり、より多く話すことができます。 「テスト」という言葉は参加者を怖がらせる可能性があります。彼らは「ああ、彼らは私をテストしている、私は何か間違っているかもしれない」と考えるかもしれません。そのため、タスクを開始する前に、参加者に聞いて、彼らから学んで学ぶことを説明できます。これは、個人のテスト/評価ではありません。また、彼らが間違っていると言ったり、やったりできることは何もないことを伝えます。
実際の生活の中で何をしているのか、どのように関係しているのかについてもっと考えさせます
「このサイトで普段行っていることを考えて、あなたはどう思いますか。いくつかのシナリオを説明してください。あなたの仕事や買い物などで、あまり効果的ではないことは何ですか？」
声を出して話す例を示す
あなたが参加者のふりをして、話し方を見せてください
聞き上手になる
「なぜ？」と尋ねる質問は次のタスクに急ぎません
参加者にリンクが表示されないと思ったことが2、3回ありました。 「なぜ」彼らがリンクをクリックしなかったのかと尋ねると、彼らはリンクに気づいたが、それは解決すべき別の問題である彼らのタスクとは無関係であると説明した
参加者があなたに言っていることに耳を傾けます。時々、新しい質問をしてスクリプトから何かをスキップすることは、詳細を学ぶためにより重要です
参加者に最初のタスクを渡すときは、次のように言います。「これを大声で読んでから、先に進んでそれを行い、セッションを進めるときに大声で考えてください。 "参加者が静かで、はっきりと大声で考えることを忘れている場合は、次のように伝えます。「大声で考えることを忘れないでください。 "質問しないでください、"何を考えていますか？ "、または他のバリエーション。彼らはその時点では何も考えていないかもしれませんが、何か言う前に、彼らが大声で考えることを本当に忘れていることを確認してください。
彼らが画面上の何かに注意を向けている間、または問題に焦点を合わせている間、あなたは彼らを邪魔したくありません。調査中に参加者があなたに質問をした場合、あなたの最初の反応は、彼らを助けるためにそれに答えることかもしれません。ただし、その前に、「どうすればよいと思いますか？」または「ここでは通常何をしますか？ "回答が得られたら、いくつかの情報を提供することを選択できます。
Andrew Martinからの選択された質問に同意します。
また、ユーザーに自分の行動について何らかの正当化を求める場合、タスク全体の認知的負荷が非常に重いことにも注意してください（つまり、タスクの実行にかかる時間が影響を受け、新しい問題に直面する能力も影響を受ける可能性があります。そのような状況ではタスクの効率を評価できません）。そして、非常に多くの場合、ユーザーに説明を求めなければなりません。
この種の思考音声プロトコルは非常に不自然なので、ユーザーは慣れるまでに少し時間が必要です。セッションの最初にデータの質が低下するのを防ぎ、ユーザーをより快適にするために、簡単で楽しい思考のタスクに関するトレーニングとして、少なくとも15分のプレセッションをお勧めします。そうすれば、メインセッション中のユーザーの声が大きくなります。
私はライブまたはビデオのデモンストレーションに確信が持てません。これは受動的であり、ユーザー自身が練習するものではありません。これに対して、簡単なトレーニングセッションでは、ユーザーはthink-aududプロトコルに慣れます。
実際、重要なのは、ユーザーにThink-Aloudとは何かを理解させることではなく、認知負荷の高いプロトコルについてユーザーをトレーニングすることです。
私は習慣的なメモを取る人です。新しいインターフェイスやツールを使用しているときはいつでも、メモを頻繁に作成するので、テキストエディターを常にバックグラウンドで開いたままにしておく必要があります。
多くの場合、メモは私自身の設計上の考慮事項と反省のために作成されますが、後でバグを報告したり、新しい機能を要求したりするために使用できるコメントの形式でそれらを構成することがあります。
残念ながら、すべてのテスターがu.iに関心があるわけではありません。 design et similis、しかしおそらくあなたが彼らに彼らが好きではないものを見るか直感的でないと考えるならば、彼らはそれをどのように再設計するのかを策定し、その理由を説明するべきだと彼らに伝えるべきだったとしたら。
プロ側では、これは彼らがインターフェースへのアプローチを交渉することを奨励するでしょう。多分彼らのアイデアはあなたがあなた自身の概念を拡大するのに役立ちます。
短所：ほとんどのユーザーは、自分の期待を機能要件と関連付ける方法を知りません。彼らは発散してそれを単純に保つことはせず、彼らが目にしたり遭遇した小さな問題に焦点を当てるでしょう。また、彼らが苦情の目的を完全に説明しておらず、彼らの改善の主題に磨きをかけている場合は、ノートにいくつかの追加処理を行う必要があります。
これがテスターに十分な注意を向けるテストである場合、彼らが目前のトピックから離れすぎているか、そうでなければ有用な情報を提供していないときに、いつでも彼らに警告することができます。
それは「セッションの管理」にかかっています
画面に焦点が当てられてタスクを実行している場合は、必要なのは "Keep Talking"プロンプトだけで十分です。あなたは音声録音に沈黙を望まない。
彼らが画面を見ることをやめて、セッションについて話すようにあなたを見ている場合、あなたはそれが役に立たなくなった（時々それが役に立つ、時には役に立たない）その会話を「シャットダウン」する準備ができていなければなりません、そして画面を見ながらタスクを再開します。