1. ホーム
2. ニールセン博士のAlertbox

ユーザーテストで知見を最大化する方法：
段階的なユーザータスク

ユーザーテストでは、興味のある領域にすぐに誘導するのではなく、幅広いタスクから始めると、状況に合った内容だけでなく、他にもたくさんのことを知ることができる。ユーザーを誘導するために利用できる、焦点を絞ったタスクを追加で準備しておこう。

• How to Maximize Insights in User Testing: Stepped User Tasks
• by Kara Pernice
• on February 9, 2020
• 日本語版2020年11月26日公開

ユーザビリティテストのタスクを書く際には、ユーザーに伝える情報が多すぎることもなければ少なすぎることもないという絶妙なバランスを取る必要がある。ユーザビリティテストのタスクは、そのテストの対象がWebサイトのデザイン変更であれ新しいコンテンツであれ、チームが興味のあるサイト領域に直接ユーザーを誘導するものが多すぎる。しかし、通常、こうしたアプローチを取ると、その機能のユーザビリティに関する情報は何かしら得ることはできるが、発見しやすさや見つけやすさ（discoverability and findability）という重要なトピックについて知る機会が棚上げされる。そして、こうしたアプローチは、一部の企業が多くのテストをおこなっているにもかかわらず、役に立たないデザインを生み出している原因でもある。ユーザーには最初は大まかな指示を出してから、自分たちが調べたい内容に誘導するほうがより多くのことを知ることができる。あなたの興味のあるポイントを直接のターゲットにしたタスクを準備しておこう。しかし、このタスクは、幅広いタスクでは必要な知見が得られない場合のみ、参加者に与えよう。

段階的なタスク

定義：ユーザビリティテストにおける段階的なタスク（stepped task）とは、同一のアクティビティに向けて段階的に具体的かつ精巧になっていく指示を提示する、関連する一連のタスク（ステップ）を構成するタスクの1つのことだ。一連の段階的なタスクの中の最初のステップは最も漠然としている。しかし、ユーザーがそのタスクをきちんと実行できた場合には、リサーチャーは彼らがそれに取り組んでいるところを観察することで、必要とするすべての情報を得ることができる。

第2ステップのタスクは、チームが興味のあるUI領域を、参加者が最初の試行で操作しなかった場合に、彼らを正しい方向に導くための最小限のヒントを提供するフォローアップ質問と考えるとよい。（必要に応じて）第3ステップでも最小限のヒントを与えよう。そして、それ以降も必要に応じてステップを追加し、同じようにしていけばよい。

サブタスクを楽に記録できる方法が、タスク番号の後に文字を追加する、またはメインタスクの数字に小数点を振ることだ。したがって、タスク4の場合、ステップは4、4A、4B（または4、4.1、4.2、4.3）というようになる。私がユーザビリティテストの進行役をしているときには、こうした小さなことでもプロセスを効率化するとともに、調査で達成しようとしていることをチームに提供するのに役立っている。（注：私はタスク番号をユーザーには決して見せない。なぜならば、タスクを順番通りに与えないこともあれば、一部を飛ばしたりすることもあるので、ユーザーの中には当惑する人もいるからだ。また、タスク番号を見たことで、依頼されるタスクは何個あるのだろうとユーザーに考えさせてしまい、そのせいで彼らの気が散ることもありうる。）

一連の段階的なタスクの例

では、ユーザビリティテストにおける一連の段階的なタスクの例を見ていこう。企業イントラネットにあるカレンダー機能をユーザーに発見したり見つけてもらって利用してほしい、と考えていると想像してみてほしい。

調査目標：どのくらい楽にカレンダーを発見したり見つけたり利用したりできるか。
タスク4：「同僚のRichard Smithから、1月12日の午後2時から3時までの時間に会議を開催するように依頼されました。忘れないようにするために、あなたはどんなことをするでしょうか」。		このタスクで実現できること：利用可能な機能がUIにあるということを具体的に示したり、その名称や場所、利用方法を伝えたりせずに、こうした機能があることを示唆。
	ユーザーのアクション：イントラネットのカレンダーに移動し、エントリーを作成。 ファシリテーターのアクション：すべての関連情報が収集されたので、ここで多段階式タスクを停止。	判明したこと：ユーザーは、そこにカレンダーがあることを直接知らされなくても、その存在に気づき、我々が調べたい機能を利用した。
	ユーザーのアクション：携帯電話を手に取って、ToDo項目を追加。 ファシリテーターのアクション：調査目標がまだ達成されていないため、ユーザーに多段階式タスクの次のステップのタスクを提供。	判明したこと：ユーザーは、この大まかなタスクを実行するのに別のやり方を採用することにした。そのため、イントラネットのカレンダーに関する情報は得られなかった。
