ユーザーの目的をユーザビリティテスト用のタスクシナリオにしよう
現実的なタスクシナリオを書くことで参加者を関与させ、行動を促そう。また、そのインタフェースがどのように利用されるべきかは明かさないようにしよう。
あるインタフェースで何が機能し、何が機能してないかを理解する最も有効な方法は、それを利用しているユーザーを観察することである。これがユーザビリティテストの本質だ。適切な参加者が現実的な活動をしようとしているとき、ユーザーが苦労する原因になりそうなことについての定性的知見は得られる。こうした知見はデザインをどのように改善すべきかを決定するのに役立つ。
また、サイト全体のユーザビリティを明らかにする手段として、ユーザーがタスクを正確に達成した割合を測定してもよい。
ユーザーができなければならないこと
参加者を観察するには、彼らに何かすることを与える必要がある。こうした課題をよくタスクと呼ぶ。（私はテスト中はそれを「活動」と呼ぶことで、参加者がテストされているような気持ちにならないようにするのが好きである）。
テストユーザーには単に「○○をしてください」と説明抜きで指示するより、短いシナリオにそうした依頼は組み込むほうがよい。シナリオではユーザーの行動の土台作りをして、ユーザーがなぜ「○○をするのか」についてのちょっとした説明とコンテキストを提供する。
テストで使うタスクシナリオを書く前には、一般的なユーザーの目的のリストを作る必要がある。そうした目的とは、あなた方のサイト（あるいはアプリケーション）の訪問者が抱く可能性のあるものである。次のように自問してみよう。このサイトですべてのユーザーが達成できなければならない最重要のこととはなんだろうか。
例えば、nngroup.comのユーザーが達成できなければならない主な3つの目的とは以下である：
- 特定のトピックについての記事を見つける
- Usability Weekセミナーに登録する
- 我々のコンサルティングサービスについて知る
タスクシナリオにユーザーを関与させよう
ユーザーの目的がはっきりしたら、ユーザビリティテストに適したタスクシナリオを策定する必要がある。タスクシナリオというのは、テストするインタフェースで参加者に取り組んでもらう行動のことである。例えば、タスクシナリオは以下のようなものが考えられる：
3/3～14に休暇でニューヨークに行くことを計画しているとします。手配する必要があるのは飛行機とホテルの両方です。American AirlinesのサイトとjetBlue Airlinesのサイトに行き、どちらがお得かを確認してください。
タスクシナリオに必要なのは、コンテキストを提供することで、ユーザーがそのインタフェースに関与して、彼らが自宅かオフィスにいるかのようにビジネスあるいは個人的タスクを実行しているふりができるようにすることである。
出来の悪いタスクは、ユーザーにある特定の機能とやりとりするよう強制することに力を入れすぎているものが多く、そのインタフェースの利用をユーザーが選択するかどうか、また、どのように選択するか、の確認が目的になってない。シナリオとはタスクにコンテキストを与えるものであるから、参加者の動機づけになるものであることが望ましい。
以下の、タスクを書くときの3つのヒントによって、ユーザビリティ調査の結果は改善するだろう。
(1) タスクは現実的なものにしよう
ユーザーの目的： 提供されている製品をブラウズして、アイテムを買う。
出来の悪いタスク： Nikeのオレンジ色のランニングシューズを1足買ってください。
望ましいタスク： 40ドル未満で靴を1足買ってください。
参加者が普段やらないようなことを依頼すると、そのインタフェースに本当の意味で関与することなく、タスクを達成しようとさせてしまうことになるだろう。タスクの出来が悪いと、参加者はそのタスクを実際に自分のものとしてそのまま受け入れることが難しくなる。この例では、参加者は自分の判断基準に基づき、製品同士を自由に比較できるようにすべきである。
タスクを現実的にすると、リクルートする参加者とテストする機能に左右されることになる。例えば、ホテルのWebサイトをテストするのなら、その家族の中で旅行関係のことを調べて予約する担当になっている人を必ず参加者にする必要がある。
別の方法としては、参加者に自分のタスクを定義させることも可能である。例えば、車を買おうとしているユーザーをリクルートし、セッション中、車について調べるのを続けてもらえば、タスクシナリオを与えなくてもよい（フィールド調査はユーザーが自分自身のタスクを実行しているときに、ユーザー自身の環境にいる彼らを観察するのに適している。しかし、フィールド調査はより費用も時間もかかる）。
(2) タスクは行動しやすいものにしよう
ユーザーの目的： 映画を見つけて、上映時間を調べる。
出来の悪いタスク： 日曜の午後に映画を観ようと思っているとします。www.fandango.comに行って、次にどこをクリックするか教えてください。
望ましいタスク： www.fandago.comを利用して、日曜の午後に観たい映画を見つけてください。
ユーザーにはその行動をどのようにしようと思っているかを聞くのではなく、その行動をして欲しいと依頼するのが一番である。「Xをする方法をどうやって見つけるつもりですか」とか、「Yをどのようにするつもりか教えてください」と聞くと、参加者は行動ではなく、言葉で答えようとするだろう。また、残念ながら、彼らが実際にそのシステムを利用しているときほどは、ユーザーが自己申告するデータは正確ではない。その上、彼らにやろうと思っていることを説明させることで、そのインタフェースが気軽に利用されているところや、利用に苛立っているところは観察できなくなる。
参加者が進行役のほうを向いて、マウスから手を離し、「最初はここをクリックしようと思います。そうすれば、行きたい場所へのリンクがあるだろうと思うので、今度はそれをクリックするつもりです」などと言うようなら、そのタスクは行動につながりにくいと言えるだろう。
(3) ヒントを与えたり、手順の説明をするのは避けよう
ユーザーの目的： 成績を調べる。
出来の悪いタスク： 中間試験の結果を確認したいと思っているとします。Webサイトに行って、サインインし、成績証明書を入手するのにどこをクリックするつもりか教えてください。
望ましいタスク： 中間試験の結果を確認してください。
手順の説明にはそのインタフェースの利用方法の隠れたヒントが含まれていることが多い。例えば、メインメニューの福利厚生をクリックするように指示することで、そのメニューラベルが彼女にとって意味のあるものかについてはわからなくなる。こうしたタスクはユーザーの行動にバイアスをかけ、もたらされる結果を役に立たないものにする。
インタフェースで利用されている用語がタスクシナリオに含まれていることでも、ユーザーへのバイアスはかかる。もし、ユーザーがニュースレターに登録するかどうかを知りたいと考えていて、あなた方のサイトにニュースレターに登録するというラベルの大きなボタンがあるなら、タスクには「この会社の週刊ニュースレターに登録してください」などという言い回しは使うべきではない。例えば「予定されているイベントについての情報を入手するために、定期的にEメールを送ってもらう手段を見つけよう」といったタスクにするほうががよい。
とはいえ、インタフェースで利用されている言葉を避けるというのが、常に容易で、自然であるとも限らず、ユーザーを混乱させることになることもありうる。既に標準的になっている、よく知られている名称を持つものを、回りくどいやり方で説明しようとする場合は特にそうだ。そうした場合は定着しているその用語を利用したいと思うだろう。
ヒントになる言葉を避けるからといって、曖昧になるわけではない。例えば、以下の2つのタスクを比較してみよう：
出来の悪いタスク： 歯医者の予約を取ってください。
望ましいタスク： あなたのかかりつけの歯医者、Dr. Petersenの予約を来週火曜の午前10時に取ってください。
ユーザーのかかりつけの歯医者が現実にDr. Petersenではない場合には、この2番目のタスクは「タスクは現実的であれ」というガイドラインに反するではないかと思うかもしれない。しかしながら、このタスクはユーザーによく受け入れられ、違う名前の歯医者にするのと同じように、予約という行為にスムーズに進んだ事例のうちの1つである。テストしているのがペーパープロトタイプ等の開発初期のプロトタイプのデザインで、そこには数人の歯医者しか載せてないというなら、ユーザーにはDr. Petersenを受診するふりをしてもらう必要があるだろうが。
タスクシナリオが曖昧すぎると、参加者がさらに情報を求める可能性が高くなったり、正しい道を進んでいるかどうかを確認したくなったりする。参加者にはタスクを達成するために必要な情報はすべて提供し、彼女がどこをクリックするかは言わなくていいようにしよう。
まとめ
ユーザビリティテストでは現実の世界を可能な限り再現しよう。代表的なユーザーをリクルートし、1つ1つのタスクシナリオは、確実に、1)現実的で、ユーザーが好きなときに、自分のやりたい活動をするのにそのシステムを実際に利用するための典型的なものにしよう。そして、2)ユーザーにそのインタフェースとのインタラクションを促すものにしよう。そして、3)そこでは答えを明かさないようにしよう。
