ユーザビリティテスト設計の観点

ユーザビリティテスト実施時には、「イントロダクション」→「シナリオ」→「タスク」の順にスクリプトを使用しますが、作成時には逆の順番で設計していくと考えやすいです。
スクリプト(テスト当日の進行をまとめた台本)は、被験者がどう受け取るかを考えながら作成しましょう。文章は明確に記載し、誤解を与えないように配慮しましょう。

ユーザビリティテストの構成

ユーザビリティテストのスクリプトは、以下で構成されます。

スクリプト説明
イントロダクションテスト実施直前に被験者に対して問いかける簡単な質問
シナリオ被験者がアプリケーションを操作するための、仮想の状況設定
タスク観察したい操作・行動を被験者にしてもらうための、擬似的な仕事

タスク作成時の観点

タスクは被験者に特定の操作をしてもらうために指示する文章です。単純に「操作をしてください」では、機械的な作業になってしまいます。被験者が自発的に考えて検証したい操作や行動をするように導くのが、タスクの役割です。

スタートとゴールを決め、主要なタスクに絞り込む

検証内容をもとに、特定の操作をタスクにしていきます。ゴールにたどり着くまでに必要な操作を、被験者が画面を見ながら考える程度の情報量で書きます。

検証内容の一番の関心事は「被験者がタスクを達成できるか」なので、その様子が観察できるようにスタートとゴールを決め、タスクを全部で3工程くらいに収めます。
このとき、どの画面からスタートするかの開始状態と完了状態を必ず決めておきます。使い始める画面を決めておかないと、想定した経路を通らずにゴールに到達してしまう可能性があります。また、ゴール(完了状態)を決めておかないと、タスクが達成できたかの判定がつきません。

ポイント

  • 「ボタンを押してください」など、具体的な操作を指示しない
  • 実際の業務と同じように、操作に必要な部署や従業員などにも具体的な名前を決めた状態で、擬似的な仕事の指示を作成する

ゴールから遠ざかってしまった場合を想定しておく

被験者がタスクの完了から遠ざかるような操作もあらかじめ想定し、準備をしておきましょう。テストの離脱とみなす操作を事前に決めておき、そのタイミングで被験者をどのようにリカバーするかも考えておきます。

タスクを確認する

必ず、検証内容が観察できるタスクになっているかを確認しておきましょう。

タスク例:

例1:従業員情報と部署マスターを予約する。
- 渡された人事情報で予約を登録してください。
- 人事情報は、別紙を参照してください。
- 適用日は10/1にしてください。
- (補足)別紙にて予約する情報を記載する
例2:部署マスターの予約に、他の部署の変更を追加する。
- 10/1に部署を新設することになりました。
- 部署マスターに部署を追加してください。

シナリオ作成時の観点

シナリオは、被験者に自発的な行動を促すために与える仮想の状況・背景です。

実際の業務であれば、利用者には機能を使う具体的な目的があり、自発的に操作しますが、テストにはありません。 被験者が能動的にプロダクトを操作する様子を観察するために、状況設定をシナリオ形式で用意します。

ポイント

  • 被験者の立場や日ごろの業務を明確にする
  • 具体的な状況を想像し、仕事を依頼するときと同様に考える

シナリオ例:

あなたは〇〇〇〇会社の人事労務担当者です。
社内の人事情報をSmartHRに反映する業務を行なっています。
SmartHRでは事前に人事情報を登録して適用日に反映できるようになりました。
ちょうど上司から「組織の配置変更に合わせて、事前に共有された資料を元に部署、役職などの従業員情報を
更新してほしい」と人事情報を渡されました。
新しい機能を使って予約を登録してみましょう。

イントロダクション作成時の観点

テストを実施する前に被験者に簡単な質問をしましょう。 本題に入る前に、中立のトピックで会話をし、安心して話せる関係性を築きます(ラポールの形成)。

被験者が普段どのように機能を使っているかは、本来はスクリーニング時に確認しておくべき内容ですが、テスト前にも会話しておくと、普段の操作とテストのギャップを認識しながら観察できます。

例:

従業員情報を未来の日付で更新する場合にどのような作業をされていますか?
組織変更によって部署に変更が入ったらどのようにSmartHRに反映しますか?