ナレッジknowledge

2016/10/19

【連載】高速ユーザーテスト実践講座 第8回「データ分析法(その1)」

第8回「データ分析法(その1)」

多くの場合、ユーザーテストを見学すれば、「その製品に問題がある」ことは誰の目にも明らかになります。しかし、具体的に「何が問題なのか」、そのような問題は「なぜ起きたのか」を明らかにするためには、観察データを冷静に分析する必要があります。
 

ポストアップ

 
ユーザーテストでは観察によって主に定性データ(質的データ)が得られます。
●ユーザーの自然な行動
●インタビューアが引き出したユーザーの発話
●見学者の「目と耳」に焼きついた事実
 
これらのデータをビデオ録画と突き合わせて詳細に検証しようとすれば、膨大な時間がかかってしまいます。そこで、高速ユーザーテストでは、原則として見学者の記憶に依存して分析を進めます。ただし、人間の記憶は時間経過とともに急速に変化・減衰するので、なるべく早くデータの“見える化”をします。
 
すべてのセッションが終わってから観察メモを統合しても構いませんが、どんどんカード(付箋紙)に書き出しながら、ホワイトボードなどに貼り出して(ポストアップ)いった方が効率も精度も上がります。他の見学者の視点に触発されるからです。
 
IMG_1003
ポストアップの例
 

観察カードには見学者の自由な視点で観察した事実を書き出して構いませんが、間違った方向に議論を進めてしまわないためのポイントが2つあります。
 
①“気づき”ではなく、実際に観察した“事実”を書き出す── 「使いづらそう」というのは見学者の主観的な評価結果です。「(ユーザーは)編集メニューの選択に戸惑った」というのが観察した事実です。つまり、後でビデオを再生すれば、ユーザーが「○○している」「××と言っている」という場面を確認できるような内容です。
 
②“ユーザーの視点”で記述する── 例えば、「戻るボタンがない」というのはユーザーの視点ではありません。ユーザーは戻るボタンを使いたいのではありません。単に「前の画面に戻りたい」だけです。つまり「(ユーザーは)前の画面に戻れない」と書くべきです(なお、ユーザーの視点で記述すると自然と「ユーザーは~」で始まる文章になります)。
 
なお、重要な点で見学者間の記憶に相違が生じた場合は、まずインタビューア(モデレータ)に確認してみましょう。インタビューアはユーザーの間近で観察しているので、見学者よりもユーザーの行動と発話を詳細に記憶していることが多いからです。もしインタビューアもよく覚えていない場合は、ちょっと手間はかかりますが、該当箇所のビデオを再生して全員で確認します。
 

マッピング

 
すべてのセッションが終了して観察した事実を一通り書き出したら、タスク単位、画面単位でデータをまとめていきます。その際に、プロジェクタで実際の画面を投影したり、印刷した画面を壁に貼り出したりして、画面と観察データの対応づけ(マッピング)を行うと理解が進みます。
 
特に印刷した画面をワークフローの順番に壁に掲示して、それぞれの画面の該当箇所にカードを貼りつけると、テストで観察した複数のユーザーの行動を改めて俯瞰できるようになります。個別のユーザーの行動が重なり合って、この製品を使用する際のユーザーの一般的な行動パターンが浮かび上がってくるのです。
 
さらに、カードそのものがインスピレーションを与えてくれます。例えば、ある特定の画面にカードが集中していれば、問題の所在は明らかでしょう。また、全体的に見ると画面の下部にカードが多かったり、タスクは異なるのに同じレイアウトの画面にカードが多かったりすることに気づくかもしれません。これは問題の根本的な原因を突き止めるための重要な手がかりになります。
 

タスク達成状況

 
問題点をリストアップしたら、次はタスクの達成状況を評価します。そのユーザーはそのタスクをどれくらいスムースに完了できたと言えるでしょうか?──私は以下のような 3 段階で評価しています。
 

ユーザーは独力でタスクを完了し、無駄な操作や混乱が少なかった場合。
ユーザーはタスクを完了したが、無駄な操作や、操作中に戸惑いが見られた場合。
また、比較的強い不満を述べた場合も含む。
× ユーザーは独力ではタスクが完了できなかったと考えられる場合。


 
この評価はあまり厳密なものではなく、分析者の主観をかなり取り入れています。問題点を抽出する時は、かなり細かい問題もリストアップするので、問題がひとつも見つからないタスクは非常に少数です。しかし、それでは「〇」のタスクがなくなってしまい、評価結果にメリハリがつかなくなってしまいます。「すべて△」という結果を出すのならば、わざわざ三段階で評価する意味はありません。
 
そこで、軽微な失敗や戸惑いがあっても、ユーザーが独力ですぐエラーから復帰して、タスク実行プロセス全体とすればスムースに完了できていたと言えるのであれば「〇」の評価を与えるようにしています。そのため、全員が「〇」のタスクであっても、問題点を指摘することがあります。
 
このタスク達成状況を一覧表形式にまとめれば、テスト結果が一目瞭然になります。
 
IMG_1013
タスク達成状況一覧表の例
 

81vCozoDHzL._UX250_
【著者紹介】
樽本 徹也(たるもと てつや)
利用品質ラボ代表。ユーザビリティ工学が専門で特にユーザ調査とユーザビリティ評価の実務経験が豊富。著書は『アジャイル・ユーザビリティ 』 『ユーザビリティエンジニアリング(第2版)』(いずれもオーム社)など。
認定人間中心設計専門家、認定スクラムプロダクトオーナー。産業技術大学院大学「人間中心デザイン」講師。

>>第1回「ユーザーテストとは」
>>第2回「ユーザーテストの大原則」 
>>第3回「ユーザーテストの基本理論」 
>>第4回「ユーザーテストの実施手順」 
>>第5回「リクルートのコツ」 
>>第6回「タスク設計法」 
>>第7回「観察テクニック」 

 

************大好評!ダウンロード資料公開中************

▼「高速ユーザーテスト実践ワークショップ」レポート▼

pic_download02

お問い合わせ

ユーザーテストのお問合せは下記からお願いします

電話でのお問い合わせ/053-545-5105(月〜金/9:00〜18:00)