思考発話法 (think aloud) の注意点

ユーザビリティテストでは、多くの場合、思考発話法 (think aloud) というメソッドが用いられます。テスター (ユーザー役のテスト協力者) に実際にタスクに取り組んでもらう中で、感じたことを口に出して話してもらう、というものです。

ユーザーの行動や振る舞いの背景にある心の内、とりわけ「なぜ、そうしたのか」を窺い知る手がかりとして、思考発話法は有効であるとされています。また、ユーザーの「生の声」としてプロジェクト関係者にインパクトを与えやすいという副次的効果もあり、ユーザビリティ改善の重要性をプロジェクト内に醸成する武器としても使えます。

しかし、その扱いには、少しばかり注意が必要です。

思考発話法をうまくコントロールする

実際のテスト現場では、タスクに取り組む前に軽く発話の練習をしてみるのですが、テスターに適切な発話をずっと意識してもらうというのは、案外難しいものです。

理想的には、今、頭に浮かんでいることをそのまま「独り言」として発話してもらうことです。感嘆詞 (「あれ?」「まじか!」「えっ?」「おやまあ!」「なにこれ?」など) を伴う感じで「~じゃないの?」「~のはずだと思ったんだけど…」など、期待通りでなかった旨を発話してもらえたらとてもありがたいのですが、現実的には、多くのテスターが「しゃべらなさすぎ」か「しゃべりすぎ」のどちらかに陥ってしまいがちです。

しゃべらなさすぎるテスター

タスクに取り組むうちに、押し黙ってしまうテスターは少なくありません。普段ウェブサイトやアプリケーションを利用する際にいちいちしゃべったりはしないので、自然な行動だと言えます。

このようなケースでは、テスターの行動が止まって、その理由が推測できない場合に限って、「今、どんなことが頭に浮かんでいますか?」などと介入することがあります。そこでネガティブな反応があれば少し深掘りしますし、迷ったり躊躇しているようであれば「もしそれをするとどうなると思いましたか?」と心の内を探ってみます。

ただしこのような介入は、くれぐれもテスターのペースを乱したり、テスターに「ヒント」を与えたりしないようにすることが大事です。また、無理に話を引き出そうとすると結果的に「誘導尋問」のようになってしまうことがあるので注意が必要です。

しゃべりすぎるテスター

その一方で、おしゃべり好きなテスターもいます。ユーザーの「生の声」がどんどんアウトプットされるので、ついそのまま受け入れたくなってしまいますが、このような人は自分の考えを言語化したり、自分の行動を理屈付けするのが得意なことが多く、ユーザビリティテストではご法度の、ユーザーの「意見」の鵜呑みにつながってしまうリスクがあります。

示唆に富んだ知見が得られることもあるので無理に発話を抑える必要はありませんが、あくまでもユーザーの「行動」を観察することをメインとして捉え、発話内容のうち「意見」に相当するものは一歩引いて扱うようにしましょう。

思考発話法を回顧的に採り入れてみる

ちなみに思考発話法には、「Concurrent Think Aloud (タスクに取り組みながらリアルタイムにしゃべる思考発話法)」と「Retrospective Think Aloud (回顧的な思考発話法)」の二つの種類があるという考えかたもあります。

一般的に思考発話法といえば前者 (Concurrent …) を指すことが大半ですが、たとえばアイトラッキングを併用するなどで、事後の振り返り (どのような操作でタスクに取り組んだかの思い出し) がテスターと共に鮮度高い形で可能であれば、そのときどんなことを思い浮かべていたかを回顧的に発話してもらう、というのも効果的です。

ただしこの手法は、回顧に際して記憶バイアスがかかってしまったり、無理に話させることで自身の行動を分析した「意見」にまとめられてしまうリスクがあるため、注意が必要です。ちょっと「意見」に傾いた発話だな、と感じた場合は、「なぜそう思いましたか?」を何度かやってみることで、本質に近づける可能性があります。

リモートテストではテスターの発話を偏重しがち

最近では、手軽なテスト手法として、リモートの (特にモデレーターの介在しない形での) ユーザビリティテストが増えてきました。このようなケースでは、ユーザー行動を直に見ることができない分、ついテスターの発話内容を偏重しがちになります。

実際、Usertesting.com を使ったプロジェクトを何度かやったことがあるのですが、テスターが欧米人という特性もあってか操作しながらの発話が多く (「今、何々をしています。なぜなら~だからです。」といった具合に、「独り言」というよりは「説明的」な発話が多い印象です)、その発話内容だけがプロジェクトチーム内のディスカッション対象となってしまうことがしばしばありました。

上述のように試行発話法による発話はユーザーの「生の声」としてプロジェクト関係者にインパクトを与えやすいという性質もあるため、特にリモートのユーザビリティテストにおいては、分析時における注意点やルール (あくまでもテスターの「行動」を見ることが最重要であること) をプロジェクト関係者の間で共通認識化しておくことが不可欠であると強く感じています。

思考発話法に伴うバイアスを理解する

ところで、思考発話法を用いること自体が、テスターの行動 (ひいてはユーザビリティテストの結果) に影響を与えてしまうという調査もあります (参照 : Does Thinking Aloud Affect Where People Look? - MeasuringU)。思考発話法はテスターを多少なりとも不自然な状況に置くことになる (普段、ウェブサイトやアプリケーションを利用するのにいちいちしゃべったりしない) ため、ある意味当然かもしれません。

たとえば以下のようなバイアスが想定されますが :

…こうしたバイアスの可能性も理解しつつ、思考発話法の利点をうまく活用してゆきたいものです。