失敗から学んだユーザビリティテストで気をつけること
事業会社でUXデザイナーをしているokatakuです。
去年から業務でユーザビリティテストをする機会があり、慣れないながらもテストの設計や実査をこなすにつれ少しずつ分かってきたことがあるので、備忘録としてメモを残します。
この記事での"ユーザビリティテスト"
ユーザビリティテストは様々な段階・対象で実施されるため、一意に語れない側面もあります。この記事では、以下のような条件・状況で実施するユーザビリティテストについてのポイントを記述しています。
対象：Webサイト、アプリのプロトタイプ
プラットフォーム：スマートフォン
ステータス：必要要件が固まっており、ローンチまで比較的時間がない段階
実査形式：オフライン
ローンチが迫ってきている段階のため、実際の利用状況に近い状態でプロトタイプを評価するユーザビリティテストを想定しています。完璧に状況が同じでないと使えない知見というわけではないですが、例えばペーパープロトタイプ段階での評価にはtoo muchなポイントも記載されていますので、ご理解ください。ではスタート！
実際の利用状況から逸脱する要素を排除する
この段階のユーザビリティテストでは、実際の利用状況を可能な範囲で再現することで、ローンチ後の問題発見につながる実用的な指摘を見つけ出すことができます。以下、「人」「サービス(画面)」「心理的状況」の3点から実際の利用状況に近づけるためにすべきことを書いていきます。
実際に体験しうる「人」を集める
ローンチが迫った段階でのユーザビリティテストでは、「実際にそのサービスを体験する可能性がある人」を対象にテストすべきです。体験する可能性のない人でテストをすると、「これ使わないんで~」「本当だったら~」という発言に代表されるような"自分ごと化されていない体験"を評価することになってしまいます。もし、「実際にそのサービスを体験する可能性が低い人」を対象にテストをすると、「〇〇になりきってください」「無いと思いますが、〇〇といった状況がもし起きたことを考えてください」と舵取りをする羽目になりますが、これはNG。
過去の利用状況や評価対象のサービス領域に求めることなどを聞いた上でリクルートする必要があります。この記事ではリクルート方法の詳細には触れませんが、ニールセン・ノーマン・グループの有難い長編レポートを貼っておきます。
実際に体験しうる「サービス（画面）」を評価する
テスト対象のサービスや画面は、実際の製品とできるだけ変わらない状態で提供されるべきです。ローンチ近くのユーザビリティテストとはいえ、考えられる遷移を全てつけることは難しいかもしれませんが、評価対象の画面に対する言動に影響を与えそうな画面への遷移は最低限つけておくべきです。
◼︎気を利かせて微調整を加えない
テストのタスクが定まってきた段階で気をつけるべきことは、先回りして"良さそうな画面"となるように微調整を加えないことです。悪いと突きつけられることがなんとなく想像できると、その前に修正して良い評価を得たいと考えてしまうのはある種自然なことだと思います。ただ、そうすると元の画面について想像でしか語れなくなるだけでなく、新しくした画面が採用される確証がないままテストすることで勿体無いことになってしまう可能性もあります。
◼︎自分ごと感が薄れる画面がないか確認する
もう少し具体的なポイントについて記載していきます。
個人の条件が反映されたマイページ系のプロトは、表現次第で自分ごと感が激減するため工夫が必要です。例えば自身が契約したことのない・契約をするはずのないプランを契約している画面見た際、それまで自分ごと感が高まっていたとしても、見ている画面は「自分のスマートフォン」から「誰かのスマートフォン」に変わります。被験者の情報を事前入力しておき、プロトの出しわけをするなどの対策は考えられますが、too muchな気もしています。何か知見がある方はぜひ教えていただきたいです。
◼︎画面からヒントを与えない
Figmaで作成したプロトタイプでテストをする場合、インタラクティブ領域がハイライトされてしまうホットスポットを解除すべきです。理由は言うまでもなく、実際にはそんなヒントが出ないからです。
実際の利用状況に即した「心理的状況」を再現する
ユーザーの自然な心理状態を再現するためには、テスト当日の空気作りやタスクを慎重に設計する必要があります。
◼︎空気から再現する
初めて訪れる場所で初対面の人の前でテストされるとなると、工夫なしではいつもの心理的状況を再現することはとても難しいです。ユーザーインタビューなどでも実施するラポール形成はユーザービリティストにおいても必要であることに変わりはありません。以下はユーザビリティテストならではの注意点を記述します。
なんでも言っていい雰囲気作り・前提説明
テストとなると肩の力が入り、少しでも良く見せようと思われてしまいがちです。テストの前提説明として、「プロダクトの欠点をテストするものであり、あなたをテストするためのものではない」ということを最初に伝えることでこの問題に対処します。
今度はプロダクトの指摘をするとなると、「本当は使いづらいけど目の前に関係者がいるから鋭いことは言えないなあ」となる方も少なくないです。"目の前にいる人たちは作り手ではない"あるいは、"作っている人は別にいる"といったことを伝えることで、発言のハードルが下がります。
観察者の存在感の圧を考慮する
観察者の人数や距離感が圧を与えていないか確認する必要があります。近すぎないテーブルでファシリテーターと記録者の二人体制で実査するのが良いかと思います。
オンラインで観察する分には何人いてもいいかと思いますが、存在感は消すべきです。追加質問はチャットで連携し、ファシリテーターを通してするようにしています。
◼︎タスクから再現する
まず、タスクを実施する可能性がある「人」を呼ぶことが大前提必要です。
さらに、参加者に与えるタスクは、実際の使用シナリオを模倣することで、現実的な反応を促します。
ユーザーへのタスクインプットは最低限にする。
タスク前のインプットはシンプルに行動に移せるような表現・ボリュームにすることで、自然な体験を観察することができる。インプットが簡潔にならない場合は、呼んでいる「人」や「タスク」が実際の利用状況とかけ離れていないか確認すると良い。
してもらいたい動作をタスクにしない
タスクの伝え方によって言動が大きく変わってしまいます。動作をタスクにし、そのまま指示を出してしまうのはやりがちなミスです。行動を誘導するだけでなく、実際の利用状況では知り得ないヒントを持った状態でタスクをスタートすることになります。
『予約ボタンを探して押してみてください。』これは動作をタスクにしている例です。ユーザーは本来検討すべき項目をすっ飛ばして予約ボタンめがけてページ内を探索してしまいます。このようなモチベーションも、ページを見る前から予約ボタンがあることを知っている状態も実際の利用状況とはかけ離れています。タスクの設計はユーザ視点で発想するようにします。
自然な体験評価と舵取りのバランスを意識する
前章「実際の利用状況から逸脱する要素を排除する」では体験までの準備段階で工夫すべきポイントをまとめました。この章では、テストユーザーの体験時・体験後の意識すべきポイントをまとめます。
基本は観察に徹する
言わずもがなですが、タスク実行中はユーザーを観察することがメインとなります。記録者は発言だけでなく、行動も記録しておくようにします。ファシリテーターも同様に行動を観察し、タスクが終わってから気になった言動の背景を深掘りすることで、何を感じそのような言動に至ったのかを理解します。
◼︎ユーザーの意見を信じすぎない
観察に徹するの裏返しですが、ユーザーの意見をあまり聞こうとしない、信じすぎないようにしています。「ユーザーは自分の欲しいものを言語化できない」という言葉をよく聞きますが、まさにそうだと思います。さらに、ユーザビリティテストでは観察者の前でいい格好をしたいため、見つけられなかったことを「見つけていた」と言うし、理解できていないことを「理解できている」と言ってしまいます。ユーザーの理解度や捉え方は、言動の観察から理解しようとします。
評価したいポイントへ舵取りをする
ユーザビリティテストでは、あらかじめ検証したい仮説や評価したい画面を設定するため、任意の画面での言動を観察する必要があります。しかし、基本は観察し、途中で口出しをすべきではないため、任意の画面への誘導の仕方やタイミングには繊細になる必要があります。自身もユーザーが想定外の行動を試みた際、すぐに修正してしまうことがありました。限られた時間があるため、時には半ば強引な舵取りもやむを得ませんが、想定と違う行動やその時の心理状態こそテストでしか分からないことです。ユーザーのやろうとしていることや考えが一通り理解できるまで泳がせて観察すべきです。
まとめ
以上がこれまで学んだ、ユーザビリティテストで気をつけることでした。
共通して言えることは、欲しい結論ありきでテストの設計・体験評価をしないと言うことです。タスクを設計する際に仮説を立てることはあるものの、仮説を検証しようとする思いが強いと、どうしても誘導してしまいます。実査前までの事業者視点と、実査での中立な視点を意識して切り替えるべきなのかと思います。ここまで読んでいただきありがとうございました！
参考
この記事が気に入ったらサポートをしてみませんか？