ユーザビリティテストをやってみよう！②【スクリプト作成編】 - テンプレートも配布！
ユーザビリティテストをやってみようシリーズ第2弾です！
今回は事前準備の続き、「タスク・シナリオ設計 & テスト当日のスクリプト」について書きます。
記事の最後にスクリプトのテンプレートも配布もしております。よかったら使ってみてください😊
前回の ①【事前準備編】はこちらからご覧ください✨
事前準備④ - シナリオを設定しよう
前回の ①【事前準備編】 の中で、ユーザビリティテスト内でモニターさんに操作してもらいたいタスクをざっくりと設定しました。
タスクの例：
・アプリ内で商品を購入する
・購入時、配送時の日付指定をする
ここで設定したタスクは、提供する機能が使えるか？を検証するための、テスト当日にテストモニター（被験者）に操作してほしい項目になります。
しかし、実際にユーザーがサービスを使うときに「では配送設定で日付の指定を行ってください」という天の声が降ってくるわけではありません。
「普段ユーザーが一人でサービスを利用している状況」を演出し、自力で操作にたどり着けるかどうかを確認するための「シナリオ」を作成しましょう。
シナリオの例：
あなたは夏服を新しく買おうとしています。
ピンクのフレアスカートを1着、白のブラウスを1着、ファッション通販アプリ「◯◯◯」で購入することにしました。
あなたは仕事の都合上、平日に荷物を受け取ることができません。
今週日曜日の19時に自宅に届くよう注文してみてください。
こちらはあなたの仮の住所となります。
〒111-1111
東京都◯◯区◯◯1-2-3 ◯◯マンション302
こちらのシナリオ内容は、テスト中にモニターさんが確認できる形で提供しましょう。対面の際はプリントアウトしお渡しするのが好ましいです。
私はリモートでテストする際は、ハングアウトのメッセージ機能を使い、上記のテキストを送信しています。
事前準備⑤ - スクリプトを用意しよう
ユーザビリティテスト当日に必要なスクリプトを用意します。
進行に必要な台本ですね。
私は普段、1つのテストに対し1つのGoogleドキュメントを作成し、以下の内容をすべて書き込んでいます。
・テストの目的・仮説
・流れに合わせたスクリプト、質問内容等
・モニターの発話（記録時）
テスト内容はぜひぜひ他のメンバーにも見てほしいので、「ここを見ておけばいいよ！」の情報がコンパクトにまとまるよう、1つのドキュメントという形で記録しています。
ではさっそくスクリプトを作成しましょう！！
私は以下の項目をGoogleドキュメントに記載しています。
目的
仮説
----------
タスク概要
事前準備メモ
モニター情報
------------
最初の説明文
事前アスキング
後半の説明文
タスク内容詳細
発話メモ欄
事後アスキング
------------
後片付けメモ
目的
これは①【事前準備編】で設定した目的。今回のテストで検証したいものは何かを書きます。
仮説
これも①【事前準備編】で設定した仮説を書いておきます。
タスク概要
今回のテストで確認する内容を書きます。〇〇画面で○○する、みたいな感じです。
事前準備メモ
テスト前（モニターが来る前）に準備しておかなければならないこと等を記載しておきます。
例えば録画・録音設定をしておくとか、リモートだったらオンライン通話ツールのURLを用意しておくとかですね。
リモートでやるときはインターフォンの電源切っておいた方がいいです！
モニター情報
予め知っているモニター情報を書いておきます。
最初の説明文
はいモニターさん来ました！ってときに話す内容を書いておきます。
私はこんな感じで書いています（いつも箇条書きです）
・お時間をいただきありがとうございます
・（自己紹介する）→ インタビューをさせていただく○○です
・今回は前半にインタビューさせていただき、後半は現在作成中のアプリを触っていただこうと思っています
・全体で○時間くらいを想定しています → お時間大丈夫ですか？
事前アスキング
こちらは事前に聞きたい質問リストを記述します。
私はその日のテストで、前半30分をインタビュー時間としています。普段の行動や、タスクに関連のある行動などを質問します。予め用意している質問リストは以下のような形式です。
・＞お名前を教えて下さい
・
・＞差し支えなければご年齢をお伺いしても？
・
・＞お仕事は？
・
・＞普段よく使うアプリはなんですか
・
買い物について
・＞普段の買い物はどのようにされているか
・
・＞最近ネットで買ったものはあるか（何を / サービス名 / 決済手段）
・
・＞いつからネットで買い物し始めたか（きっかけ / 最初の感情 / 抵抗感）
・
「＞」の記号は「こちらからの質問」を示す印に。2行目は解答欄として用意しています。
丸括弧の部分には、深堀りしていく中で知りたい情報をあらかじめ書いておいています。
基本的に投げかける質問は1つだけ。回答していただく中で丸括弧内の質問を聞いていきます。
❌ 質問攻め
モデレーター「最近ネットで買ったものはありますか？何を買い、そのときどんなサービスを使って、どんな決済方法を使ったか教えていただけますか？」
モニター「えっと…3日前くらいにしました。使ったのは○○のアプリで……すいません、あと質問なんでしたっけ…」
⭕️ 1つずつ聞く
モデレーター「最近ネットで買ったものはありますか？」
モニター「はい。スカートを買いました」
モデレーター「そのときどのような流れで買われたか教えていただけますか？」
モニター「買いたいものは決まってたので、○○っていうブランドです。まず○○のアプリを開いて…（以下略）」
モデレーター「その時の支払いはどのようにされたのですか？」
モニター「クレジットカードですね。登録してあるやつを使ってます」
後半の説明文
ここでは後半の、プロトタイプを使った実査について説明します。
私のスクリプトは以下のような感じです。
前半のインタビューは以上です。ありがとうございました。
続いて後半に移ります。
後半では、現在開発中のアプリを使って、ある操作をお願いします。
実際に◯◯さんが操作しながら、どう感じたかなどをお聞きできればと思います。
タスク内容詳細
ここではプロトタイプを使ったテストのための説明手順をメモしておきます。
テストに必要な設定
・(リモートの際)画面共有の設定説明
操作について説明
・まず以下のURLを開いてください(プロトタイプを一時的に共有する)
https://...
・仮の設定のもと、操作をお願いします
・設定を今からお送りします(→ハングアウトで送信)
あなたは夏服を新しく買おうとしています。
ピンクのフレアスカートを1着…（以下略）
注意点の説明
・まだ作成途中のアプリのため、動かない箇所もあります。また、うまく操作できないこともあるかもしれませんが、それはあなたが悪いわけではなく、アプリに問題があるということなので、気になさらなくて大丈夫です。
・また、操作を開始してからは、「ここはこうですか？」などの質問には答えられないことをご了承ください。
・どう感じたかを知りたいため、独り言をぶつぶつ言いながら操作してみてください。 例えば「今からここを押します」「これはなんだろう？」といったように。
・最後に、お願いした操作が完了したと思ったら、「終わりました」と私に教えてください。
・ここまででなにかわからなかった点や不明な点などはありますか？
発話メモ欄
本来は進行役のモデレーター1人、記録が1人、とそれぞれが集中できるようにした方が良いのですが、私の環境だと人数がそんなに取れないこともあり、モデレーターと記録を自分が兼任しています。
発話メモ欄には、基本的にはモニターが発話した内容をすべて記録しています。
記録スピードを早めるため、私は以下のルールに沿って書いています。
モデレーター(進行役)の質問は「＞」
例:
＞今なにを考えてる？
＞どこを押した？
（実際は「考えてらっしゃいますか？」と聞いてますが、記録では時間短縮のため上記のような省略形で書いています）
モニターの行動は「＃」
例:
＃ ナビゲーションバーの戻るをタップ
＃ 検索画面で手が止まる
モニターの発話はベタ書き
例:
えっと、まずはこのボタン（購入）を押してみます
なんか小さい字が…あ、送料無料って書いてある
ふっと見たラベルを口にしたとか、「あ」とか「うーん…」も温度感が分かるので発話は極力全部書きます。
実際に続けて書くと、以下のように記録する形になります。
＃ カートボタン押下後
このボタン（「配送方法の指定」ボタン）押してみます。あれ、動かない。えーっと…
＞そのボタンを押したら何が起こりそうか
なんか、変更？的なことができそうです
＞どんな内容が変更できそう？
ポスト投函でもいいよとか…メール便を選べたりとかですかね。
Tips: 発話記録時に普段注意していること
①指示語を明らかにする
テスト中、最も発される指示語は「ここ」です（経験談）。
『ここ』をそのままにしておくと、あとで振り返ったときに「『ここ』って、どこのことや…」とわからなくなってしまいます。
なので、記録中に「ここ」の言葉が出た際には、極力メモを追加します。ここ（…）とか、ここ（＋）とか、記号をを書くだけでも見返したときかなりヒントになります！
②事実のみを書く
記録では「ユーザー行動の事実」のみを書き、考察は書きません。
❌ ＃ ホーム画面でボタンが見つけられず、動きが止まった
⭕️ ＃ ホーム画面で動きが止まった
記録時に考察を書くとかなりバイアスがかかります。のちの振り返りでも「ボタンが見つけられなかったんだね！じゃあボタンをもっと目立たせよう」と結論づけてしまいます。
でも本当にそうですか？ボタンが見つけられなかったことが原因ですか？目に入ってはいたけど、ほかの要素の主張が強すぎて気に留めなかったのではないでしょうか？
テスト中の時間がないときに、原因追求は難しいです。
記録時は「事実の記録だけ」に集中します。
事後アスキング
テスト終了後、以下の内容を質問します。
さきほど操作いただいた機能について質問します。
・ご自身が日常で使う = 10点、ご自身だったら使わない = 1点とすると、操作いただいた機能は何点ですか？
・特に気になった点はありますか？
すでにリリースしているアプリの場合は「普段お使いになられていて、気になっている点はありますか？」って聞くのもアリです👍
普段感じているポイントを情報収集できる絶好の機会です。
後片付けメモ
最後に必要な設定等があればメモしておきます。
私は共有リンクの設定変更、OFFにしたインターフォンの解除などを書いています（終わって一段落すると忘れがち！）。
スクリプトは以上です！
テンプレート配布します！
下記にスクリプトのテンプレートを貼っています！
よかったらDLして使ってみてください😊
今回はここまで！
次回はテスト中に「モニターの発話を引き出すコツ」についてまとめます😊
この記事が気に入ったらサポートをしてみませんか？