タスク4-A：「Richard Smithとのミーティングのために、1月12日の午後2時から3時までの時間を押さえる別の方法を見つけてください」。		このタスクで実現できること：ユーザーにカレンダー機能を直接指示したり、名称を指定したり、利用方法を指示したりせずに、利用可能な機能があることを示唆。
	ユーザーのアクション：イントラネットのカレンダーに移動し、エントリーを作成。 ファシリテーターのアクション：すべての関連情報が収集されたので、ここで多段階式タスクを停止。	判明したこと：ユーザーはカレンダーがあることを具体的に知らされなくても、カレンダーを発見し、エントリーを作成した。（しかし、彼らが最初に思い浮かべたものが我々のカレンダーではなかったこともわかっているので、我々にはやるべきことがいくつかある）。
	ユーザーのアクション：「カレンダーがあるのではないかと思う」と言ってカレンダーを探す。しかし、見つけられないので、それをイントラネットで探すことをあきらめる。そして、その代わりに、物理的な付箋を書いてそれを机に貼る、と発言。 ファシリテーターのアクション：調査目標がまだ完全には達成されていない（具体的には、ユーザーがカレンダーを見つけて利用できるかどうかが不明である）ため、ユーザーに多段階式タスクの次のステップのタスクを提供。	判明したこと：彼はカレンダーがあることを具体的に知らされなくても、カレンダーがある可能性に気づいたが、カレンダー自体を見つけることはできなかった。彼がカレンダーを利用できるかどうかは不明である。
タスク4-B：「イントラネットに会議の予定を入れる方法があります。イントラネットを利用して、1月12日の午後2時から3時までの時間をRichard Smithとの会議のために押さえてください」。		このタスクで実現できること：カレンダーのような機能があることを、その名称や場所、利用方法を具体的に伝えずにユーザーに知らせる。
	ユーザーのアクション：イントラネットのカレンダーに移動し、エントリーを作成。 ファシリテーターのアクション：すべての関連情報が収集されたので、ここで多段階式タスクを停止。	判明したこと：カレンダーのような機能があることを知らされると、ユーザーはそれを見つけて、エントリーを作成した。
	ユーザーのアクション：「わかりました。カレンダーがあると思います」と言って、カレンダーを探し回るが見つからず、イントラネットでそれを探すのをギブアップ。 ファシリテーターのアクション：調査目標がまだ完全には達成されていない（具体的には、ユーザーがカレンダーを見つけて利用できるかどうかが不明である）ため、ユーザーに多段階式タスクの次の段階のタスクを提供。	判明したこと：イントラネット上にカレンダーのような機能が存在することを知らされても、ユーザーはそれを見つけることができなかった。彼がカレンダーを利用できるかどうかは不明である。
タスク4-C：この時点で、ファシリテーターはこのユーザーをイントラネットのカレンダーに連れていき、同じタスクを与える。「このイントラネットツールを利用して、1月12日の午後2時から3時までの時間をRichard Smithとの会議のために押さえてください」。		このタスクで実現できること：ユーザーにカレンダー機能の利用方法を説明せずに、カレンダー機能に誘導。
	ユーザーのアクション：イントラネットのカレンダーに移動し、エントリーを作成。 ファシリテーターのアクション：すべての関連情報が収集されたので、ここで多段階式タスクを停止。	判明したこと：ユーザーはカレンダーを見つけることができなかった。しかし、カレンダーに連れてこられると、彼はそれを使ってエントリーを作成することができた。
	ユーザーのアクション：イントラネットのカレンダーにエントリーを作成できない。または、エントリー作成中に問題が発生。 ファシリテーターのアクション：観察された動作に応じて、ここで多段階式タスクを停止するか、カレンダー内の「個々の」機能の用法を確認する追加のサブタスクの提供を継続。	判明したこと：このユーザーはイントラネットにカレンダーがあることに気づかなかったし、カレンダーがあると知らされてからもそれを見つけることができなかった。カレンダーに連れてこられた後、彼がエントリーを作成しようとすると、問題が発生した。（したがって、このデザインには、見つけやすさや移動のしやすさ、カレンダー機能自体のインタラクションデザインに関する問題がある）。

