こんにちは、デザイナーのachanです。
クイックでは新型コロナウイルスの感染拡大防止のため、4月より原則出社禁止、リモートワークになっています。 その影響でユーザーと直接会えず対面でのユーザーテストやインタビューを中止せざるを得なくなっています。これをきっかけに、リモート環境でのユーザーテストの実践法をまとめてみたいと思います。
リモートユーザーテストとは
リモートユーザーテストとは、ユーザーに自宅のパソコンや携帯からWebサイトやアプリを利用してもらい、その行動や発言の観察を通して「ユーザー心理」と「Webサイトやアプリの課題」を見つける調査手法です。
また実施形式の「進行」(モデレーター役)という観点から2種類に分けられます。
- 進行あり：同期型リモートユーザーテスト
- 進行なし：非同期型リモートユーザーテスト
利用するツール・環境
対面で行うテストのように操作中の行動や発言（思考発話・ひとりごと）の録画や、閲覧したページの記録、アンケート形式の回答データの取得など目的に応じてツールの準備が必要です。
基本、リモート環境では必要なツールは以下に分けられます。
- ビデオチャットツール(例: Google Hangouts Meet / zoom)
- スクリプトメモ用ドキュメント (例: Google Spreadsheet)
- 画面録画ツール(例: Lookback)
- 議事録用ツール(例: Miro)
ちなみに、ビデオチャットツールは以下の項目に注意して選定する必要があります。
ユーザー側
- ソフトインストールが必要かどうか
- 画面共有ができるか
- スマホ画面のミラーリングができるか
実施側
- 録画・録音ができるか
上記すべて満たすものとしては個人的にzoomがお勧めです(アカウント作成が必要)。
テストの準備
1. 目標を定義し、ユーザーを募集する
効果的なユーザーテストを行うためには、テストするサイトやアプリの検証目標(タスクベースなど)を定義し、ターゲット条件に限りなく近いユーザーを募集しましょう。例えば、
① 似たものの利用経験の有無
② 製品・サービスへの興味の有無
③ ITスキルの高低
また、人数に関しては、ユーザーテストは定量調査の目的ではなく定性調査を目的に実施するため、1検証に対しておよそ5人の実施で有効な検証結果を得ることが出来るとされています。
一方で進行なしのユーザーテストではユーザー自身に一人で操作を進めてもらうため、発生した行動や回答に対する深掘りが難しいという欠点があるのと、指示されているタスクや質問の意味を取り違えてしまったりすることがあります。それを防ぐためにはテスト実施人数を想定より1~2名多めにしたほうがいいでしょう。
2. タスクを設計し、テストスクリプトを作成する
「ユーザーテストはタスク設計がカギ」と言っても過言ではありません。適切なタスク(作業課題)を設計するための基本原則が4つあります。
① テストの実施目的に沿った主要なタスクに絞り込む
② ユーザーの視点で、その操作を行う目的や意図、状況を想定する
③ タスクのスタートとゴールを定義する
④ タスクを行う状況設定として、シナリオ化する
テストスクリプトを作成する際に、あくまで経験談となりますが例えば、
- 指示文を短くする
- 長文だと「何」を「どうする」のか、関係性が分かりづらくなる - 社内用語を使わない
- 感想を言うときはなるべくその画面に移動してもらうように指示文に書き込む
- 「つまづいたところを教えてください」だと何の画面、何の内容なのかわからない。そこで、指示文を「該当の画面を表示して教えてください」に変更すれば明確になる
テストの実施
1. 事前説明
タスクを実行してもらう前に、ユーザーに伝えておくべきポイントは主に以下3つです。
① ユーザー自身のテストではない
- 場合によっては、ユーザーが指示されたタスクをクリアできないことがあります。その際、ユーザーは自分が悪いと誤解しやすく、プレッシャーを感じてしまいテストに非協力的になってしまいます。それを防ぐため、事前に伝えておくとショックが和らぎます。
② 操作しながら思っていることを口に出してもらう
- これは製品の課題やユーザーの心理を抽出するための重要な手法(思考発話)です。なるべくユーザー自身で該当画面に移動してもらい、操作しながら感想をもらいましょう。
③ 質問には答えられない
- テストでは操作に関わるすべての判断はユーザー自身が行わないと意味がありません。そのため、操作上の疑問点があったとしてもインタビュアーが返答できかねることを事前に伝えましょう。
2. テストの進行
前述の進行の有無で２パターンがあります。
① 進行あり- 同期型リモートユーザーテストの場合
この場合では、ユーザーに提示したタスクを実行してもらい、それを観察（記録）します。
モデレーターとユーザーが離れた環境にいるので、可能な限り快適で「リアルな」雰囲気を作ります。例えば、
- 情報の取り扱いを伝える
- アイスブレイクをいつもよりやや長めに
- 声を明るく、大きく
- オウム返し
- 同席者(例: 記録係)がいる場合こちらの状況をしっかり説明する
ユーザーがタスクを実行している間、モデレーターは観察を続けます。途中で質問されても直接回答せずに、質問で返答してください。例えば、「次にどこへ行けばいいですか」と尋ねられた場合、「どこへ行けば良いと思いますか」などと返答しましょう。
もし記録係がいる場合、ユーザーが成功したタスクと必要な時間を漏れなくメモしましょう。記録係がいない場合、なるべくユーザーの発話を多く引き出し、動画に記録を残すようにしましょう。
② 進行なし - 非同期型リモートユーザーテストの場合
この場合では、事前にユーザーにタスクを送り、操作している動画を納品してもらいます。そのためユーザーが好きな時間、好きな場所において各自でテストを進めることができます。
非同期型では、テスト経験のあるユーザーが必要なので、選定する際に気をつけましょう。
テストの結果分析
テストの目的に合わせて簡易分析と詳細分析を使い分けます。
簡易分析
セッションの直後、記憶が鮮明なうちに、調査で気づいた大きな問題やその他の観察内容を書き留め、簡易リストを作成します。メモや記録を詳しく調べるまでもなく、傾向は一目瞭然です。
簡易分析は、時間の制約がある場合や、デザインの修正をすぐに行う必要がある場合に特に有用です。
詳細分析
時間と意欲があれば、「インパクト分析法」を用いて、発見された問題点を解決する際の優先順位を付けることができます。
そこで、下図のように「問題の質」と「発生頻度」 の2軸を使って判断します。
問題の質
- 発見された問題を「効果・効率・満足度」の３つに分けます。
・効果: 独力でタスクを完了できていない問題
・効率:完了できても、途中で戸惑ったり、無駄な操作を行ったりするような問題
・満足度: 完了までの過程でユーザーの不安や不満が口や態度に出るような問題
発生頻度
- 同じ問題を起こしたユーザーの人数で評価します。
・発生頻度高: (ほぼ)全員
・発生頻度中:複数人
・発生頻度低: 1人
※ 人数の境界値は厳密なルールがないが、問題点の発生頻度やテストの検証目的に合わせて方針を決めてください。
さいごに
対面でのテストと完全に同じクオリティや効果を得るのは難しいかと思いますが、コストを削減できるためリモートユーザーテストはますます人気が高まっています。 状況によって使い分ければ、効率よくユーザーに価値を提供できると信じています。
参考資料
・樽本徹也著, 『ユーザビリティエンジニアリング第2版』
・How to run a remote usability testing - UX Collective
・Remote Usability Testing 101 & Getting Started | Adobe XD Ideas
・Remote Usability Tests: Moderated and Unmoderated
＼\一緒に良いサービスを作って成長したい、そんなメンバーを募集中です！ /／
919.jp
