kigoulab アプリやウェブサイトをリニューアルしたとき、本当にこれで問題点が解決できたか、不安になったことはありませんか？そんなときは、ユーザテストを実施し、プロジェクトの早い段階で、実際のユーザーの意見を聞くことをオススメします。
ユーザーテストに必要なもの
一般的には、ユーザーテストには次のモノやヒト、場所が必要です。簡易的な場合は、適宜省略も可能です。
動作モック
現在公開中のアプリやウェブサイトをテストするのであれば、それを使えばよいですが、開発中のものをテストする場合、出来るだけ本番と同様に動作するもののほうがベストです。動作モックを作れない場合InVisionのようなプロトタイピングツールをつかって画面画像を操作させるのも１つの手でしょう。開発の初期段階で、動作モックが用意出来ない場合、手書きのペーパープロトタイプでもユーザーテストは可能です。モック作りに手間をかけるぐらいなら、できるだけ早い段階でユーザーテストを出来る方法を選ぶべきです。
PCまたはスマートフォンなどのデバイス
今回のテストで使うデバイスを用意します。デバイスには後述する画面記録アプリ等がインストールされている状態にします。ペーパープロトタイプの場合は不要です。
テストシナリオ
ユーザーテストで重要なのがシナリオです。被験者がつまずきそうな画面遷移を含む行動シナリオを考えます。どこから操作をはじめてもらって、最終的に何が出来ればゴールとなるのか、一通りの流れを押さえます。その上でつまずくとしたらどの画面でつまずくか、仮説や検証ポイントをスタッフ全員で共有します。ゴールは炊飯器を買う、チケットを予約するといった具体的な目標である必要があります。自由につかって感想を下さいでは、ばらばらの行動をとってしまいテストになりません。
シナリオは5分以内で終わるものだと短すぎです。また、20〜30分もかかるものだと長過ぎです。ちょうどよい時間のシナリオが予備もふくめて3つ程度あると理想的です。初心者ユーザーは熟練ユーザーの5〜10倍の時間がかかると見積もるとよいでしょう。
被験者
テストをしていただくユーザーです。最も理想的な被験者は、実際にそのサービスを使うユーザーです。モニター会社を利用して探してもらうことも可能ですが、費用がかかります。他の部署の人に応援を頼むなど、周囲にいるユーザーから、サイトのペルソナに近い人をさがすほうがコストもかかりません。通常、被験者は３人〜５人程度集められるのが理想的です。テストが終わったら、5000円程度を謝礼としてお支払いするのが一般的です。
インタビューア（進行係）
シナリオに基づいて、被験者に操作を依頼する役目です。あくまでも操作は被験者が行い、つまずいたとしても基本的に手はさしのべません。適宜、発話を誘導するために、「何故この画面で検索しようと思うのですか？」といった様な質問を適宜投げかけてゆきます。
記録係
被験者の発話や、操作上のつまずきを記録します。その他、被験者の操作で気になった点なども記録してゆきます。関係者の見学もふくめて、２名から３名程度が適切でしょう。後ほど上がってきた問題点を付箋紙に書きだし、KJ法などをつかって整理していきます。
ビデオカメラ
操作画面（スマホの場合は手元）を録画し、発話を録音します。あとで分析するときの参考資料とします。ビデオは手持ちではなく、三脚に固定した、固定カメラのほうが操作画面に集中して分析でき、被験者も緊張せずよいでしょう。
画面録画アプリ
画面操作を録画、録音するアプリです。WindowsだったらSnagitであるとか、iOSなら、Quick TimeやAir Shouといったアプリを用意し、操作画面を録画します。ビデオでも録画していますが、スマートフォンの場合、手元がわかりづらいですので、画面の動きを記録できるキャプチャー動画があるとより詳しくわかります。
発話記録用のICレコーダー
これも、ビデオのバックアップですが、固定ビデオは被験者が緊張しないよう、後方に設置するケースが多いため。画面はズームアップで録画できていても、発話記録が遠いので小さな音でしか録音されてないというケースがままあります。そのためのICレコーダーです。
テストが可能な部屋（会議室など）
ユーザーが普段、そのデバイスを使っている環境に近いのがベストです。そのような環境が用意できない場合は、周囲の音がもれ聞こえず、テストに集中できる会議室などが良いでしょう。
被験者の待合室と、案内係
被験者は時間差でテスト会場にきてもらうようお願いしますが、早めにつかれる方も多くいらっしゃいます。そのような方を待合室にご案内する案内係と、待合室があるとベターでしょう。くれぐれもテスト会場に次の被験者が入る事のないようにしてください。
ユーザーテストの流れ
被験者をテストするのではないことをお伝えする
まず、被験者をテストするのではなく、アプリやウェブサイトをテストするだということをお伝えしましょう。間違った操作をすると、自分が悪いのだと思ってしまう被験者は多くいらっしゃいます。その場合、あなたが悪いのではなく、アプリやウェブサイトの操作性に問題があるのかもしれませんね。と伝えましょう。
被験者には操作を発話してもらう
テストを始めるにあたって、操作をしながら、「どこをクリックするのだろう」「次の画面へはどう行けばいいのだろう」といったように、操作をして感じたことを発言してもらうようにしましょう。これが改善のヒントにつながります。
シナリオに基づいて、操作をしてもらう
初期画面は事前に表示しておいて、ゴールを提示してそこまでの操作をしてもらいます。あくまでも手段は伝えず、目的だけを伝えるようにします。発話が難しい被験者もいるとおもいますので、「なぜこの画面から探そうとしたのですか」といった質問を適宜なげかけて、発話をうながしてゆきます。
操作につまずいて進めなくなったらそこで終わり
操作につまずいて、次の画面へいけなくなったら、しばらく待って「わからない」と被験者が言ったらそこで終わりとします。ユーザーテストは進めることよりも、どこがわからないのかということを知ることが目的なので、わからないものはわからないままで良いのです。恐らく、操作がわからない理由をたくさん発話されていると思います。どうしても次の画面もテストしておきたい場合のみ、簡単なヒントを与えて次の画面へ遷移してもらいます。
ユーザーテストでなにが分かるのか
アプリやサイトの抱える問題点がわかる
例えば、アクセス解析で直帰率が高いページはわかりますが、なぜ直帰率が高いかまでは分かりません。ユーザーテストでは被験者がつまずきやすい個所をあぶり出すことによって、なぜここでユーザーが離脱しているのか、その理由がわかります。
アプリやサイトを使っているときの心理がわかる
アプリやサイトを使っているときの、ユーザー体験を観察することができます。操作しているときの生のユーザー体験を知ることは今後の開発に非常に大きなヒントになるでしょう。
アプリやサイトの改善点が見えてくる
ユーザーテストをしていると、ユーザーの発話やつまずきから、アプリやサイトの改善点がみえてきます。機能上の使いにくさ、情報の見つけにくさ、情報の不足といった、UI/UX、コンテンツ、情報設計上の課題を抽出することができます。
ユーザーテストは万能ではない。
ユーザーテストをすれば、ユーザビリティ上の問題点がすべて把握できるとはかぎりません。ユーザーはどうしても思い込みや、失敗したらだめだと身構えてしまう傾向にあります。専門家による、ヒューリスティックテスト（エキスパートレビュー）でないと発見できない問題点もあります。うまく兼用していくことが大切です。
長くなってしまいましたが、ユーザーテストに必要な物と、簡単な流れ、それによって得られるものをまとめてみました。用意するものでは、本格的なユーザーテストの場合を想定して考えられるものを全部だしてみましたが、カフェの片隅で、ビデオカメラも用意せず（またはスマホで代用）友達相手に、気楽な感じでテストするだけでもユーザーテストは効果的だとおもいます。
ユーザー中心設計と言う言葉があるぐらいですから、独りよがりな開発にならないよう、常日頃からユーザーの観察をしておくことが、ユーザー目線のUI/UXを実現する近道だと思います。
（担当：小山智久）
キゴウラボでは、ユーザーテストのお手伝いをお受けしております。とくに高齢者、視覚障害者を対象としたユーザーテストは、NPO法人ハーモニーアイの協力のもと、被験者の手配から、テストの実施まで、数多くの実績があります。ぜひお問い合わせください。