ScribeFlash

調査の実践

ユーザビリティテストの報告:観察・解釈・提案を分ける

タスク、引用、観察メモ、別の説明を区別し、再確認できる問題報告を作成。次のテストで確かめることまで具体化します。

ScribeFlash約8分で読めます
インタビュー資料と出典を確認する研究者

観察・解釈・提案を分けて報告する

「参加者はエクスポートを探して請求画面を開いた」は観察です。「アカウント設定の近くにあると思ったのではないか」は確認が必要な解釈です。「ボタンを移す」は設計上の提案です。この三つを分けると、何が根拠で、次に何を確かめるのかが伝わります。

以下は仮定のケースです。報告方法を説明するもので、ScribeFlashの実際のテストや、改修によるタスク成功率の改善を示してはいません。

1. タスクを決め、外部のツールで記録する

目標、開始時点、製品のバージョン、端末や支援技術、完了条件を決めます。「同僚に送れる報告書を準備してください」なら経路は自由です。「エクスポートを押してください」では、調べたい操作を先に教えてしまいます。

GOV.UKのモデレーテッド・ユーザビリティテストガイドは、答えを教えない現実的なタスクを勧めています。進行役が助けた場面も記録しておきます。

録音・録画の許可や個人情報の扱いを、調査の取り決めに沿って確認します。研究用・会議用のツールで収録し、音声または動画ファイルをアップロードします。ScribeFlashがテスト画面を録画したり、マウスの動きを自動観察したりするわけではありません。文字起こしは発言の記録です。無言の操作には観察メモと外部録画による裏付けが必要です。

2. 問題名を付ける前に証拠を記録する

架空のタスクT1で、参加者U1が請求画面を開き、プロジェクトに戻り、04:18に「送れるファイルはどこで手に入りますか」と質問したとします。その後、進行役がエクスポートの位置を示しました。

項目を分けて残します。

  • **観察:**画面の移動、戻る操作、質問、受けたヒント。操作は観察や動画に、発言は文字起こしに出典を付けます。
  • **解釈:**入口の場所や名称が期待と違った可能性。権限や不慣れなプロジェクト状態も別の説明になります。
  • **提案:**分かりやすい入口や名称を試す。まだ検証前の案です。

発言だけから感情やマウスの経路を推定しないようにします。外部録画がない場合は、確認できなかった操作を明記します。調査分析ガイドでも、観察、知見、行動を分けて扱っています。

3. 再確認できる問題記録を作る

デザインや開発に渡す記録には、次を含めます。

  1. 具体的な題名:「U1はヒントなしではレポートのエクスポートを見つけられなかった」。
  2. **タスクと環境:**T1、開始画面、試作品やビルド、端末、関係するアカウント条件。
  3. **観察した順序:**実際に見た手順と進行役の介入。
  4. **出典:**参加者コード、時刻、正確な発言、出所を示した観察メモ。
  5. **タスクへの影響:**中断、助けを受けて完了、回避策の発見のどれか。
  6. **考えられる説明:**解釈、別の原因、未確認事項。
  7. **次の確認:**担当者、試す変更や問い、再判断に必要な材料。

発言の該当箇所をエビデンスにし、観察の背景は調査者メモに書きます。同じタスクの複数場面を研究課題で結べば、発言ごとに別の知見を作る必要はありません。

4. タスクへの影響で優先度を考える

優先度の基準をチームでそろえます。回避できない停止、何度もやり直す必要のある操作、文言で一瞬迷うことは、異なる影響を持ちます。進行役の助けで失敗が隠れていないか、必須のタスクを妨げていないかも確認します。

「U1にはヒントが必要だった」は「ユーザーはエクスポートできない」より正確です。発生数を記すなら、誰が同じタスクをどの条件で試したかを示します。少人数を目的に沿って選んだ調査から、利用者全体の失敗率は算出できません。

成功例も残します。架空のU2がすぐにエクスポートを見つけたなら、開始画面、利用経験、見える権限を比較します。その違いが、問題の起きる条件を説明するかもしれません。

5. 次のテストにつながる報告にする

検討中の判断とタスクを示し、障害、出典、影響、代替説明、次の確認を続けます。成功した試行や未解決の問いも載せます。

仮のエクスポート問題なら、タスクの指示は中立に保ち、既存の名称とより明確な名称を比べる案が考えられます。自力での発見、質問の有無、選んだ経路、受け渡しに使えるファイルが得られたかを、事前に観察項目として決めます。将来確認する結果を、実現済みの改善として書かないようにします。

ScribeFlashでは出典と照らして知見をレビューし、確認後にレポートへまとめます。発言、観察メモ、提案の区別には人の確認が必要です。整った文章でも、記録されていない動作は補えません。

テンプレートとサンプルを使う

調査テンプレートのユーザビリティテストから、タスクを軸にした問いを準備できます。サンプルプロジェクトと資料は、シミュレーションと明示したデータで証拠から報告までの構造を示します。複数セッションの比較にはインタビュー分析の手順を参照してください。

共有前の確認

各問題にタスク、出典、受けた助け、観察できた結果があるかを確認します。解釈の範囲を限定し、提案は提案と明示し、不要な個人情報を削ります。何が起き、どう解釈し、次に何を試すのかを読み分けられる状態にします。

目的に合う調査テンプレートから始める

解約インタビューやユーザビリティテストを選び、知見と出典を結び付けて整理します。

ユーザビリティテスト問題報告観察エビデンス
ScribeFlash ブログ
ユーザビリティテストの報告:観察・解釈・提案を分ける | scribeflash