ユーザビリティテスト報告書：課題を録画と結び付ける方法

報告書は観察から始める

「参加者は画面の移動が気に入らなかった」だけでは、どこを直すか分かりません。録画を見ると、返品方法を探して支払い画面を3回開き、その後に助けを求めていたかもしれません。これなら特定のタスクで再現できる課題になります。

画面のバージョン、端末、シナリオ、成功条件、進行役の支援を記録します。条件が分からないと、試作品でのつまずきを本番製品の不具合と取り違えたり、ヒントを得た結果を自力での成功として数えたりしかねません。

セッションから検証可能な所見をまとめる

1. 重要な場面に印を付ける

   セッションごとに、タスクの開始、つまずき、再開、結果を記録します。文字起こしと画面録画を照合しましょう。「クリックした」という発言が、実際のクリックを表すとは限りません。行動の前後のタイムコードも残し、背景を確認できるようにします。

2. 観察と解釈を分ける

   観察欄には行動と結果を書き、推定原因は別の欄に記載します。「支払い画面で返品方法を探した」は観察です。「項目名が分かりにくい」は仮説で、次の画面案で検証できます。

3. 似た事例を比較する

   同じ課題が同等のシナリオで起きた場合に限り、場面をまとめます。何人がその課題に遭遇し、何人がタスクを行ったかを書きます。少人数の調査で得た割合を製品の全利用者に当てはめないでください。

4. 対応と検証方法を決める

   タスクが止まったか、支援が必要だったか、余分な手順が生じたかを評価します。製品の状況を踏まえて優先度を合意します。変更案については、次のテストで何が観察できれば効果があったと分かるかを書きます。

利用者が注文の返品方法を探す

以下は架空の学習用事例です。名称、条件、結果は手順を説明するためのものです。

一つの発言だけでは画面上で何が起きたか分かりません。この例では、支払い画面を2回開き、進行役がヒントを出すまでタスクが止まったことが録画で分かります。試作品のバージョンと一緒にカードに記録します。

注文の詳細にリンクを追加する案は検証が必要です。次のテストでは、参加者が助けなしに操作を見つけ、どの注文を返品するか理解できるかを確認します。

報告書用の課題カード

先にカードを作成し、その後で主な障害を短くまとめます。結論とテスト資料とのつながりを保てます。

課題の短い名前：
バージョン／端末／タスク：
参加者とタイムコード：
観察した行動：
タスクへの影響：
進行役の支援の有無：
同等のセッションでの再発：
推定原因：
優先度と根拠：
変更案：
結果の検証方法：

報告書をもとに対応できるか確認する

• 重要な所見を録画から探せる。
• タスクを自力で終えたかが分かる。
• 原因を仮説として示している。
• 変更案に次回の検証基準がある。