モデレーターありのリモートユーザビリティテスト:実施方法
モデレーターありのリモートテストを適切に実施する鍵は、徹底的な準備と段取りにある。以下の7つのステップに従って、確実に調査を成功させよう。
モデレーターありのリモートユーザビリティテストには多くの利点がある。対面調査に比べて、多くの場合、費用や時間がかからないし、参加者にとっても都合がよい。参加者がテスト会場に移動することが不可能な場合、モデレーターありのリモートユーザビリティテストは優れた代替手段になるのである。
おそらく、モデレーターありのリモートユーザビリティテストの最大の欠点は、事前にいろいろと準備が必要になることであり、とりわけ利用するツールのセットアップをしなければならないことだろう。まだ一度もモデレーターありのリモート調査をしたことがない場合は、何から始めたらいいのかを判断するのもたいへんかもしれない。
そこで、今回紹介する7つのステップに従い、モデレーターありのリモートセッションをスムーズに実施して、豊富で深い洞察を生み出してほしい。
調査計画
1. 参加者とコミュニケーションを取るためのツールを選ぼう。
テスト参加者だけでなく、観察者や進行役にも利用やインストールが容易な、画面や音声共有ツールを選ぼう。
すべてのテスト参加者に同じツールを利用する必要はない。たとえば、オフィスのコンピュータから参加する人は、会社が承認した会議ツールを利用する必要があるかもしれない。また、たとえば、ファイアウォールが厳しいために、ソフトウェアをインストールできないこともあるだろう。
画面共有ツールはいろいろとあるが、我々がリモートテストに利用しているツールは以下である:
- Zoom
- GoToMeeting
- Join.me
- Skype
- Lookback.io
ツールを選択する際には、特にインストール要件に注意しよう。そのツールが対応していないオペレーティングシステムやブラウザはないだろうか。
たとえば、Lookbackでは、モバイルでもモデレーターありのリモートユーザビリティテストが可能だが、iOSやAndroidのすべてのバージョンをサポートしているわけではない。こうした細かい部分については早めに把握しておく必要がある。リクルートに影響を及ぼすおそれがあるからだ。できれば、参加者がそのツールを利用可能であることを確認するためにスクリーニングをおこなうといいだろう。また、モデレーターありのリモートユーザビリティテスト用ツールのモバイル版は安定性の問題を抱えていることが多い、ということを認識しておこう。市販されているさまざまな種類のモバイルデバイスを完璧にサポートするのは非常に難しいからだ。
また、そのツール内で観察者をどう扱うかも考えておかなければならない。セッション中、彼らの音声をミュートにして不必要なノイズを防ぐことができるかを確認しておこう。ツールにチャット機能がある場合は、チームの会話を非公開にしておくことで、参加者の気が散らないようすることが可能なはずだ。あるいは、別のツール(Slackのようなメッセージングアプリなど)を利用して、観察者同士や進行役と連絡が取れるようにするといいだろう。
Webカメラの映像を共有するかどうかを決めよう。利用しているシステムと接続環境でそうした動画への対応が可能なら、たいていの場合は、参加者と進行役の顔をチームの皆が見られるようにすることをお勧めする。セッション中にやり取りする情報の内容が充実するからだ。
2. タスクの与え方を考えよう。
対面テストなら、単にタスクを印刷した紙を参加者に渡して、そのタスクを読み上げてもらえばよい。しかし、モデレーターありのリモートテストの場合、タスクの与え方はもう少し複雑になる。また、利用しているツールによっても変わってくるだろう。
タスクの理想的な提供方法は、一度に1つずつ与え、そのタスクを参加者に読み上げてもらうことだ。そうすることで:
- 参加者が該当のタスクを最後まで読んだということがわかる。
- 参加者が後のタスクを考慮に入れるということがない。
- 参加者が大きな声で発言する練習になる。
あわせて、参加者がタスクの実行中、指示をすぐ見られるようにしておく必要がある。彼らがタスクを忘れてしまった場合に参照できるからだ。
モデレーターありのリモートテストのタスクの提供方法は3種類ある:
- すべてのタスクが記載された文書(pdfなど)を参加者に送信する。
- セッション中、画面共有ツールのチャットウィンドウを利用して、そのときのタスクのテキストを参加者に送信する。
- 参加者に向かって、モデレーターにタスクを読み上げてもらう。
すべてのタスク(またはタスクへのリンク)が記載された文書(pdfなど)を参加者に送信する。
この場合には、セッション前にタスクを読み進めないように参加者に指示をする必要がある。その文書にタスクのテキストが出ているときは、文書の最初のページは必ず空白にし、それから、各タスクはそれぞれ別のページに記載するようにしよう。また、ページ番号を入れて、参加者を特定のタスクに誘導できるようにしておこう。参加者はこの文書を事前に印刷しておいてもよいし、テストセッション中にデバイス上で参照してもよい。
セッション中にデジタル文書へのアクセスが可能な場合は、テキスト自体ではなく、タスクテキストへのリンクを載せてもよい。その場合、各タスクの指示はWebページ(Google ドキュメントなど)としてWeb上で公開され、参加者は対応するリンクをクリックして、そのタスクを読むことになる。
セッション中、画面共有ツールのチャットウィンドウを利用して、そのときのタスクのテキストを参加者に送信する。
たとえば、Zoomには、出席者が互いにリンクやテキストを送信できるチャット機能がある。このチャットウィンドウは、タスクの指示を伝えるのに便利だ。そして、参加者には、その指示を読み上げてから、タスクを開始してもらおう。
参加者に向かって、モデレーターにタスクを読み上げてもらう。
最もお勧めできないのがこの方法だが、(たとえば、ツールやデバイスの制約などから)このやり方が唯一の選択肢になる場合もある。この方法を選択する場合は、必要に応じて、タスクの指示を参加者のために何度も読み直す覚悟をしよう。
3. 可能であれば、テクノロジーの練習セッションの予定を入れよう。
各参加者に対して、セッション前日に15分間のオンライン会議の予定を入れるようにしよう。さらに、練習のための観察者も1人か2人呼ぼう。
このタイミングで、参加者にテストに必要なテクノロジーをセットアップしてもらうとよい。必要なアプリケーションをインストールしてもらい、画面共有や音声、Webサイトへのアクセスなどに関するあらゆる障害を解決しておこう。
テストする予定のものとはまったく関係のないWebサイトやアプリを選んで、それを参加者に短時間利用してもらおう。この練習セッションでは、テストを予定している実際のWebサイトやプロトタイプをユーザーに見せたり、テストタスクを試させたりしてはならない。参加者が同意書や機密保持契約書に物理的に署名する必要がある場合は、このときに調査のそうした細かい調整についての話をし、確実に参加者がそういう文書にアクセスでき、それをどうやってセッションの前に返信したらいいのかがわかるようにしておこう。
スケジュールの制約により練習セッションができない場合は、実際のセッション中にセットアップのための時間を追加で確保しておかなければならない。
たとえテクノロジーの練習セッションをおこなったとしても、セッション中に技術上の問題が発生する可能性はあるということを認識しておいたほうがよい。練習セッションでは、参加者のセットアップは完璧にうまくいったのに、(たとえば、コンピュータが一夜のうちにオペレーティングシステムを自動的に更新してしまい)翌日には全然ダメだったということもあった。セッションを台無しにすることなく、小さな問題に確実に対処できるように、常に各セッションには少し余分な時間を追加しておくことをお勧めする。
テスト当日
4. リマインダーを送信しよう。
他の種類のテストと同様に、テストの前日の夜か当日の朝に、参加者と観察者にリマインダーメールを送信しよう。
参加者に対しては、セッションの開始時間とセッション中に必要になるもの、および、やることを再度確認しよう。たとえば、彼らに再確認しておきたいことには以下のようなものがあるだろう:
- ノートブックを充電ケーブルにつなぐ。あるいはモバイルデバイスをフル充電する。
- ハウリングを最小限に抑え、音質を向上させるために、ヘッドセットまたはヘッドフォンを用意する。
- テクノロジーテストセッションで使う練習をしたリモートソフトウェアツールを開く。
- 強力なWi-Fiまたは有線に接続する。
- 邪魔されることのない静かな場所で参加する。
観察者には:
- テストのスケジュールを再確認する。
- 観察時のルールを伝える(たとえば、5分前に参加する、自分たちの音声をミュートにしておくなど)。
- 調査を観察するためのヒントやユーザーが試みるタスクの写し、注目すべき具体的な課題を提供する。
各セッション中
5. セッションへの参加をチームに呼びかけよう。
観察者がセッションに参加すべき正確な時間は、以下の条件によって変わってくる:
- リモートソフトウェアツール
- ユーザーとのテクノロジー練習セッションがうまくいったかどうか
- 観察者との関係
セッションが開始される数分前に参加してもらうことには、特に、誰かが新しく会議のセッションに参加するたびにリモートツールからビープ音が鳴る場合、参加者の混乱を最小限に抑えられるという利点がある。しかし、観察者の時間を無駄にし、彼らの参加意欲を低下させるかもしれないのが欠点だろう。
後者が気になる場合は、調査を実施するための細かい調整がすべて終わったところで、(通常は予定の開始時刻の数分後に)観察者にセッションに参加してもらえばよい。あるいは、前のセッションの結果について話し合ってもらったり、観察者のためのヒントを確認して具体的な課題について考えてもらったりすることで、そうした隙間時間中に観察者を忙しくすることもできる。
6. 参加者とのセッションを開始しよう。
参加者が約束の時間に会議に参加したら、以下の台本をアレンジして、実行しよう:
- こんにちは、(名前)さん、ご参加いただきありがとうございます。
- 私は(XXX)です。(YYY)社で働いています。
- 始める前に、あなたのお名前の読み方は(名前)で正しいでしょうか。
- わかりました。ありがとうございます。
- ここにいるのは私の仕事仲間です。彼らはセッションを静かに観察して、(サイト/アプリ)を改善する方法を探ることになっています。
- 記録を始めてもよろしいでしょうか。
- (確認を待ってから、記録を開始する)
- (参加者がまだ同意書に署名していない場合は、以下の手順を実行する)
- (画面を共有する)
- (ユーザーに読み上げてほしい同意書を開く)
- これは、今日ここでおこなうことと、そこで得られる情報の利用の仕方を説明した同意書です。これを読み上げてください。そして、その内容に同意する場合は、あなたの氏名を声に出して言ってください。
- (読み上げと同意を待つ)
- (画面のコントロールをユーザーに渡して、ユーザーが自分の画面を表示できるようにする)
7. セッションを終了しよう。
- 参加者の協力に感謝して、お礼を言う。
- 記録を停止して、保存する。
- 観察者に報告をして、そのセッションの主な観察結果と、タスクや手順をその後変更したい場合はそのことについて話し合う。
調査が完了するまで、手順5~7を繰り返そう。(ステップ8:調査がうまくいった!と自画自賛しよう)。
モデレーターありのリモートテストを適切に実施するためのその他のヒント
- 事前に署名済みの同意書を入手していない場合は、参加者に同意書を読み上げてもらい、さらに彼らに自分の氏名を声に出して言ってもらうことで、口頭で同意を得よう。
- 他の人のテクノロジーについて考えるあまり、自分自身のテクノロジーのセットアップに手を抜いてはならない! 参加者と同じように、ヘッドセットを使用して、強力なWi-Fiに接続しよう。
- 確信がもてないときは必ず、ユーザーのファーストネームをどう発音するか聞こう。対面調査なら、ジェスチャーや音でユーザーの注意を引くことができる。しかし、リモートセッション中に参加者のタスクを中断させなければならない場合は、その人の名前を呼ぶのが最も自然に感じられる。しかし、そのためには名前の発音の仕方を知っておく必要がある。
- セッションが終了することになっている時間を把握しておこう。セッションの開始時にそれをユーザーにも確認し、そして、時間通りに終わらせよう。
- 物事とはうまくいかないものだということを受け入れ、代替策を用意しておこう。直前になってソフトウェアが更新されたり、ファイアウォールが干渉したり、アプリにバグがあることも考えられる。そうした場合、観察者をいつ解放するのか。ユーザーはどうするのか。スケジュールを変更しなければならない場合にはどうするつもりか。対面テストと同様に、セッションの時間を少し長めに取り、実際に必要だと思うよりも多くの参加者をリクルートするとよい。
- パイロットテストを実施して、プロセスや進行、タスクに磨きをかけよう。パイロットセッションとはテストそのもののテストであり、デザインのテストではない。そのため、参加者は代表的なユーザーでも誰か他の人(訳注:たとえば、社内の人間)でも構わない。
リモート調査に関する1日セミナー
モデレーターありのリモートユーザーテストの(台本のサンプル、調査計画、タスクを含む)計画、実施、分析について、さらに詳しくは、我々の1日セミナー、「Remote Usability Testing」をチェックしてみてほしい。
(この記事の前のバージョンは、2018年3月25日に公開されたものである。記事は2020年4月26日に最終更新・修正された)