ユーザビリティテストのタスク例：答えを誘導しない書き方

ユーザビリティテストの課題文は、参加者に目標と必要な状況を伝え、操作の道筋は本人に任せる文章です。期待する結果は、進行役のメモに分けて書きます。確かめたいメニュー名やボタン名、操作手順を課題文で教えてしまうと、画面の分かりやすさではなく、指示に従えるかを測ってしまうことがあります。

ユーザーに試してもらうプロトタイプでは、すべての画面を仕上げる前に、現実的な課題を少数用意します。ここでは業務用の配送ダッシュボードを使い、「週次レポートを用意する」「配送先を変更する」「失敗した書き出しから復旧する」の三つを例にします。それぞれ異なる設計上の判断を確かめる課題です。

調べたいこと、課題文、達成条件を分ける

最初に、まだ分かっていないことを絞ります。「このダッシュボードは使いやすいか」より、「週次レポートを見つけられるか」の方が具体的な行動につながります。参加者向けの課題文では、その情報が必要な理由を伝えます。達成条件には、調べたいことを判断するために観察する行動を書きます。

達成条件では、特定のクリック経路を必須にしていません。画面に別の正当な経路があるなら、それも記録します。参加者が件数を正しく答えても、別の期間を出力していたら、課題全体を成功と扱わないでください。情報を見つけることと、目的に合う資料を用意することは分けて判断します。

Nielsen Norman Groupの課題作成ガイド（英語）は、画面内の用語や指定した手順が参加者を誘導し得ることを説明しています。この観点で課題文を見直しつつ、実際の顧客が知っている言葉まで取り除かないようにします。馴染みのある語をすべて避けると、現実的な課題ではなく謎解きになってしまいます。

答えを教えてしまう指示を書き換える

課題文と実際の画面を見比べ、同じ言葉を拾います。それが利用者も使う業務用語なのか、操作経路を示すヒントなのかを判断してください。「配送先」は顧客自身の言葉かもしれません。一方、社内で付けたメニュー名にしかない「配送設定マネージャー」は、日常的な表現に置き換えた方がよいでしょう。

集計期間、架空の配送先、担当する役割など、参加者が自分で決められない情報は渡します。ただし、長い物語を覚えてもらう必要はありません。個人情報は架空のデータを使い、テスト用のプロトタイプへ本人の金融情報やアカウントの認証情報を入力させないでください。

課題に合う開始状態を用意する

課題文が適切でも、求められた情報がプロトタイプになければテストは成立しません。配送レポートなら、比較できる複数の期間、遅延と予定どおりの配送の区別、選んだ期間と一致する出力を用意します。どの経路でも同じ成功画面に着く構成では、参加者が選択の意味を理解したか分かりません。

課題ごとに、役割、開始画面、既存のデータ、すでに起きたこと、意図的に用意していない機能をメモします。書き出しの復旧を調べる課題なら、失敗または中断した依頼がある状態から始めます。最初に書き出しを成功させてから、別の場所にある失敗を想像してもらう進め方は避けましょう。

各課題を独立させるか、続きのある作業として扱うかも決めます。同じアカウントを使えば準備は簡単ですが、最初の課題で覚えたメニューが次の課題の助けになることがあります。入口の見つけやすさを調べる場合は、適切ならセッション間で課題の順序を変えるか、後の課題ではすでに画面を見ていたことを記録します。事前知識が同じ条件だったかのようには比較しません。

実施前に、進行役の判断をそろえる

各課題について、完了、一部完了、断念、支援ありをどう判断するか決めておきます。進行役が「レポート」の場所を教えた後に正しい資料を取得した人と、自分で見つけた人では結果が異なります。単純な成功のラベルにまとめず、どの助けがあったかを記録します。

声をかけるなら、「今、何を探していますか」「次に何をしようと思いますか」など中立的な問いを用意します。「メニューを試してみましたか」と答えへ誘導しないようにしてください。手詰まりになったときの終了条件は、調査の目的と参加者の負担を踏まえて決めます。どの調査にも同じ制限時間を当てはめるのではなく、進行役が一貫して判断できることが重要です。

観察したことと解釈も分けます。「配送件数を探している間に『請求』を2回開いた」は観察です。「レポートを請求の下へ置くべきだ」は仮説です。必要な変更は、レポートという名称の改善かもしれませんし、関連する場所からのリンクや分類の変更かもしれません。一度の寄り道だけでは正しい解決策までは決まりません。

Pixsoで課題の流れを組み立てる

Pixsoでは、ダッシュボード、対象期間の選択、レポートのプレビュー、書き出しの失敗、取得完了を別々のフレームで用意します。画面をまたいで期間と件数をそろえ、参加者が実際に選びそうな経路を接続してください。間違った領域へ進んだ場合の戻り道も必要です。プロトタイプで再現していない範囲は調査メモへ書き、参加者の画面に操作のヒントを足さないようにします。

設計の議論に参加していない人に、一度試してもらいます。操作前に課題文を声に出して読み、何を達成する必要があると思ったかを説明してもらうと、日付の曖昧さ、足りないデータ、リンクの不備が見つかります。文言が原因なら課題文を、作業できない構成が原因ならプロトタイプを直します。画面の本当の使いにくさを、台本にヒントを加えて見えなくしないようにしましょう。

結果を、次に変える具体的な画面へつなげる

参加者がレポートを見つけても、選んだ週の内容か判断できなかったとします。次に確かめるのはダッシュボード全体の美しさではなく、対象期間の見え方です。プレビューと出力完了の表示に日付範囲を加え、同じ目標で再び試します。期間は理解しているのに別の配送区分を選ぶなら、名称と定義を調べます。

記録は、課題、観察した行動、つまずいた箇所、考えられる理由、変更案の5項目にすると整理しやすくなります。矛盾する観察も消さずに残してください。別の経路で成功した参加者は、排除すべき逸脱ではなく、有用な代替経路を示している可能性があります。複数のセッションから優先度をまとめる方法は、UXリサーチの統合ガイドで詳しく扱っています。

次のセッションも同じ現実の目標から課題を作り、新しい画面の使い方を先に教えないようにします。画面が変わっても、調査を利用者の仕事へ結び付け続けるためです。Pixsoでテストする作業の流れを作る。