Web サイトのユーザビリティテストスクリプトの書き方
ユーザビリティ調査とは？
ユーザビリティ調査、すなわちユーザビリティテストは、次の目的で体系的なアプローチを確保するためにテストスクリプトを使います。
- ユーザーがスクリプト化されたタスクを成功裏に実行できるかをテストする
- タスク完了に対する彼らの好みを見つける
- 製品改善の機会を見つけ出す
テストスクリプトとは？
ユーザビリティ調査の中心にはテストスクリプト（test script）があり、モデレーターがテストセッション中にこれに従って、タスクベースのユーザビリティテストを実行し一貫性を確保します。
テストスクリプトは:
- カバーしようとしていたことを確実にカバーするのに役立ちます。 ユーザビリティ調査のリサーチ目的を満たし、プロジェクトを進めるために必要な答えを携えて調査から出てくることを確実にするのに役立ちます。
- セッション間で一貫性を保ちます。 厳密な方法論を維持するため、すべての参加者に同じ質問をすることが重要です。これは分析時の作業も楽にしてくれます。
- 協働を支援します。 特に、他の人があなたの作業をより容易にレビューできるようにします。
- セッション中の時間管理を助けます。 約束した長さにリサーチセッションを収めることが重要です。
テストスクリプトなしで堅実なユーザビリティ調査を実践することは、実質的に不可能です。スクリプトなしで臨んではいけません。
タスクベースのユーザビリティテストの最初のドラフトを書く方法
ユーザビリティ調査の最初のドラフトを書くためのスタート地点として、この ユーザビリティテストスクリプトテンプレート（内部アクセスのみ）を使ってください。
ユーザビリティ調査スクリプトは通常 4 つの主要パートに従います。
各パートについての説明です（テンプレートを見ながら読み進めることをお勧めします）。
導入
ここで自分と、参加しているチームの他のメンバーを紹介します。また、ユーザビリティ調査の参加者にセッションの進行を伝え、録画と共有への同意を得ていることを再確認します。
導入を使って参加者とのラポールを築きます。人々はリサーチセッションの開始時に、ためらいや緊張、あるいは少しよそよそしさを感じることがよくあります。「ああ、あなたの住んでいる場所に行ったことがあって、とても気に入りました」のような簡単なコメントが、人々をリラックスさせ、調査がスムーズに進むのを助けるのに大いに役立ちます。
テストしているソリューションから自分を切り離すことを忘れないでください。テストされているコンセプトの作成に関わった人物として自分を提示しないでください（たとえ関わっていたとしても）。参加者がテスト中に何を言っても、こちらの気持ちを害さないことを強調してください。エクスペリエンスをテストしているのであって、参加者をテストしているのではないことを思い出させます。また、このエクササイズの主要な目的は彼らの率直なフィードバックを受け取ることであると思い出させます。
ウォームアップ質問
ウォームアップ質問は、さらにアイスブレイクを進め、参加者についての関連背景情報を得るためのものです。
考慮すべき標準的なウォームアップ質問をいくつか挙げます。
- 現在の役割は何ですか？
- その役割にどれくらいの期間就いていますか？
- [調査トピック] に関する経験はありますか？
- GitLab を使ったことはありますか？あるとしたら、何のためですか？
Tip 1: 特に聞きたいことがなくても、ここで少なくとも 2 つの簡単な質問を用意してください。アイスブレイクの助けになり、参加者をより落ち着かせます。
Tip 2: あなたのデザインとやり取りする前の、参加者のメンタルモデルと期待を理解するのに役立つ質問を尋ねることを検討してください（例えば、「Security Dashboard というページがあります。そのページを使ってどのようなタスクを達成できると期待しますか？」）。
Tip 3: 必要があり時間があれば、この調査または別の調査に役立つ追加のインタビュー質問をここに含めてもよいです。（別の調査の場合は、同じ参加者プロフィールを共有していることを確認してください！）特に、後でペルソナや JTBD 調査の一部として使えるかもしれない質問を尋ねることを検討してください（例えば、「あなたのトップ 3 のタスクは何だと言えますか？」）。
タスク
これはユーザビリティ調査スクリプトの中心であり、書くのに最も時間がかかる部分です。ユーザビリティ調査は通常（常にではありませんが）3〜4 タスクで構成されます。
良いタスクを定義する方法 タスクを書き始める時には、すでに リサーチ目標、目的、仮説を定義 しているはずです。良いユーザビリティテストを作成するには、あなたとステークホルダーが調査から得たいことの詳細を述べたリサーチ目的を見直し、それらをユーザータスクにどう最適に翻訳するかを考えることから始めます。
タスクやエクスペリエンス、デザイン／プロトタイプがどのようにパフォーマンスを発揮したかを判断する際に使う、明確で合意済みの測定指標も必要です。何が合格／不合格に見えるかを定義する必要があり、参加者がユーザビリティタスクを成功裏に完了したかを判断できるようにします。
目的からタスクへ進む際に覚えておくべき鍵は、タスクは現実的なユーザー目標を反映すべき ということです。
例えば、目的の 1 つがユーザーが CTA（call to action）を素早く見つけられるかを調べることだとします。しかし、ボタンを見つけるという目標でウェブサイトに訪れるユーザーはいないので、タスクを「ボタンを見つけてクリックできますか？」とすべきではありません。むしろ、参加者がそもそも なぜ ボタンをクリックしたいかについてのものであるべきです（例えば、「プロジェクトで機能 X を有効にしたいです。それをやってくれますか？」）。
別の目的は、フローに対する潜在的な改善点を特定することかもしれません。現実のユーザーは通常、欠点を見つける唯一の目的でウェブサイトに訪れることはないので、参加者に「次のステップを完了して、何を改善すべきか教えてもらえますか？」と尋ねる代わりに、フローを試みる必要のあるタスクを実行してもらい、彼らがどこで失敗し、つまずき、ためらうかを注意深く観察します。
Tip: UI に存在する言葉を使うのは避けてください。タスクが UI で簡単に識別できる言葉で書かれていると、参加者はタスクを完了するために UI でそれらの言葉を探す傾向があります。
最後に、バイアスを避け、参加者を誘導しないよう、また他のよくある落とし穴を避けるよう、タスクの言い回しに細心の注意を払ってください。
- シナリオを書くとき、明確さと誘導する言葉のバランスをとることが重要です。使う言葉は、参加者にとってなじみのある言葉であるべきです。それらの言葉がどうあるべきか分からない場合は、リサーチャーにガイダンスとフィードバックを求めるべきです。
- 参加者が使う言葉を使ったのにそれでもタスクを完了するためにインターフェースをスキャンしているのが見える場合は、タスクの提示方法を変えてください。各タスクは、システム内であなたがしてほしいことを参加者自身が説明し、通常それをどう行うかを説明することから始めてください。そうすれば、参加者があなたに対して使ったばかりの言葉を使って、タスクを行うよう導くことができます。
- 参加者がタスクを開始する前に、与えられたタスクを完全に理解していることを確認することが極めて重要です。ファシリテーターとして、参加者がタスクの明確化を求める質問と、タスクを成功裏に完了するために使える情報を提供しないこととのバランスをとる必要があります。
- ユーザビリティ調査、つまりユーザビリティテストは、参加者が与えられたタスクを達成できるかを評価することに焦点を当てるべきで、彼らがどうタスクを理解するかを探ることではありません。タスクのどこかで参加者が進めなくなった場合、通常どう進めるかを尋ね、そのオプションを試すよう促してください。
良いタスクの書き方についてさらに学ぶには、Write Better Qualitative Usability Tasks: Top 10 Mistakes to Avoid を強くお勧めします。
Tip 1: 各タスクについて、そのタスクに関連するプロトタイプ／ウェブページのリンクをスクリプトに追加してください。スクリプトをレビューするチームメイトがタスクの内容を理解するのに役立つだけでなく、参加者が再度リンクを必要とした場合に素早く再送できます。
Tip 2: 各タスクの下に、薄いグレーで「私たちが期待している行動」（例: 「CI パイプラインに従って SAST ジョブの出力に入る」）をメモすることを検討し、モデレーターにタスク完了の可能な経路を思い出させましょう。これは、参加者が前提となるタスクで失敗した場合に、モデレーターが参加者の回復を助けるのに役立ちます。
タスクの順序の決め方
- タスクが互いに合理的な方法で積み重なるなら、それを反映するように順序を決めてください。例えば、タスク 1 を特定のページへのナビゲーション、タスク 2 をそのページのレビューに関するものにできます。
- 同じトピックや製品領域に属するタスクをまとめます。
- 一般的なルールとして、最も重要なタスクから始めます。ユーザビリティセッションのモデレーションをマスターするには時間がかかり、始めたばかりの頃は時間が押すのは普通です。そのため、最も重要なものから始めて、あれば良い程度のものはテストの最後に残してください。
各ユーザビリティテストシナリオの構造化
各タスクについて、参加者にコンテキストと適切な動機を提供するためのセットアップが必要かを検討します。必要なら、タスクを与える前に関連シナリオを記述します。ユーザビリティテストケースの例をいくつか見てみましょう。
シナリオ: 「これがあなたが取り組んでいるプロジェクトで、ちょうど新しいコードをコミットしたとしましょう。」 タスク: 「そのコードにセキュリティ脆弱性が含まれているかをテストしてください。」
次に、参加者が自発的にこれらのトピックを挙げない場合に、タスクが展開する中でモデレーターが活用できる、より具体的な質問とプロンプトを追加することを検討します。例:
- このページに何が見えますか？
- このページは何についてですか？
- SAST は今実行されていますか？
- もしあれば、次に何をしますか？
まとめの質問とクロージング
ここで、参加者が見たり経験したりしたことについての広範な印象を得ることができます。考慮すべき標準的な質問をいくつか挙げます。
- 今経験したこのプロセスについてどう思いますか？
- GitLab で経験したばかりのこのプロセスは、普段使っているツールと比べてどうですか？
- 他に追加したいことはありますか？
定性的なアンケート質問を含めることもできます。「なぜその回答を選びましたか？」と必ずフォローアップしてください。例えば:
- [挿入: タスク] を完了するのは簡単でした。
- 完全に同意する
- やや同意する
- 中立
- やや同意しない
- 完全に同意しない
参加者への感謝と、いつ報酬を受け取れるかについて言及してスクリプトを締めくくります。
ドラフトスクリプトが完成しました。次は何をしますか？
1. ユーザビリティ調査ドラフトをレビューする
ドラフトがほぼ完成したら、もう一度読み返して自分に問いかけます。
- プロジェクトの目的をカバーしているか？
- 時間的に納得できるか？時間の見積もりは経験を積めば容易になります。ユーザビリティテストは通常 30〜45 分かかることを覚えておいてください。
2. 他の人にドラフトをレビューしてもらう
ステークホルダーやチームメイトから受け取ったフィードバックに基づいて編集します。
3. テストをテストする
同僚や内部参加者でパイロットテストを実施し、タスク指示が明確で、時間内に収まるかを確認します。必要に応じて編集し、大きな変更があればステークホルダーに通知します。
リモートでモデレートありのユーザビリティテストのクラッシュコース
bfd74782)