ユーザーテストを実施してのまとめ

会社の制度を使って、4月から通っているUI/UXのスクールでは、開始当初からチームに分かれてモバイルアプリを作成しています。

そのアプリを元に実際にモニターを迎えて、ユーザーテストを行なったのでまとめておこうと思います。

ユーザーテストのプロセス

今回、行ったユーザビリティテストとは、ユーザーに課題（タスク）を行ってもらい、その様子を観察してエラーや課題を評価するものです。

本来であれば、
1.計画（実施概要・モニタ条件）
2.準備（リクルーティング、質問内容、スクリプト、プレテスト）
3.実施（会場設営・インタビュー実施、デブリーフィング）
4.分析（モニタ毎の分析、質問項目の整理、事象に対する要因を考察）
と行うのですが、
授業では、講師に用意していただいたユーザーに対して
・タスクを提示して、それを横で観察する
・モデレーターが会話を進め、観察者が記録を取る
の2点を重点的に行いました。

準備したこと

■スクリプト作成
進行役を務めるモデレーター用にスクリプトが必要になります。簡単に言うと司会者の台本のようなものです。
ざっくりまとめると以下のようになります。（実際のものはもっと内容を細かく記載してあります。）
---------
1-イントロ
・挨拶
・個人情報保護について
・このインタビューがどのように進められるかの説明
2-事前インタビュー
・アプリの説明
・事前アスキング
（年齢・使用アプリ・使用頻度・アプリに関する範囲での質問）
3-事前説明
・今回のテストの目的
・開発途中の試作品で操作することの説明
・タスク説明（いくつのタスクを行ってもらうか）
・操作がうまくできなくてもあなたは悪くないんだよという説明
・基本的に、一人で操作してもらうよという説明
・それぞれの操作が終わったら教えて欲しいことを説明
4-タスク実行観察
・タスクの数とそれを1つずつ行ってもらうことの説明（タスクは1つずつ紙に印刷して、操作前に1つずつ提示する）
5-事後アスキング(デブリーフィング)
・操作を振り返ってどうでしたか
・気になる箇所ありましたか
・この操作のときは・・・でしたけどどういったことをされたのですか。(テスト中のメモを元に質問)
などの質問をまとめる
6-クロージング
---------

■タスク設計
ユーザーに行ってもらうタスクのゴールを設定します。
スタートからゴールにユーザーが到達できるかを評価します。

作成するタスクは、ユーザーにこういうことを聞いてみたい、ユーザーはここをどうやっているのか知りたいという点から作成していきますが、基本的にオープンクエスチョン（クローズドクエスチョンを避ける）で作成していきます。タスクはスタートとゴールが明確なものにしていく必要があります。

OK例：
会員登録してみてください。
商品を購入してみてください。

NG例：
ヘルプを使ってみてください（動作や機能の話）
＝ヘルプを使って何をするかをタスクにする

テスト実施

テスト実施の際はモデレーター、記録者が各1人ずつ担当します。
テストユーザーの隣にモデレーターが座り、記録者はモニタの視界に入らないようにします。複数の記録者がアイル場合は別室で外部スクリーン等で観察します。

モデレーターは以下のことに気をつけながら進行していく必要があります。

モデレーターのマインドセット

・否定はせず徹底的に受け入れる（受容の姿勢）
＝否定されると発話を控えたり、本来の意図を曲げた答えが返ってきてしまう。

・仮説にとらわれずに観点を広く持つ
＝仮説にない重要な発見を見逃してしまう可能性がある。

・ユーザーの発言を真に受けない
「・・・が欲しい」と言われたら、「じゃー、機能追加しますね。」ではなく、一旦受け止めてその意図を聞いていく。
＝欲しいと思った背景を探るためにその意図を深く聞いていく。

・個人を追求する
ユーザーテストで欲しいのは「問題なく操作できた」「〜でつまずいた」という事実なので「自分は大丈夫だと思うんですけど、高齢者の場合は・・・」などといったモニター本人以外の話は不要。

・ユーザーの話しやすい雰囲気を作る
PCでスクリプトを確認しながら進める際は事前に断りを入れる。

モデレーターのテクニック

モデレーターのマインドセットの他に、以下のテクニックも心に止めておく必要があります。

・平易な言葉を使う
専門用語は使わない、カタカナ用語は使わないなど、ユーザーのわかりやすい言葉で話を進める

・間違えた操作をすぐに中断しない
例え、操作がこちらの意図するものと違っていたとしても、様子を見ながら「今何をされていますか？」と行動の意図を探る。

・質問は質問で返す
質問に対して答えを与えてしまわない。
例：このボタンを押すとどうなりますか？→どうなると思いますか？

・オウム返しをする
ユーザーが発した言葉をそのまま繰り返すと、それを聞いたユーザーが話を展開してくれる。

・自信なさげな言葉尻を拾う
ユーザーの自信なさげな言葉はユーザーの気持ちを表している。そこから話を展開してみる。

・オープンクエッションを多用する
「はい・いいえ」で答える質問ではなく、ユーザーが自由に発話できる質問を投げかける。

・理由を直接聞かない
なぜ？と聞かれるとすぐに理由を答えられず、理論的に正しい回答を考えてしまう。

・沈黙の意味を考える
いろいろな沈黙があるのでその意味を考え答えを促すような質問をする。

記録者のテクニック

記録でもたつかないように、分かっている質問は記録表に事前に記入しておく、わかりやすい記号で記入の手間を省略するなどのテクニックを用いって記録をスムーズに進めていく必要があります。

分析（事象に対する要因を考察する）

分析は見つかった問題点をリストアップすることから始まります。
発生した問題の頻度を数え、問題点に優先度をつけます。
そこから、問題（事象）の要因を考察し、分析結果から改善の方向性を検討します。

まとめ

今回、私は記録者として参加しました。
とにかく記入のスピードと簡潔にまとめる力を求められる役割でした。
しかも、テストを観察し、記入しながら、事後アスキングに聞く話もまとめておく。。。というやることが盛り沢山な状況にテンパり、モデレーターのテクニックとしてあげられている「理由を直接聞かない」をやってしまうという失態を。。。

自社でも数年前にユーザーテストを行ったことがあったのですが、今回のようにがっつり参加するタイプのものではなかったので、改めて参加してみて、仕組みがよくわかりました。

もともと、テンパりやすいタイプなので、事前の準備をしっかりしないとなと反省の多い実施となりましたが、とてもいい経験になりました。