日頃UIデザインをつくっていて、「そもそもこのUIやフローで、ユーザーに価値を提供できるのか。使いづらくて不快感を与えないだろうか。私たちが考えた仮説はどれだけ的を得ているのか。もしかしたら、ただの自己満足な妄想なのかもしれない。」...なんて思ってたりする。

最近ユーザーインタビューをする機会が増えてきたので、今回はユーザーと直接関わりながら、プロダクトを検証・改善をしていくアプローチについて考えてみます。

1. ユーザビリティを評価する

UIデザインの役割を「ユーザーがゴールに到達するまでの道のりをスムーズに導くこと」とするのであれば、それを測る手段としてユーザビリティ評価というものがあります。

ここで取り上げている「ユーザビリティ」は、

特定のコンテキストにおいて、特定のユーザーによって、ある製品が、特定の目標を達成するために用いられる際の、効果、効率、ユーザーの満足度の度合い

とします（参考：ISO 9241）

この「特定の」ユーザー、利用状況、目標を定義してから、効果・効率・満足度という観点を用いてプロダクトの質を評価する手法がユーザビリティ評価とされています。

・効果：ユーザーが目標に達成できるかどうか
・効率：ユーザが目標を達成できるとして、その間に無駄な手順を踏まず、なるべく最短経路で目標を達成できるかどうか
・満足度：ユーザーに不愉快な思いをさせていないかどうか

（引用：ユーザビリティエンジニアリング ―ユーザエクスペリエンスのための調査、設計、評価手法―）

2. ユーザーテストとは

ユーザビリティ評価のやり方は色々あるのですが、その中でもユーザーが直接参加して行っていくものはユーザーテストに区分されます。

ユーザーテストとは、ユーザーにあるタスク（作業課題）を提示し、その実行過程を観察していくスタイルのリサーチ手法になります。
実際にユーザーがプロダクトを使っている様子を観察することで、仮説を検証したり、改善点を発見しやすくなります。

3. ユーザーテストのやり方

ユーザーテストの実施手順は大きく5ステップ

（参考：Web制作者のためのUXデザインをはじめる本 ユーザビリティ評価からカスタマージャーニーマップまで）

①計画

まずは、なぜユーザーテストが必要なのかといった理由、目標をはっきりさせていきます。このゴール設定があやふやだと、その後の評価設計や分析にも影響してくるので、できるだけ明確にしていきます。

ゴールや目的が固まってきたら、そのユーザーテストで呼びたいユーザー像（簡易ペルソナ）を作成し、リクルーティング（テストユーザー集め）の手配をします。

リクルーティングでは、希望スケジュールや場所の叩き台を作っておいて、協力してくれそうな人にサポートをお願いすると良さそう。

②評価設計

「ユーザーがどんな状況でプロダクトを使って欲しいか（利用状況）」を考えていきます。ここでユーザーにとって自然な状況を描く際に、過去のUser Researchで得た情報や気づきがじわじわ参考になったりします。

タスク設計

ユーザーテストのときに、実際にユーザーにやって欲しいタスク（作業課題）をかためていきます。

・主要なタスクに絞り込む：優先度の高いものを選んでシンプルにする
・ユーザー視点で発想する：主観的なビジネスゴールではなく、ユーザーがやりたいことで考える
・スタートとゴールを定義する：ユーザーがタスクを達成できるかを判断するための着地点（ex. アカウント登録完了画面）
・シナリオ化する：ユーザーがリアリティを感じながら機能を使える状況を提示する

良いタスク例：
「あなたは明日13時に新宿で、友人とランチにいくとします。会社のミーティングの都合で、12時集合に変更したいと思います。このスマホを使って、SNSで友人に変更時間を連絡してください。」

いまいちなタスク例：
「このアプリを適当に使ってみてください。興味があればマップ機能から店舗アイコンをタップして、洋服を買ってください。」

たくさんやりたいことは出てくるかもしれませんが、あれこれ盛り込みすぎると私たち自身もユーザーも分かりづらくなってしまうので、ゴールに向けてシンプルで一貫したタスク設計にしておいたほうが良さそう。

観察ポイント

テスト実施中に、どこをチェックしておくべきかを予め決めておきます。リストにして書き出すことで、仮説がより具体的になり、チームメンバー同士で知りたいポイントの意見交換がしやすくなったりします。

③事前準備

必要であれば、記録用備品（ボイスレコーダー＆カメラ）、NDAや個人情報の同意書、謝礼などを用意します。私の場合、進行スケジュールや観察ポイントをすぐに確認＆記録ができるよう、紙に印刷して持参しています。