一連の段階的なタスクで次のタスクにシームレスに移動してもらうには、言葉によって参加者の不安を取り除くとよい。たとえば、以下のように言ってみるのもいいだろう：

• ［見たものを記録していることを示すためにメモを書きながら］「そういうことをしていただいてありがとうございます。とても参考になるメモをたくさん取ることができました。イントラネットでも会議の予定を入れる方法があるのですが、そうと知ったら…」
• 「ありがとうございます。とても参考になりました。それをやってみての感想が何かありますか」［コメントを待つ］「あなたがそれをするのを見て、多くのことを学ぶことができました。では今度はこれをやってみてください」［彼らをカレンダーエリアに連れていく］

その後、印刷したタスクを指し示せばよい：

「イントラネットを利用して、1月12日の午後2時から3時までの時間をRichard Smithとの会議のために押さえてください」。

ありふれたラベルを使って機能をテストするための段階的なタスク

段階的なタスクは多くの事例で役に立つ。しかし、このタスクが有用な主な状況とは、タスクで機能名を利用したくない場合、つまり、発見しやすさや見つけやすさをテストする場合である。

UI機能やコンテンツの発見しやすさとは、その機能やコンテンツがインタフェースに存在することをユーザーがどれだけ容易に認識できるかを指す。したがって、機能が存在することをタスクの指示の中で、前もってテスト参加者に伝えることは、彼らがその機能を自分で発見できるかどうかを知る機会を逃してしまうということである。だからこそ、段階的なタスクでは、最初のタスクが最も幅広いのである。しかし、参加者がその機能を発見できない場合は、それ以降のステップで徐々にその機能に誘導すればよい。その時点で、この機能は発見されにくいということになる。

UI機能やコンテンツの見つけやすさとは、ユーザーがその機能の存在を知ってから、どれだけ容易にそれを見つけてアクセスできるかを指す。機能の見つけ方を前もってテスト参加者に伝えることは、彼らがその機能を自分で見つけることができるかどうかを知る機会を逃してしまうということである。

UIにある言葉の回避

一般に、タスクではUIで利用されているのと同じ用語は使わないようにしよう。このガイドラインに従うのは難しいかもしれない。というのも、本来は、何らかのユーザー調査をすでに実施していて、そこでのユーザーのメンタルモデルに一致する用語を選択しているものだからだ。たとえば、ユーザーがその機能を「グラフ」と認識していたので、アプリのボタンに「グラフを作成」という名前を付けたとする。その場合、この機能のテストをするために、「グラフ」という概念を指す別の単語を考え出すのは容易ではない。しかし、それをする価値はある。タスクの説明で同じ単語を利用すると、ユーザーにプライミング効果が起こり、彼らがUIでその名前を探してしまうからだ。テスト参加者は、タスクを読んだ後、その指示に出てきた1つまたは複数の単語を検索ボックスに入力することがある。あるいは、タスクの説明にあるとおりの単語を、UIを流し読みして探したりもする。その結果、彼らは答えを早く見つけられ、そのタスクを実際以上に容易に感じて、ユーザーとリサーチャーの両方に誤った自信や満足感、錯覚を与える可能性がある。

また、タスクの説明を複雑で抽象的になりすぎないようにしつつ、説明的なアクティビティや語句を一般的な単語に置き換えるのもたいへんなことだ。とりあえずやってみてもよいとは思うが、段階的なタスクも準備しておき、そこで別の類義語を試したり、名前を言う代わりに何をする機能なのかを説明したりすればよい。たとえば、参加者にグラフ機能を利用してもらうために、数字の入った表を与えてそのデータをチームに伝えるように依頼したり、グラフの画像を表示してそれを再現してもらうのもいいだろう。

上記のカレンダーの例でいうと、カレンダー機能は時間帯を確保するためのものなので、そのようなタスクの指示にしているが、タスクでは、（UIで利用されている用語の）「カレンダー」や「スケジュール」という言葉には触れていない。そのため、カレンダーがあることにユーザーが気づき、それを使おうと考え、会議を設定するコマンドを見つけることができるかどうかを確認することが可能である。

単にテストセッション中に新しいタスクを作成すればよいのではないか

