ユーザビリティテストを行う際の基本原則の１つは、ソフトウェアやアプリ、Webサイトを被験者に使ってもらうことでサービスの問題を知ることです。
サービスの使用場面を再現することで、実際のユーザーが離脱してしまう問題や製品を他者に勧めなくなったりする問題を突き止めて修正することができます。
さて、黙ってユーザーを観察するべきと言われていますが、ファシリテーターはユーザーに干渉する必要があるのでしょうか？ 私が言いたいのは、ユーザーがタスクに行き詰まり先に進めない状況について、ファシリテーターは何をすべきかということです。
ユーザビリティテストを実施した私の経験上、テスト中に被験者を手助けするかどうか、手助けするタイミング、手助けしたテストのデータの扱い方という問題については常に議論が絶えません。これにはもっともな理由があります。被験者を補助するという考えは、ファシリテーターやプロダクトマネージャー、エンジニアの手助けなしに製品を使用してもらうというユーザビリティテストの第一の目的に矛盾しているように見えるからです。
ここでは、ユーザビリティテストにおいて補助が必要なタイミングを判断するときに考慮すべき10の項目を説明します。
これらは、MeasuringUでの体験および、Joe Dumas氏とBeth Loring氏の素晴らしい著書『Moderating Usability Tests』、Tedesco氏とTranquada氏の『Moderator’s Survival Guide』から引用しています。
１. ユーザビリティテストの補助とは
ユーザビリティテストの補助とは、テスト中にファシリテーターが介入して被験者を手助けし、タスクの完了に導いたり進行をうながしたりするものです。
たとえば、ユーザビリティテストのタスクとして、被験者が買い物かごにパーカーを追加するように指示されたとき、サイズの選択が必要なエラーメッセージが下図のように小さく、気付けず先に進めない場合などがあります。最終的にファシリテーターは、タスクの次のステップに進むためには色とサイズを選択する必要があると指摘しなければなりません。
２. 補助する目的
タスクや調査の早い段階で被験者が行き詰まる場合、調査の中で、もし補助がなければわからなかっただろうユーザビリティの問題が後々明らかになることがあります。
さらなる問題の発見やより多くのデータ収集というメリットが、タスクの典型的なデータではなくなる可能性があるというデメリットに勝らなければいけません。パーカーの例では、被験者に先へ進む方法を教えることで、買い物かごのぺージとそこでの体験に関するより多くのデータを集めることができます。
３. 補助することを恐れない
ファシリテーターが最初に学ぶのは、被験者をタスクの完了に導いたり、セッションを実演にしたりすることではありません。一般的に、人は誰かが苦戦しているとき助けたいと思うものなので、干渉しないようにするのは非常に難しいかもしれません。
しかし、干渉が本当に必要な場合もあるので、補助の準備をしておくことが重要です。いつ介入すべきなのかは一概には言えません。介入が必要なタイミングには、共通する兆候がいくつか存在します。次の章で説明します。
４. 補助するタイミングを知る
待つべきか介入すべきかを知るには練習が必要です。被験者を補助すべきタイミングの目安は以下の通りです。
- 被験者が本当に苦戦している：被験者が何度も手こずったり、同じ間違いを犯している場合を指します。同じ体験を無限に繰り返させる意味はありません。ただ、苦戦している最初の兆候で飛びついてはいけません。被験者が本当に自力で前進できないのかどうか確かめましょう。
- 時間切れ：ユーザビリティテストの時間は限られています。被験者が１つのタスクに時間をかけ過ぎてほかのタスクやスクリーン、調査部分に取り組めなくなる場合には、補助が必要です。
- きわめて悲惨な事態：被験者が行動を続けることで、システムをクラッシュさせたり、データを消去したり、知らず知らずのうちにクレジットカードで購入したりするなどの問題が起こりうる場合は、介入する必要があります。
- すべてのタスクが終了していない：被験者はときどき、実際はすべてのタスクを完了していないのに、タスクを達成して次に進めるようになったと勘違いすることがあります。このようにタスクが未完了の場合は、介入して、被験者にほかの選択肢がないか考慮してもらう必要があります。
５. 慎重に補助する
テストに補助が必要なときがある一方で、補助する回数は最小限にする必要があります。調査の中で補助する回数が多いと感じたら、タスクや調査をデザインし直すことを考えましょう。実験者がどの調査でも補助することが多い場合には、タスクのうながし方を見直し、補助する回数を減らす方法を模索しましょう。
６. 補助したことを記録する
被験者を補助しなければいけなかったかどうか、何回補助したのか、なぜ補助したのかを記録しましょう。補助の頻度や原因を知るだけで、ユーザビリティの問題を解明し、テストのプロトコル（調査のプロトコル、タスクの指示、テストされたソフトウェアの問題など）を改善できるかもしれません。
７. 補助する場合としない場合のタスク完了を記録する
補助したことを記録するとき、補助した場合としない場合のタスク完了率をどのように記録するのか選びましょう。組織によっては、補助ありのみ、補助なしのみ、あるいはその両方の完了率を記録するように方針を立てていることもあります。補助しない場合の完了率は、定義上、補助した場合の完了率より低くなります。最低限のタスク完了率を満たす必要がある場合などでは、データの結果によって、補助した場合のタスクの完了率を記録すべきかどうかは議論がわかれるでしょう。
８. すべての介入が補助ではない
被験者がタスクを実行しているとき、ファシリテーターの介入が必要な場合がありますが、そのすべてがタスクの完了を補助しているわけではありません。補助に当たらない介入には以下のようなものがあります。
- タスクの指示を明確にする、タスクを繰り返し説明する
- 被験者が考えを述べるのをうながす
- ソフトウェアのバグやコンピューターの故障などの技術的な問題から被験者が立ち直るのを助ける
９. 補助には段階がある
Dumas氏とLoring氏は、以下のように、介入度合いによる４つのレベルで補助することと、そのレベルごとに記録することを勧めています。
- タスクを読み直したり、ほかの選択肢を検討するよう被験者にうながすことで、繰り返しの行動を止める
- 必要な情報は既に画面上にあることを被験者に伝えるなど、抽象的なヒントを与える
- 必要な機能はメニュー項目の下や次の画面にあることを被験者に伝えるなど、具体的なヒントを与える
- 被験者に何をすべきか伝える、それでも駄目なら、特定のボタンをクリックすることを被験者に教えたり、ある要素に誘導したりする
10. 注意をそらして補助する
直接補助されると、被験者は気分を害する場合があります。双方にとって不愉快な状況を最小限に抑えるには、Tedesco氏とTranquada氏が言及している、被験者の注意をそらして補助する方法があります。注意をそらして補助する際は、被験者が現在取り組んでいることを中断させ、前のタスクの中で述べた機能など、関係のないことを尋ねましょう。被験者が質問に答えたら、行き詰まっていたタスクを再開してもらい、たとえばレベル４の補助として、気付かなかった機能をクリックして先へ進むようにうながします。
