定性的ユーザビリティテストのタスクの改善：
防ぎたい間違い・トップ10
ユーザビリティ調査のために適切なタスクを書くのは、科学ではなく芸術の分野の作業だ。とはいえ、そこにもルールはある。タスク作りでよくある以下の間違い10個に自分のタスクが該当していないかチェックしよう。
定性的なユーザビリティ調査を大きく左右するのが、テストするデザイン、テストする参加者、そして、（特に多いのが）セッションを運営する進行役である。だが、これ以外にも重要な要素というのは存在する。それがタスクである。
タスクに求められるのは、UXリサーチャーのゴールを正確かつ適切に反映すること、さらに、参加者がやらなければならないことについての明確な指示を与えることである。正確で行動を起こしやすい調査結果が得られるユーザビリティ調査には、良質なタスクが不可欠といえよう。
ユーザビリティテストのタスクを書くというのは、容易なことではない。経験豊富なユーザビリティリサーチャーなら誰でも言うことだが、タスクの書き方は調査の成功に直結しているからだ。調査参加者に与えた指示が不適切だと、参加者にバイアスをかけ、調査の結果がまったく変わってしまうこともありうる。そうなると、良くて、調査から得られることがたいしてなく、その調査が現実世界の利用をあまり反映していないという程度だが、最悪だと、「調査結果」のせいで判断を誤り、そのせいで製品を改善するどころか、改悪してしまう結果になってしまいかねない。
タスクを書き終わったら、一通り見返し、得られる結果の価値や深さ、あるいは、参加者の快適さに影響を与える、以下に挙げたよくある間違いをしていないかどうかを確認しよう。
1. 行き先をユーザーに説明してしまう
インタフェースに登場する言葉がタスクの中に出ていないだろうか。もしそうなら、参加者にプライミング（訳注：プライミング効果とは、先行の刺激が後続の別の刺激の処理に、無意識的に影響をあたえること）してしまっているので、ユーザーの読解力や一致する言葉を見つける能力のテストになり、ラベルやナビゲーションのテストにはならなくなってしまう。そのタスクは書き直し、インタフェース内に出ている言葉をすべて削除しよう。そうすれば、ユーザーがサイト内で自分で行き先を見つけられるかどうかをきちんと確認できるだろう。
タスクのゴール：支店検索ツールを利用する（ラベルは「Find a Branch」（：支店を検索する））
ユーザーを誘導しているタスクの例：最寄りの支店を検索して、その支店の明日の開店時間を確認してください（Find a branch near you and see when it is open tomorrow.）。
改善例：最も行きやすい場所にある銀行の明日の開店時間は何時ですか（When is the bank location that’s most convenient to you open tomorrow?）。
2. やるべきことをユーザーに説明してしまう
サイトに登録して、ソフトウェアをインストールしたり、書類をダウンロードするなど、タスクの一環として、ユーザーがいくつかのステップを踏まなければならない場合もある。こうした場合には、調査参加者がしなければならないことを彼らには予告しないようにして、このプロセスに関する情報をより多く集める機会としよう。タスクに登録やインストール、ダウンロードの指示を入れてしまうと、プロセス中の該当ステップにあたったときにユーザーが提供してくれる貴重なフィードバックを逃す可能性がある。たとえば、追加されたステップまたは予想してなかったステップに、参加者が驚いたり、イライラするということはありうるからだ。
タスクのゴール：コンサルティングサービスの料金を確認する
作り込みすぎているタスクの例：コンサルティングサービスについての情報を見つけて、あなたとあなたの会社についての詳しい状況を提示し、料金についてコンサルタントと話し合う時間を設定してください。
改善例：コンサルティング料金がいくらかを調べてください。
3. 時期が外れたタスクを作成してしまう
ユーザビリティ調査の予定日のほんの数日前にタスクを書く、というのはよくあることだ。しかし、そうであっても、タスクの適時性についてはよく考える必要がある。タスクに未来の出来事が含まれているなら、テスト期間中にもその出来事が未来のものであることを確認しよう。たとえば、タスクが、2月20日の飛行機の出発便を見つける、というものなら、そのテストは2月22日に実施すべきではない。また、タスクがサイト内の最新のニュースに関するものなら、テストの日かその前日にサイトを更新して、コンテンツを最新のものにしておく必要があるだろう。特定の月や季節にしか関係なかったり、更新されないことが多い情報がタスクに含まれていないかにも注意が必要だ。このサイトにある情報は古い、あるいは、このタスクは非現実的だ、とユーザーが思ってしまう可能性があるからである。
タスクのゴール：スポーツチームの得点を確認する（このテストは2月に実施されたものとする。米国では、野球のシーズンは4月から10月、ホッケーのシーズンは10月から4月である）
時期外れになっているタスクの例：野球チームのCubsの最新の試合の結果について調べてください。
改善例：ホッケーチームのBlackhawksの最新の試合の結果について調べてください。
4. タスクをシンプルにしすぎしている
サイトにある図やグラフ、情報が効果的に利用されているかどうかを知りたいのなら、そうした情報に移動できるかどうかのみのテストにしてはならない。そのためには、調査参加者がそうした情報に多少は取り組むことになるタスクを作成する必要がある。ここでの目標は、タスクをいたずらに難しくはせず、単に情報を見つけるだけではない、処理の必要な現実的なタスクをユーザーに与えることである。
タスクのゴール：選手の成績データを見つけて利用する（「1試合平均得点数」は、選手の成績データの最初にあり、そこでは得点数の多い順に選手が並んでいる）
やさしすぎるタスクの例：全試合を通じての平均得点がリーグで最も多かったのは誰ですか。
改善例：Russell WestbrookとLeBron Jamesのどちらがそのシーズンの全試合平均得点数が上でしたか。
5. 作成したシナリオが複雑すぎる
タスクによっては、活動にコンテキストを与えるちょっとしたシナリオが有用な場合もある。その際、参加者がそうしたタスクをしなければならない理由を理解したり、見つけてほしいと期待されている正確な情報を確認するには、説明は短かいほうが助けになる。参加者が音楽について調べなければならないのなら、音楽のジャンルを、また、特定の情報を探さなければならないなら、その理由を提示すればよいし、買い物をしなければならないのなら、その物の名前やアドレスなどを提供すればよいのである。たとえば、プレゼントをもらう人の誕生日がいつかといった情報を入れておくと、プレゼントが予定通りに届いたかを確認するという配送オプションをユーザーが見つけられるかどうかを確認できるだろう。
シナリオは役に立つ。しかし、利用する際には注意が必要だ。常に必要とは限らないからだ。シナリオによって、簡単だったかもしれないタスクが複雑になることはある。また、ユーザーが目を通し、覚えておく必要のある項目の数が増える可能性もある。シナリオは普通ではない、変則的な活動を正当化するのに利用されることもある。ユーザーがある活動をやりたくなる理由を長々と説明する必要があるというなら、それは現実的ではないタスクをテストしようとしているということかもしれない。
タスクのゴール：栄養指導の情報を見つけて利用する
不必要なバックストーリーが入っているタスクの例：あなたは友達を手伝うために、彼女の子ども（3歳の男の子）のベビーシッターを1週間しているのですが、子どもの健康的な食事についてもっと知りたくなりました。彼の食事にどのくらいの量の穀物を入れるとよいかを調べてください。
改善例：3歳児の食事にはどのくらいの量の穀物を入れるとよいかを調べてください。
6. タスクではなく広告を作ってしまう
マーケティング用語や業界用語をタスクに忍び込ませてはならない。「ワクワクするような新しい機能」といった宣伝文句や、「既成概念にとらわれずに」などのビジネスでよく使う言葉、社内で使っている謎の略語をタスクに入れてはならない。ユーザー中心の言語を利用し、作り手中心の言語は使わないようにしよう。オーディエンスが特定の層である場合は、専門用語やそのオーディエンス特有の言葉を使うことに意味があることもある。しかし、これは例外であり、ルールではない。
タスクのゴール：新しいソーシャルシェアリング機能を利用する
宣伝文句になっているタスクの例：迅速かつ容易に同僚と記事をシェア可能な、ワクワクするような新しい機能について調べてください。
改善例：同僚に記事を送ってください。
7. 感情的な反応を生む危険がある
参加者の母親を中心に展開するタスクを書くというのは、害のないことのように思える。しかし、調査参加者それぞれの状況というのはわからないものだ。タスクの中で特定の関係について言及することで、ユーザビリティテストで必要のない感情が生まれてしまうこともありうる。たとえば、そのタスクで引き合いに出した人と参加者の関係がうまくいっていなかったり、その人が亡くなっていたとしたらどうだろうか。ユーザーを動揺させ、タスク、あるいはセッション全体からも逸脱させるような危険を冒してはならない。参加者の快適さを保つこともユーザビリティテスト実施という業務の一部だ。代わりに、タスク内では、友達や同僚、友達の子供などの、無害であいまいな人間関係のみを利用するのがいいだろう。
タスクのゴール：参加者がどのようにプレゼントを買うかを確認する
参加者を動揺させうるタスクの例：母の日がもうすぐです。お母さんに送る花束を探してください。
改善例：友達に転職祝の花を贈ってください。
8. ウケ狙いをしてしまう
タスクでは、ふざけたり、有名人の名前を使ってはならない。また、雰囲気をやわらげようとする必要もない。それが裏目に出て、参加者がきまり悪く感じたり、下手をすると、ばかにされているように感じることにもなりかねないからである。たとえば、KellyかJesseという名前で登録してください、という指示のように、男性にも女性にも使える名前をタスクに使うことですら、タスクへの雑音になることはある。
タスクのゴール：定期購読をプレゼントするときの精算フローにある問題を特定する
邪魔なジョークが入っているタスクの例：友だちの誕生日に定期購読をプレゼントしてください。彼女の名前はIma Customer（：私がお客です）で、住所は826 Main Street in Tempe, Arizona, 85280です。
改善例：友だちの誕生日に定期購読をプレゼントしてください。彼女の名前はJen Smithで、住所は826 Main Street in Tempe, Arizona, 85280です。
9. 参加者を攻撃してしまう
誰かを不快にさせる可能性のある情報はタスクに入れないようにしよう。社会問題や政治、健康、宗教、年齢、金銭にかかわることは、すべて参加者の気分を害する可能性がある。
タスクのゴール：エクササイズやカロリーに関する情報を見つけて利用する
参加者を不快にさせうるタスクの例：あなたは1キロほどやせる必要があります。どんなタイプのエクササイズなら、余分な体重を落としやすくなるかを調べてください。
改善例：どんなタイプのエクササイズがカロリーの消費量が最も多いかを調べてください。
10. 説明ではなく質問してしまう
参加者には礼儀正しくしたいと考えているとは思う。しかし、やり過ぎは禁物だ。つまり、「どうやって（タスクを達成）するでしょうか」と参加者に質問するのはやめよう。ただし、何をするつもりであるかを詳しく彼らに説明してほしいと思っていて、実際にそのことをするかどうかは気にならない場合は別だが。ユーザビリティテストのポイントは、ユーザーが何をしているかを見ることで、彼らが何をするつもりなのかを聞くことではないからである。
タスクのゴール：インフルエンザの症状を調査する
タスクの実行ではなく、タスクについて話すように指示している例：どうやってインフルエンザの症状を調べるでしょうか。
改善例：インフルエンザの症状とはどういうものであるかを調べてください。
コツ：最終ゴールを考えることから始めよう
タスクで避けなければいけないことすべてを考えると、参加者に解いてもらわなければならないなぞなぞを書いているような気分になることもあるだろう。タスクの中に、ナビゲーションのラベルやステップ、ストーリー、あるいは、宣伝文句を入れないのというのは容易なことではない。これこそが、タスクを書くことは科学というよりも芸術である、という理由なのである。
タスクを書くのに苦労していると感じるなら、タスクの最終ゴールではなく、ユーザーの最終ゴールを考えるとよい。テストしたいセクションや機能に焦点を合わせるのではなく、なぜユーザーがそのセクションや機能を利用するのかを考えよう。最終的に彼らは何をしようとしているのだろうか。
精算プロセスをテストするなら、何かを買うというタスクをユーザーに与えればよい。また、ニュースレターの購読プロセスを見直したいなら、Eメール経由で情報を受け取るためにユーザー登録をしてください、と依頼しよう。そして、ユーザーがコンテンツを理解しているかどうかを確認するなら、コンテンツに含まれている情報についての質問が入ったタスクを書けばよい。ユーザーの最終ゴールをまず考えるようにすれば、効率的にタスクを書けるようになる。そして、今回紹介したよくある間違いがないかについて見直しをすれば、そのタスクをさらに微調整できることだろう。
タスクの書き方について、さらに詳しくは、我々のトレーニングコース「ユーザビリティテスト」にて。
