定量と定性のユーザビリティ調査タスクの作り方

どんな種類のユーザビリティテストも、成功させるには注意深く作成されたタスクが欠かせない。調査の具体的な手法にかかわらず、タスクに常に必要な特性というものはある。しかしながら、厳密に良いタスクといえるものは、実施するユーザビリティ調査が定量的か定性的かによって異なってくる。

背景：定量調査と定性調査

ユーザビリティテストの定量調査と定性調査には違いがいろいろとある。それぞれ、適した調査目的は異なるからだ。

定量調査は科学的な実験によく似ていて、十分にコントロールされた厳密な条件のもとで（タスクの成功やかかった時間といった）指標をとらえることを目的としている。

対照的に、定性調査の狙いはUIにある問題を発見しようとするものだ。定性調査の目的は、一人一人のユーザーが感じた思いや経験した困難を理解することにある。定性調査は、UIにある課題を浮き彫りにする可能性のある、オープンエンドな活動をユーザーに提示することでおこなわれることが多い。

したがって、大まかにまとめると、定量的なユーザーテストの目的は数値だが、定性的なテストの目的は知見ということになる。

この2つの手法は目的も特性もかなり違うので、調査の種類によってタスクを書き分ける必要がある。定性調査に最適なタスクが定量調査にはまったく機能しないということは多い。そしてその逆も同じなのである。

では、まずは、定量であれ定性であれ、あらゆるユーザーテストのタスク作成の基本になる原則から見ていこう。

あらゆる調査向けのタスクの作成

• タスクに関するインスピレーションを得るために、あなた方の製品によってユーザーが何をおこなう必要があるのかを調べよう。タスクは可能な限り現実的なものでなければならないことは覚えておいてほしい。参加者に実生活ではやらないようなことをするように強制すべきではない。自分たちのプロジェクトに無関係なことを測定することになってしまうからだ。ユーザーがあなた方の製品を何のために利用したいと思っているのかは、ユーザーインタビューや検索ログデータ、カスタマーサービスの電話、アナリティクスデータで調べるとよい。
• タスクの中でうっかり手がかりを与えてしまうことがないようにしよう。ユーザーが進まなければならないステップをそのまま説明してはならない。そうではなく、自分自身で考えてもらおう。また、UIのラベルに使っている言葉をそっくりそのまま書かないようにしよう。ユーザーに先行刺激を与えて、特定の単語を探させるべきではない。

  ダメなタスク：Alertboxに登録してください。
  改善案：このサイトのニュースレターに登録してください。

• タスクは感情を伴わないものにしよう。タスクを作成するときには、ユーザーの私生活や人間関係について決めつけないことだ。タスクは極力、「友達」に関するものにして、「お父さん」や「配偶者」などの家族には触れないほうがよい。

  ダメなタスク：お母さんの誕生日のためのプレゼントを探してください。
  改善案：友達の誕生日のためのプレゼントを探してください。

• タスクは常にパイロットテストをしよう。これは不可欠なステップだが、飛ばしてしまうリサーチャーが多すぎる。自分たちの考えたタスクでうまくいくと思っているのかもしれないが、1人か2人の代表的なユーザーに試してもらわないとわからないものだ。調査の予算とスケジュールの計画には必ずパイロットテストを入れておこう。そうしておけば、そうと知らないで良くないタスクを使ってリソースを無駄にしたり、間違ったデータを集めたりしないですむ。

定性調査向けのタスクの作成

• オープンエンドなタスクでもよい。定性調査では、タスクはさまざまに解釈できるようにしていい。ときにはユーザーに具体的な基準を示す必要が出てくることもあるだろうが、それと同時にユーザーが重視していることや彼らの意思決定の要因を確認することのできる余地をタスクに残しておいてもよい。

  具体的な定性タスク：Cash Rewards Credit Card（＝クレジットカードの名称）を作ってください。
  オープンエンドな定性タスク：あなたのニーズに合うクレジットカードを見つけてください。

• 状況を説明するのに十分なだけの詳細情報を提供しよう。しかし、度を超してはならない。重要なのは、このタスクに対して参加者にしっかりとやる気になってもらうことであって、小説を書く必要はないからだ。その参加者が自分たちの実際のユーザーを代表しているということが確認済みで、そのタスクが彼らにとって現実的なものであることが間違いないなら、コンテキストを過度に提供する必要はないはずだ。
• 求めている知見が得られないなら、タスクを変更しよう。定性調査では調査の途中でタスクの言い回しを変えたり、また、全面的にそのタスクをやめてしまったり、新しいタスクを追加したとしても問題ない。定性調査では、有益な観察結果を入手することがすべてだ。したがって、参加者全員にまったく同じタスクをさせなくても構わない（実際、役に立たないタスクを繰り返して、参加者の貴重な時間を無駄にするよりはましだ）。

定量調査向けのタスクの作成