ユーザーテスト当日は、進行・観察・記録など色々やることがあるので、複数名で協力しあうチームプレーが大切になってきます。
自分以外のメンバーが、当日の流れ・時間配分・環境づくり・タスク・観察ポイントが把握できるようドキュメントにまとめて、口頭で説明しておいた方が良さげ。

④テスト実施当日

事前インタビュー

いきなりユーザーテスト開始！大観察！ではなく、まずは自己紹介をしたり、なぜ今日はこうゆう場を設けたのかという概要説明をしつつ、タスク実施につなげる質問を投げかけていきます。

はじめは初対面同士で「お前誰やねん。これから何すんねん？」といった疑心暗鬼な雰囲気になりがちなので、相手に安心感を与えられるようなコミュニケーションをして、場を和ませていきます。

タスク実施

ユーザーにタスク（作業課題）を伝えて、実行してもらいます。
タスクを伝える際には、そのユーザーにとっての利用状況が想像しやすいような表現や単語を用いた伝え方をしていきます。

タスク実施中は、観察に徹して、こちらから話しかけることは控えるようにします（思考発話法の場合は除く）

目の前で起きている行動と事実をみながら、「どこでなにが起きたのか」「ユーザーはどんな反応・言動をしているのか」「ユーザーはどうやってタスクを達成したのか」を観察していきます。

事後インタビュー

ユーザーがタスクを終了したら、やってみた感想を聞いてみます。その後は満足度や改善要望にまつわる質問などを投げかけてみます。

⑤分析

問題を洗い出す

各画面・操作ステップごとに、気になった問題点を書き出します。
「ユーザーがそのタスクをどれぐらいスムーズに完了できたか（タスク達成状況）」を3段階で評価していくと、各ユーザーの結果を一覧で比較しやすくなるため、俯瞰的にバランスよく分析する手助けになったりします。

問題を優先度別に分類する

問題が出てきたら、次は「どの問題の対応優先度が高いか」を判別していきます。問題の質（効果＞効率＞満足度）× 発生頻度という観点で分析していきます。

Step1：各問題を「効果・効率・満足度」にカテゴリ分けします
Step2：各カテゴリ内で発生頻度が多い順に並び替えます
Step3：効果が大きい＆発生頻度が高い問題＝優先度が高い改善点になる

こうした検証・分析方法を用いることで、その機能の改善点や対応優先度が明らかになっていきます。

（参考：サービス改善の成功率を8倍まで引き上げるユーザーテストの作法）

4. 小規模な再テストを繰り返す

ユーザーテストを企画する際、一体何人やっとけば大丈夫なのか、どこまでチェックしたらいいのかと不安になったりします。

ヤコブ・ニーセンのWhy You Only Need to Test with 5 Usersによると、

・5人のユーザーでテストすれば、ユーザビリティ問題の大半（85％）を発見できる
・1度に15人のテストよりも、テスト実施時期を3回に分けて5人ずつをテストをしたほうが良い

といった感じで、1度きりの大規模なテストで終わらせるよりも、小規模なテストを繰り返してプロダクトを磨き込んでいくことを推奨しています。

「とりあえず5人やっとけばOK」ではなく、「3〜5人のテストでも十分に価値はあるから、もっと積極的＆継続的にユーザーからのフィードバックを得たほうがいい」という意味合いになっています。

確かに1回目のテストで問題点が出たら、それらを修正した状態で再テストして、果たしてそのアプローチで改善できたのか検証したい。前回見落としに気づけたり、もし似たような反応が多くあった場合、それを確証が高い参考データとして扱いやすくなるので良いなぁと思いました。

5. まとめ

ユーザーテストでは、ユーザーの行動を観察して、仮説を検証する。そこからさらに改善と検証を繰り返すことで、より良いプロダクトへと磨き込んでいく。作り手の一方通行ではなく、ユーザーと関わり合いながら、サービスを育てていくことが大事なんだと考えさせられました。

6. さいごに

最近デザインリサーチ系の資料を読んでるのですが、よく分からない専門用語や手法が登場してきて、読めば読むほど混乱してきたので、勉強がてらまとめてみました。特にユーザビリティエンジニアリングとUXデザインをはじめる本とU-Siteにはお世話になりました。

これまでの経験は、事前準備にバタバタして、分析＆レポート作成は疲れておざなりになるパターンが多かったり。…そもそもの仮説&タスク設計がいまいちで、分析しづらかったのかもしれない。

ただUXデザインとしてのお作法はありつつも、そのときのチームやプロダクト、ユーザーの状況によって臨機応変にやっていければなと。できることから少しずつ試してみようと思います。

もし勘違いしている内容あれば、コメントくださると嬉しいです。ここまで読んで頂きありがとうございました。それでは〜