「設定をクリックして同僚を追加してください」という指示は、参加者にインターフェース上のルートを直接教えてしまいます。ユーザビリティテストの目的が「そのルートを自力で見つけられるか」を検証することなら、この指示は検証したい重要な問いの答えをあらかじめ明かしてしまっていることになります。代わりにタスクシナリオでは、状況と達成したい結果だけを伝え、どうやってそこへ辿り着くかは参加者自身に委ねます。
たとえば、架空のプロジェクト管理ツールの場合はこうなります。「月曜日に新しい同僚がプロジェクトに加わります。チームの仕事内容を確認できるように、その人にプロジェクトへのアクセス権を付与してください」。このシナリオは、メニューやボタンの名称を挙げずに行動する理由だけを与えるため、参加者が画面上の選択肢をどう解釈するかを観察できます。
参加者の状況に立って書く
まずは、対象者にとってリアリティがあり、調査の目的に沿ったゴールを設定することから始めましょう。管理者にとっては自然なタスクでも、レポートの閲覧しかしない人には馴染みがない場合があるため、同じ指示が両方に適しているとは限りません。タスクが意味を持つように、参加者の役割と前提となる状況を明確に設定します。
実際のユーザーがすでに持っているはずの情報も含めてください。電車の切符を予約する人には目的地と日時が必要ですし、サブスクリプションを選ぶ人には何人の同僚がそれを使うのかという情報が必要です。こうした詳細が欠けていると、参加者が自分で状況を作り出さなければならなくなり、生じた問題がプロダクトに起因するのか、タスクの曖昧さによるものなのかが判断しにくくなります。
Nielsen Norman Groupによるタスクシナリオのガイダンスでは、現実的なゴールをテスト用のプロンプトに落とし込む方法が解説されています。大切なのは、参加者がわざわざ記憶しなければならないような長文にすることなく、行動を起こすのに十分な文脈を提供することです。
UIの名称を答えにしない
「『メンバーを招待』ボタンを使ってください」という指示と、先ほどの同僚へのアクセス権付与の例を比べてみてください。前者は指定された指示に従えるかをテストするものですが、後者は正しいルートに気づけるかを観察する余地を残しています。この違いはツリーテストでも重要で、タスク文の中でナビゲーションのラベルをそのまま繰り返すと、分かりにくいラベルであっても簡単に見つけられているように見えてしまいます。
「これは簡単なタスクです」や「多くの人がここで迷います」といった、参加者の感情を誘導するような表現は避けてください。難易度の評価が必要な場合は、タスクの実行後に一貫した質問を使って回答を集めます。タスクの文言であらかじめ評価を提示してはいけません。
もちろん、すべての調査で手順の指示を避けるべきというわけではありません。マニュアルやガイドの分かりやすさを検証する調査では、指示通りに行動できるかを意図的にテストすることもあります。ただし、それは「自力での見つけやすさ（ディスカバラビリティ）」をテストする目的とは異なるため、目的に応じた文言を設定する必要があります。
調査を実施する前に「達成基準」を定義する
参加者に見せるシナリオと、リサーチャーの採点基準は目的が異なります。先ほどの同僚へのアクセス権付与タスクなら、招待フォームを開いた段階、意図通りの権限を設定して招待を送信した段階、あるいはサポートを受けてようやく完了できた段階などをリサーチ計画で区別しておくことができます。どの結果を成功と見なすかを事前に決め、サポートの有無を一貫した基準で記録しましょう。
プロトタイプやテスト環境がタスクに対応しているかも確認してください。リサーチャーがプロトタイプの動作範囲を把握していないと、未実装なだけの部分がユーザビリティの課題に見えてしまうことがあります。また、複数のゴールが混ざっている場合は、達成度や難易度を明確に判断できるように、タスクを分割すべきか検討してください。
本番と同じ形式でパイロットテストを行う
本調査に入る前にシナリオを試してみて、どのように理解されるかを観察しましょう。モデレーターなしのセッション（非同期テスト）では、その場での補足説明がなくても意図が伝わる文言でなければなりません。また、モデレーターがいるセッションでも、参加者によって曖昧なタスクの助け舟の出し方がブレてしまわないように注意が必要です。
文言だけでなく、タスクの順序も見直しましょう。前のタスクをこなすことで後のタスクに必要な場所が分かってしまい、比較結果に影響を与えることがあります。そうした影響を考慮してタスクの順序やローテーションを計画し、その意図を記録しておきましょう。より包括的なユーザビリティテストのガイドではタスクを調査全体にどう組み込むかを解説しており、プロトタイプテストでは未完成のデザインを扱う際の制約事項について取り上げています。
}