ユーザーテスト設計

解決策が出来上がった段階で、ユーザーテストの実施について検討する。基本的に検証したい論点がある場合に実施するが、テストを実施しないことで起こり得るリスクを許容できる場合は実施しないこともある。また、サービスや製品を使ってもらい、ペインポイントの傾向を掴むパターンもあるだろう。

ここでいうリスクとは、UIがわかりづらいためにお問い合わせが増えることなどである。

テストを行う際、用いる手法はユーザーインタビューが主力である。可能であれば観察と併用すると良い。やることはシンプルで、実際に動くプロトタイプを用意し、ユーザーの方に触ってもらい率直な意見を聞く。順を追ってポイントを見ていこう。

＜テストの実施の判断から調査計画の流れ＞

検証したい論点を洗い出す
ユーザーテスト実施の判断
被験者の選定基準を検討
シナリオを用意する
トークスクリプトを用意する
協力依頼
プロトタイプの準備

検証したい論点を洗い出す

課題をきちんと解決できているのかが一番の論点であろう。実際のデザイン案を持参し、こんなデザイン案の場合、〇〇（課題）は解決されますか？と聞きにいくことを想像してほしい。また、これに付随してデザイン案を世の中に出した場合に論点となるのはどんな部分であるかを考える。要するに心配な点や確信を持てていない点、懸念される点である。

導線に気付けるか？
あしらいや設計に違和感がないか？
アイコンやワーディングの意味がわかるか？
操作の仕方がわかるか？
実際の利用シーンを想定した場合の操作性に問題がないか？

合わせてこれらの点が検証できない際に考え得るリスクについても簡単に考えておくと良いだろう。

ユーザーテスト実施の判断

検証したい論点とリスクを洗い出したら、リスクやコストなどビジネスの観点も含め総合的に実施の判断をする。テストを実施しないのであればそのリスクを誰が負うのか責任の所在も明確にしておくと良い。

被験者の選定基準を検討

ここからは、具体的な調査計画に入っていく。まずは誰に触ってもらうか？を決める。検証したい論点を検証できる人に聞けば良いが、基本的には案件における課題感を強く持っている人が良いだろう。あまり難しく考える必要はなく、デザイン案を先方や上長、投資家などにプレゼンするとしたら、どんな人から意見をもらえれば納得感のあるプレゼンテーションになるかを論理を持って考えれば良い。

また、テストに協力してもらう人数は3~5名程度で良い。これはユーザビリティの専門家であるヤコブ・ニールセンが提唱しており、3名の調査でUIの問題点の約70％、5名の調査で約80％以上を発見することができるとしている。

Why You Only Need to Test with 5 Users をもとに作成

シナリオを用意する

続いて検証したい論点をどうすれば検証できるかを考える。これは、実際に課題が発生している一連のタスクを行ってもらうのが良いだろう。被験者の方に一連のタスクを行ってもらうためにシナリオを用意する。次のような具合だ。

Q. 〜〜という場面で、〜〜をしたいと思っています。行ってみていただけますか？

この時、事前に「どういう結果が得られたらどうするのか」を考えておくと良い。また、デザインパターンを触ってもらった場合に言われそうな指摘事項を事前に考え、指摘された場合に見せる代替案も作っておくと良い。簡単な例で言うと、「アイコンが何を意味しているかが伝わるか」というテストを行い、「わかりづらかった」と指摘される可能性も考えられるので別のアイコンにしたパターンも作っておく、という具合である。

トークスクリプトを用意する

シナリオが出来上がったらそれを踏まえ、今度は訪問した時点から事前ヒアリングやテストの実施、事後ヒアリングまでを含めてユーザーテスト全体のトークスクリプトを作っていく。なお、シナリオと同時に作っても良いし、順序は問わない。

スクリプトを準備する主な目的は、全ての被験者の方に同じテストをするためと聞き忘れを防ぐためだが、テスト当日の流れも確認できるので時系列で所要時間なども考慮しながら作ると良い。

なお、スクリプト通りにやるにはやるが途中で話が脱線することは構わない。思いの外そういった何気ない会話からヒントが得られることもある。また、思ったことを何でも言ってもらえる環境作りにもなる。空けてもらっている時間も見ながらではあるが、脱線し終わったところでまたスクリプトに戻れば良い。

テストの趣旨をわかってもらうことも大事で、「これから見せる画面ではデザインが変わっており、デザインが変わった場合にも問題なく操作できるかを見させていただきたいと思っています。」などと事前に伝えると良い。

協力依頼

被験者の選定基準が決まり、トークスクリプトを作成しおおよその所要時間がわかったところで順次協力依頼をする。電話番号がわかっていれば電話が手っ取り早いだろう。（個人情報の使用ポリシーに製品の改善のために使用することがあるという旨が書かれているかは注意が必要だ。）その他、メールやSNSなど手段は問わない。

プロトタイプの準備

テストに使用するプロトタイプを作る。iPhoneアプリであればiPhoneで動くプロトタイプが好ましい。可能な限り実際のシーンと同じ状況を作る。

ページの構成の確認や画面遷移くらいしかインタラクションがない場合は InVision で作ると良い。さらにリッチな挙動を作る場合は Protopie がおすすめだ。おおよそ全てのインタラクションを実装でき、操作もそこまで難しくなく、学習コストが低い。

テストするパターンは参考値ではあるが〜3つ程度準備し、すぐにそれらを行き来できるようにプロトタイプを作っておくと良い。