「使いにくそうだった」は解釈です。「3回押し直してから別の画面に移った」が観察です。記録は観察から書きます。
1. 観察と解釈を分ける
検証の記録で最も起きやすい失敗は、見たことと考えたことが混ざることです。混ざると、後から見返したときに、どこまでが事実でどこからが推測か分からなくなります。観察は、その場にいた別の人が書いても同じになる内容です。解釈は、その観察から考えたことで、人によって違ってよいものです。記録欄を最初から二つに分けておくと、書く段階で自然に区別できます。
2. 検証の前に決めること
触ってもらう前に、何を確かめたいのかを決めます。すべての画面を見てもらおうとすると、どれも中途半端になります。今回見たい作業を1つか2つに絞り、それを相手にやってもらう形にしてください。あわせて、「ここまでできたら成功」という基準を先に書いておきます。基準がないと、当日の印象だけで良し悪しを判断することになります。
- 今回確かめたい作業(1〜2つ。相手に伝える言葉で書く)
- その作業が「できた」と言える状態
- 触ってもらう人の条件と人数(5人程度で多くの問題は見えてきます)
- 使う試作の形(紙、画面のつなぎ合わせ、動くもの)
- 記録する人を、進行役とは別に置けるか
3. 当日の進め方
最初に、評価されているのは相手ではなく試作であることを伝えてください。この一言があるだけで、相手は詰まったときに正直に言いやすくなります。作業中は説明せず、手が止まっても10秒ほど待ちます。すぐ助けると、どこでつまずくのかが分からなくなります。考えていることを声に出してもらうと、画面のどこを見ているかが分かります。どうしても進めない場合だけ、記録に「ここで助けた」と書いた上で手助けしてください。
- 「うまくできなくても問題ありません。試しているのはこちらの作りです」と伝える
- 考えていることを声に出してもらうようお願いする
- 作業の目的だけ伝え、操作の手順は説明しない
- 手が止まっても、すぐには助けない
- 助けた場合は、その時点を記録に残す
4. 記録シート(一人分)
一人につき一枚を使います。作業の区切りごとに行を足してください。当日その場で埋めきれない場合は、観察の欄だけ埋めておき、解釈は終了後すぐに書き足します。時間が経つほど解釈が記憶を上書きするため、当日中に書き終えることを目安にしてください。記録する人を進行役と分けられる場合は、進行中に観察の欄を埋めていくと取りこぼしが減ります。
5. 解釈を書くときの注意
解釈を書くときは、思いついた理由を一つで確定させないことが大切です。同じ観察から、複数の説明が成り立つことがよくあります。「分かりにくかったから」と書く前に、「急いでいたから」「その業務の慣れが違うから」「今回の試作が紙だったから」といった別の可能性も並べてください。並べた上で、どれが確からしいかを次の検証で確かめます。一人の観察から結論を出すのは、たいてい早すぎます。
- 一つの観察に、説明を2つ以上考えてみる
- 試作の形(紙か動くものか)が原因である可能性を除外する
- 相手の属性や経験が原因である可能性を検討する
- 確かめるには次に何を見ればよいかを書く
6. 複数人分をまとめる
全員分の記録が集まったら、観察を横に並べます。同じ場所で複数の人が止まったなら、それは試作側の問題である可能性が高くなります。一人だけに起きたことは、その人固有の事情かもしれないので、いったん保留にします。まとめの表を作り、直すもの、様子を見るもの、直さないものに分けてください。直さないと決めたものも、判断の理由とともに残しておきます。
7. 次の一手を決める
検証の価値は、次に何を変えるかが決まって初めて生まれます。まとめの表から、次の版で直すものを選び、いつまでに誰が直すかを決めてください。直した後は、同じ作業をもう一度別の人に試してもらい、同じ場所で止まらなくなったかを確かめます。一度で完成させようとせず、小さく直して、また見てもらう。この往復を数回繰り返すほうが、大きく作り直すより早く良くなります。
- 次の版で直すもの(3つ以内に絞る)
- 直す担当と期日
- 次の検証で、同じ作業をもう一度見るかどうか
- 今回の検証で答えが出なかった問いを書き残す
関連するインサイト
- UXリサーチの基本手法 — インタビュー・ユーザビリティテスト・分析ユーザーが本当に困っていることを知るための基本手法を整理します。インタビューの設計と誘導の避け方、ユーザビリティテストの観察、定量分析との組み合わせ、ペルソナの使い方、小規模チームでの現実的な進め方まで解説します。
- モバイルファーストUXの設計原則 — スマホ完結型サービスの作り方1画面1目的、親指の届く範囲、入力削減、通信への配慮というモバイルファーストの原則と、登録・本人確認・決済・通知をスマホだけで完結させる設計、Webとネイティブアプリの使い分け、検証とアクセシビリティの考え方を解説します。
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開