• タスクのやり方が1つしかないということを確認しよう。定性的なタスクとは対照的に、定量調査向けのタスクは可能な解釈や解決方法が１つだけである必要がある。あいまいにしてはならない。
  タスクの指示が大まかすぎたり、オープンエンドだったりすると、参加者ごとに本質的に異なったタスクをおこなってしまったり、インタフェース内で違う経路を進んでしまう可能性がある。そうなると、集めた指標のあらわすものが同じものではなくなるので、データに大きなばらつきが出ることになる。また、可能な解決方法がいろいろとあるとしたら、何をもって「成功」と見なせばよいのか。

  ダメなタスク：あなたのニーズに合うクレジットカードを見つけてください。
  改善案：Cash Rewards Credit Cardを作ってください。

• タスクを限定的で明確なものにしておくのに必要なだけの詳細情報を提供しよう。これはつまり、一部の定量調査は、提供する情報が細かすぎるということだ。
  また、十分な量の詳細情報を提示していると考えていても、その後、パイロットテストをしてみると、まだ忘れていたことがあったと気づくこともよくある。たとえば、タスクでユーザーに伝える情報は、どの時期にどのホテルを予約するかということだけでは十分ではない。すなわち、どの種類の部屋を予約するのかも伝える必要があるのだ。このレベルの指示は定性調査では不要だ。しかし、定量テストでは、参加者全員にまったく同じタスクを確実に実行してもらうために必要なのである。

  ダメなタスク：シカゴのハイアットリージェンシーホテルに、2人用の部屋を、1月17日から19日まで予約してください。
  改善案：シカゴのハイアットリージェンシーホテルに、クイーンベッドのある2人用の部屋を、1月17日から19日まで予約してください。

• ログインや決済などの個人情報の入力が必要なタスクには偽の認証情報（ダミーデータ）を提供しよう。実際に皆が同じ情報を入力することになればばらつきも最小限に抑えられる。参加者全員が同じ文字列を入力することになるからだ。また、自分のデータを公開することを人よりためらう人もいるかもしれない。そうなると、彼らの納得のいく解決策を見つけるのに時間が余分にかかる可能性もある（多くの定性調査では、むしろ、参加者に彼らの実際のデータを利用させてもらうべきだろう)。
• タスクはそれぞれ独立しているべきである。理想としては、定量調査では、タスクの順番はランダム化するとよい。しかし、タスクが2つあり、片方のタスクがもう1つのタスクを前提にしていると、それらのタスクは常に同じ順番で提示しなければならなくなる。その上、最初のタスクを失敗した人は2番目のタスクも自動的に失敗ということになってしまう。

  ダメなタスク：
  タスク1：Joe Smithの人事ファイルを見つけてください。
  タスク2：Joe Smithの人事ファイルのページで、彼の直属の上司を見つけてください。
  改善案：
  タスク1：Joe Smithの人事ファイルを見つけてください。
  タスク2：このリンクで提供されているページで、誰がJim Grantの直属の上司なのかを見つけてください。

• それぞれのタスクの成功指標は1つだけであるべきだ。したがって、2つのタスクを1つのタスクにまとめるのはやめたほうがよい。定量調査で必要なのは、タスク時間とそのユーザーが成功したかどうかを判断するのに役立つ、たった1つの明確な評価項目である。1つのタスクに成功の指標が複数ある場合、ユーザーが1つの情報は見つけられても、それ以外を見つけられなかったらどうなるだろう。タスクが重なっている状態なら、分割することで修正しよう。

  ダメなタスク：博物館の住所と祝祭日の営業時間を見つけてください。
  改善案：
  タスク1：博物館の住所を見つけてください。
  タスク2：博物館の祝祭日の営業時間を見つけてください。

• いったん調査を開始したら、タスクは変更しないようにしよう。定量調査では、各参加者がまったく同じタスクをおこなっていることが重要だ。この種の調査ではあなた方が設定した独立変数（たとえば、あなた方のアプリ　対　競合他社のアプリなど）以外のすべての条件を一定に保つべきである。つまり、途中でやめるべきではないし、タスクの言い回しを変えるわけにもいかないということだ。そうしてしまうと最終的な結果に悪影響が出る恐れがあるからだ。パイロットテストはどんな調査にとっても不可欠だが、調査の途中での変更が難しい定量調査の場合はとりわけ重要である。
• 重要なタスクに集中しよう。定量調査には費用がかかる。そのため、ユーザーや組織にとって優先順位が低いタスクをテストしても元が取れない。定性テストは実際にある極端な事例をタスクとして試せる柔軟性がある。しかし、定量調査は最も重要な中心的タスクに集中しなければならない。

まとめ：定性調査向けタスク 対 定量調査向けタスク

計画中の調査の種類にかかわらず、良いタスクを作成するには練習が必要である。

定性調査向けに良いタスクを書くための実践的な練習や、定性的なユーザビリティ調査の進行のためのヒントを得るには、我々の1日セミナー、「Usability Testing」をチェックしてみてほしい。