ユーザーテストはこうやります

なんとなくユーザーテスト（ユーザビリティテスト）について、あらためてまとめてみようか、と。

まず昨日も「ユーザー調査とユーザビリティ評価の違い」で書きましたが、ユーザビリティ評価としてのユーザーテストにも大きく分けて2つの手法があります。

  • 総括的評価：定量的な評価で、品質の“測定”が目的。大サンプルに対して、一斉に実査を行う会場テストを実施。
  • 形成的評価：定性的な評価で、品質の“改善”が目的。小サンプルに対して、1対1のテストを実施。

昨日も書きましたが前者はパフォーマンスを測るもの、後者は具体的に現状のデザインのどこに問題があるかを発見し、改善を図るためのものです。

人間中心のデザインを行う上で意味があるのは、形成的評価のほうで、多くの場合、ユーザーテストというのはこちらを指すケースが多いと思います。

形成的評価の2つのユーザーテスト法

また、1対1で行う形成的評価のユーザーテスト法にも2つの手法があります。

  • 思考発話法（think aloud法）：被験者にタスクを実行してもらいながら、タスク実行時の認知過程をその都度発話してもらう手法。行動と発話を観察、記録、分析する。
  • 回顧法（retrospective report法）：被験者には思考発話法同様にタスクを実行してもらうのは同じだが、発話は行っても行わなくてもどちらでもよい。質問はタスク終了後に行う手法。主に行動を観察、記録し、事後の質問への回答とともに分析する。

僕はどちらかといえば思考発話法のほうでテストを行うことをおすすめします。もちろん、ユーザーに発話をうながすのはなかなか大変だったりしますが、きちんとプロトコル分析を文脈にそって行いたい場合は行動と発話があらかじめセットになっている思考発話法のほうが正確な分析が可能だと思うからです。

回顧法にも「分析が簡単」だったり「他の手法と併用も可能」だったりという利点もありますが、「複雑な状況はユーザー自身も回顧がむずかしい」「ユーザーが後付けで理由をつくってしまう」などのデメリットもあります。

ユーザーテストの手順と概要

ユーザーテストを実施する際の手順は大まかには次のようになります。

  • テストの目的の明示
  • 被験者リクルート：リクルート条件決定、スクリーナ作成、被験者募集、被験者決定後の実査までのフォロー
  • テスト設計：タスク設計、インタビューガイド作成、実査のための準備、パイロットテスト実施
  • テストルームでの実査：受付、イントロダクション、事前説明＆インタビュー、タスク実行観察、事後インタビュー、エンディング
  • 分析・レポート：デブリーフィング、プロトコル作成、プロトコル分析、評価レポート作成、改善のためのブレインストーミング実施

まず、リクルートですが、これは実際にデザインされたものを使うターゲットユーザーを被験者として呼ぶことが重要です。先に上流工程でペルソナを作成していれば、ペルソナのプロフィールに近い人を被験者のリクルーティング条件にするとよいでしょう。

被験者の数は、そもそも人間中心のデザインでは反復デザインが有効なので、15人を対象に1回やるよりも、5人を対象に3回やったほうがベターです。
この5人という数字に関しては、ヤコブ・ニールセンが被験者5名で85%の問題を発見可能といっています。リクルーティングの際には、異なる条件のグループごとに5名ずつ被験者を集めるとよいでしょう。

大事なのはテスト設計です。
これに関しては前に「ユーザーテストはテスト設計が大事」というエントリーでも書いていますが、実査でユーザーに与えるタスクがそもそも実際のユーザーの現実の利用状況に見合ったものでなかったりすると、本当の問題点を見つけられずにテストをやった意味がないなんてことにもなりかねません。

タスクは「ボタンを押してください」とか「ヘルプを使ってみてください」などと具体的な機能名で指示を行うのではなく、ユーザーが実際にある目的を達成するためにタスクを行うのだというイメージがしやすいよう、「夏休みに旅行に行くので予算○円以内のツアーの予約をしてください」などの形で指示ができるようインタビューガイドを作成します。

実査において留意すべきこと

ここまできちんとリクルーティング、テスト設計ができていても、実査の時点ですべてが台無しになってしまうことがあります。

それはユーザーテストをインタビューと勘違いしてしまうことです。
ユーザーテスト法ではユーザーの声を聞くのではありません。ユーザーの行動を観察して問題点を発見するのです。

よくユーザーテストでいろいろ質問したり、どう間違ったのか「使いやすかったですか？」とか「印象はどうですか？」などと聞いたりするテスターがいますが、そんなの訊いてデザインをどう改善できるんだろ？と不思議に思います。

ですので、インタビューガイドに従い、タスク実行の指示を正確に出した後はユーザーにゆだねなくてはいけません。

質問しない、質問に答えない。質問されたらおうむ返しをする（被験者：「これを押せばいいのかな」、テスター：「これを押せばいいんですかね」など）。

そして、「今は何を考えてるんですか？」「次はどうしますか？」などと発話を促し、その間も常にユーザーと画面から目を離さないことが大事です。アイトラッキングツールなどを使ったユーザーテストなどでよくある間違いはテスターがアイトラッキングツールが表示する視線の軌跡を追いかけてしまい、それより大事なユーザーと画面のあいだのインタラクションを無視してしまったりすることです。それではあとでプロトコル分析をするのもむずかしいはずです。

大事なのはあくまでユーザーの行動の観察からデザインの問題点を抽出することです。
20代の男性はこういう風に使う傾向があるとか、ユーザーの評価をしてしまう人もいますが、それはユーザーテストの目的じゃありません。そういうのは昨日も書いたとおり、ユーザー調査でやるべきで、ユーザーテストで評価するのはユーザーではなくデザインのほうです。

実査後の分析、改善のためのブレインストーミング

実査を行ってユーザーテストは終わりではありません。
そもそもデザインの問題点を発見し、改善を行うのがテストを行う目的ですから、そこまでもっていけてはじめてテストは終了になります。

まずはテスト後には各ユーザーの行動と発話をプロトコルに書き起こします。書き起こしたものを認知科学の分野でも行うプロトコル分析にかけます。
そこで現状のデザインのどこに問題があるかを抽出するわけですが、その際も問題点は「戻るボタンがない」という書き方をするのではなく「前に戻れない」というユーザーの行動の視点で書くことが大事です。
これは先のテスト設計の場合でもそうですし、ペルソナを使ったシナリオを書く場合でもそうですが、人間中心のデザインを行う場合の基本的なメソッドです。

こうした問題点を抽出したレポートを元に、改善のためのブレインストーミングを実施するわけです。
会議じゃなくブレストなのは目的が「結論を出す」ことではなく「アイデアを多く出す」ことだからです。まぁブレストのコツに関しては「ブレインストーミングの7つの秘訣」を読んでいただいた方が参考になるか、と。

と、ここまで改善案のリストづくりまでできた段階でユーザーテストの完了となるわけです。
とはいえ、ユーザーテストはあくまでデザインプロセスの一部です。
これで終わったわけじゃないというのもお忘れなく。

　

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック