ユーザーテストの進め方
「画面を直したけれど、利用者が迷わず使えるか分からない」。そんなときは、実際に使う人に作業を試してもらい、どこで手が止まるかを見てみます。ユーザーテストは、感想を集めるだけでなく、操作中の困りごとを確かめる方法です。
この記事では、進行役が同席する使いやすさのテストを扱います。目的と参加者を決め、操作を誘導せずに観察し、見つけた問題を改善候補として残すまでの手順を紹介します。
- 確かめたい作業を一つ選び、実際に使う人に試してもらう
- 操作の正解を教えず、行動と発言を分けて記録する
- 困りごとの根拠と影響を残し、次に確かめる改善候補を選ぶ
何を確かめるテストなのか決める
最初に、利用者が終えたい作業を一つ選びます。「新画面は使いやすいか」より、「初めて使う担当者が、申請に必要な資料を見つけられるか」と書くと、観察する場面が明確になります。
英国政府のユーザビリティテストのガイドも、参加者が具体的な作業に取り組む様子を観察する方法を説明しています。参加者にとって自然な目的を設定し、操作手順を問題文で教えないことが重要です。
過去の出来事や業務の背景を聞きたい場合は、ユーザーインタビューが適しています。ユーザーテストでは、いま試している画面で何が起きたかを確かめます。利用者の言葉と操作が違って見えても、どちらかを間違いと決めず、その違いを記録します。
本記事では、架空の申請管理ツールを例にします。以下の課題や記録は説明用であり、アーコレ！や実在する顧客の事例ではありません。
参加者と、試してもらう課題を用意する
参加者は、対象の作業を実際に行う人、または今後行う見込みのある人から選びます。社内の開発担当者だけで試すと、画面の構造を知っているために見つからない問題があります。初回利用を調べるなら未経験者、日々の作業を調べるなら普段の担当者というように、目的と相手を合わせます。
課題文には「何を終えたいか」を書きます。次のように、ボタン名や場所を含めない形にすると、利用者が自分で探す様子を観察できます。
| 操作を教えてしまう課題 | 目的を伝える課題 |
|---|---|
| 右上の「添付」ボタンを押してください | この申請の見積書を確認してください |
| 検索欄に取引先名を入力してください | 先週受け付けた、この取引先の申請を探してください |
| 保存ボタンを押して一覧に戻ってください | 内容を修正し、あとで続きを確認できる状態にしてください |
実施前に、使う端末、開始画面、実際の顧客情報を含まないテスト用データをそろえます。送信・削除・購入などが本番に反映されないテスト環境を使い、安全に試せることも確認します。権限やデータ量によって画面が変わる場合は、その条件も記録します。
同僚に一度試してもらい、課題文が通じるか、途中で画面が開けなくならないかを確認すると、本番での準備不足に気づけます。この予行演習の結果は、対象利用者の結果とは分けて扱います。
当日は助けすぎず、行動を観察する
冒頭で、確認したいのは参加者の能力ではなく、画面やサービスの使いやすさだと伝えます。記録の用途と共有範囲を説明し、録画するなら先に同意を得ます。参加者が答えにくい質問を飛ばしたり、途中で終了したりできることも伝えてください。
進行は、次の順で組み立てられます。時間配分を固定するより、一つの課題を落ち着いて試せる範囲に絞ることをおすすめします。
- 進行役が目的と進め方を説明する。
- 参加者が課題文を読み、操作を始める。
- 記録役が、迷った場所や操作の順序を書き留める。
- 課題を終えた後に、気になった操作や言葉の意味を聞く。
- 参加者にお礼を伝え、記録の扱いを再確認する。
操作中に沈黙が続いたら、「いま何を探していますか」のように中立的に尋ねます。「右上を見てください」と教えると、その後に分かったことは助言を受けた状態の結果になります。手助けが必要なら行って構いませんが、何をいつ伝えたかを残します。
参加者が誤った場所を押しても、すぐに訂正せず、安全なテスト環境の中で様子を見ます。ただし、実際の送信、削除、購入などにつながる場合は止めます。操作の観察を優先して、不利益のある処理を実行させる必要はありません。
「使いにくそう」を具体的な記録に変える
記録には、画面で見た行動、参加者の発言、記録役の解釈を別々に書きます。「迷っていた」だけでは、後でどこを直すべきか検討できません。
| 記録する項目 | 説明用の架空例 |
|---|---|
| 課題と条件 | スマートフォンで、申請に添付された見積書を探す |
| 観察した行動 | 申請の説明欄を読み、一覧に戻り、もう一度同じ申請を開いた |
| 発言 | 「資料はどこにありますか」 |
| 手助け | 進行役が添付欄の位置を伝えた後、資料を開けた |
| 解釈・仮説 | 添付欄の位置や名称に気づきにくい可能性がある |
| 次に確かめること | 添付欄の表示を変えた案で、助言なしに資料へ進めるか |
発言を正確に記録できなかった場合は、引用ではなく要約と記します。調査結果の分析ガイドでも、見聞きした事実と、その意味を考える工程を分けています。
「簡単でした」という感想があっても、途中で手助けが必要だったなら両方を残します。満足したという発言と、課題を自力で完了できたことは別の情報です。
見つけた問題を、次の改善につなぐ
振り返りでは、参加者ごとのメモを読み、同じ作業で起きた問題をまとめます。その際も、元の記録へ戻れるようにしておきます。似た発言でも、初回利用者と毎日使う人では原因が違うかもしれません。
改善候補には、問題が起きた場面、業務への影響、回避できたかどうか、まだ分からない点を添えます。少人数のテストで見つけた件数を、そのまま顧客全体の発生率にしないでください。画面が少し見づらい問題と、作業を完了できない問題も、件数だけでは比べられません。
複数の候補から何を直すか選ぶ際は、開発する機能の優先順位を決める方法を使えます。直した後には同じ目的の課題で再確認し、問題が解消したかと、別の迷いが増えていないかを見ます。改善を継続的な計画へつなぐ全体像は、プロダクトロードマップの作り方で説明しています。
よくある質問
何人に試してもらえば十分ですか？
目的や利用者の違いによって変わるため、人数だけで十分とは判断できません。対象業務を絞り、異なる利用条件を含めて計画します。少人数で問題を探すテストと、顧客全体の割合を推定する調査は分けて考えてください。
開発前の試作品でも実施できますか？
確認したい作業を試せる範囲で実施できます。動かない箇所や仮の表示は記録し、試作品の制約によるつまずきを、完成した製品の問題と混同しないようにします。
まとめ
ユーザーテストでは、確かめたい作業を絞り、利用者の行動と発言を記録します。操作を教えた場面も残し、根拠と影響が分かる改善候補として整理してください。まずは、問い合わせが多い作業を一つ選ぶところから始められます。
テストのメモだけなら、文書や表でも整理できます。一方、問い合わせや日々の要望も増えると、同じ困りごとを探してまとめ直す作業が必要になります。
アーコレ！は、集まった要望を整理し、優先順位の検討につなげるツールです。テストの実施や観察そのものを代わりに行うものではありません。改善候補をどう整理できるか、まずはサービス紹介で仕組みをご覧ください。
