今日の問い
利用者が迷ったとき、それは画面の問題だと分かる課題文になっていますか。
30秒でつかむ
ユーザビリティテストは、利用者がプロダクトで課題を進める様子を観察する方法です。好みを聞く会ではありません。
計画には、検証する問い、参加者の条件、現実的な課題、観察する行動、同意、進行役と観察役を置きます。機能名や正解の場所を課題文に含めないことが大切です。
30秒図解 · LESSON 28
流れ図
質問ではなく、行動を観察する
目的、課題、観察項目、判定条件をテスト前に固定します。
- 01学習目的
- 02現実的な課題
- 03観察する行動
- 04成功条件
CLUE · 見抜く手掛かり
答えを誘導しない課題になっているか
TRAP · ありがちな罠
好きかどうかだけを聞く
原則
最初に問いを一つへ絞ります。「使いやすいか」では広すぎます。「予約変更の入口を、説明なしで見つけられるか」なら、見る行動が決まります。
参加者は、想定利用者に必要な経験や状況から選びます。人数だけを先に決めません。試作品の段階、検証したい差、利用者の多様性によって募集条件を決めます。支援技術を使う体験を確かめるなら、その利用者を計画に含めます。
課題文は目的を伝え、操作方法を教えません。「予約変更を押してください」ではなく、「来週の予約を金曜日へ変更してください」とします。架空データを使い、患者情報や私的な予定を入力させません。
記録するのは、成功したかだけではありません。開始点、迷った場所、戻った回数、発言、助けを求めた時点を、解釈と分けて残します。進行役は参加者を助けすぎず、観察役は途中で説明しません。
録画や画面共有を行う場合は、開始前に目的、保存、閲覧者、削除時期を説明し、同意を得ます。中断できることも伝えます。テストするのは人ではなく設計です。
目的に沿うシナリオ、参加者、進行役と観察役、同意、発話思考、観察記録、終了後の統合を含むテスト計画を支える。
良い例と惜しい例
課題文の中立性
検証したい問いを隠さず、操作方法は教えない課題文を選んでください。
検証したい問いを隠さず、操作方法は教えない課題文を選んでください。
AIへの指示例
目的: 予約変更の入口発見と完了までの迷いを観察するユーザビリティテストを設計する
制約: 課題文に画面上の機能名や操作順を含めない。実在する個人情報を使わない。録画は同意前に始めない
参照: problem-hypothesis.md、assumed-user.md、primary-flow.md、wireframes/
受入条件: usability-test-plan.mdに検証問い、参加条件、課題文、成功条件、観察項目、進行台本、同意、記録方法、中止条件を記す
確認問題
セルフチェック
1. 『予約変更の入口を見つけられるか』を調べる課題文として、機能名を含めない理由は何ですか。
最終制作へ反映する
usability-test-plan.mdを作る
検証問いを一つ選び、参加条件、課題文、観察項目、役割、同意、記録方法、中止条件をusability-test-plan.mdへまとめる。
Acceptance criteria
- 課題文が現実的な目的を示し、画面内の名称や正解の経路を教えていない
- 成功条件と観察項目が行動として記述され、録画や画面共有の同意手順がある
今日のまとめ
- ユーザビリティテストは、利用者が課題を進める行動を観察する
- 課題文は目的を示し、機能名や正解の経路を教えない
- 次は、観察事実を解釈と分け、直す順番を決める