ここで、次のような疑問をもつかもしれない。タスクの説明を大まかなものにしておいて、テスト中に何が起こるか、様子をみればよいのではないか。そして、ユーザーが機能を見つけたり発見したりすることができない場合は、ファシリテーターが必要に応じてタスクを追加することで、その場で対応すればよいのではないか、と。それも1つのオプションではある。そして、問題が発生するまで、そうした可能性があることを予測していなかったために、実際にこのルートを取ることを余儀なくされることもある。しかし、私は以下の理由から、可能な限りこのアプローチは取りたくないと考えている：

• プレッシャーの中で適切なタスクを作り上げるのは難しい。テストタスクの作成には、何度も試したり、他の人からのレビューを受けたりする必要がある。ユーザビリティテストのファシリテーターとしてこれ以外のすべての役割にも集中しているときに、ユーザーが見て待っている状態で、適切なタスクを作成するというのは容易ではない。その結果、タスクが誘導的になりすぎたり、効果的でなかったり、お粗末なものになる可能性がある。また、この記事の段階的なタスクの例はシンプルに見えるが、その理由の1つは、ファシリテーターが課題を予測して、そのために準備しておいたものであるためで、テスト中に驚いて、必要に応じて対応したものではないからだ。
• 書面に書かれたタスクによって、ユーザビリティテストはファシリテーターが観察を実践する場であり、インタビューや会話ではないということが強調される。ユーザーがユーザビリティテストで苦労しているのを見ているのはつらいものだ。しかし、多くのユーザーが問題に遭遇しないですむように、UIの問題について知り、それを後で修正するためには、通常はそれをおこなう必要がある。それでも、テストのファシリテーターの中には、テスト参加者が苦労するのを見ているのは気が引けるという理由で、彼らを助けるタイミングが早すぎる人もいる。

観察であって会話ではないことを強調しよう

ファシリテーターがテスト参加者に話しかければ話しかけるほど、参加者はそれに慣れて、ユーザビリティテストが会話やインタビューのようになることを期待する。適切なユーザビリティテストにはリズムがあり、以下のように進んでいく：

1. ファシリテーターがユーザーにタスクを渡す。
2. ユーザーがそれを声に出して読む。
3. （通常、思考発話しながら）ユーザーがそれに取り組む
4. ファシリテーターはほぼ黙っている。
5. タスクが終了する。
6. ファシリテーターがフォローアップ質問をする。
7. ファシリテーターが次のタスクをユーザーに渡す。

ファシリテーターが新しいタスクを作り出す必要があると、このリズムは崩れてしまう。

ユーザーにタスクを書面で渡すことで、ユーザビリティテストは基本的にはファシリテーターが観察を実践する場であって、インタビューや会話ではないということを彼らに再認識させることができる。

また、複数段階からなる会話として準備しておいたセリフを読むことで、多く言いすぎたり、気まずいために手伝ってしまうことが癖になることを、多少なりとも防ぐことができる。

結論

企業の中には、ユーザーテストを含む調査に多額の費用を費やしているにもかかわらず、不適切なデザインを生み出しているところもある。このような状況になるには多くの理由があるが、その1つは、ユーザーテストで与えるタスクが的を絞りすぎたものであることだ。これは私が他のリサーチャーを指導してきた長年の間に、数え切れないほど見てきた課題でもある。「的を絞りすぎたタスク」とは、「誘導的なタスク」、つまり、ユーザーにプライミング効果を与えたり、指示を提供したり、タスクに影響を与えるUIについての情報を漏らすようなタスクということではない。むしろ、タスクとして問題があるわけではないが、テストするUI機能の発見しやすさや見つけやすさなどの要素を考慮に入れていないもののことをいう。

発見しやすさや見つけやすさをテストすることは容易ではないが、それでもテストできるように努力すべきだ。具体的でない大まかなタスクは、ユーザーに自分でUI機能を発見してアクセスする機会を与え、テストの指示や誘導を減らすことで、ユーザーが本来UIとどのようにインタラクトするかについてより多くの知見をもたらす。しかし、ユーザーが調査対象の機能に自分でたどり着けない場合は、その機能のユーザビリティについて知ることができるように、段階的なタスクによってユーザーをそこに連れていけばよい。テスト参加者の一人一人にかかる費用は安いものではない。そのため、毎回のセッションからできるだけ多くの知見を引き出すべきなのである。