ユーザビリティテストのやり方｜設計・タスク・評価指標・分析手順

社内デモでは滞りなく動いた試作品が、初めて触る人の手に渡った途端に止まります。画面右上のボタンが見つかりません。入力後に保存された状態も読み取れないままです。作り手には見慣れた導線ほど、使い手の迷いに気づきにくいものです。

ユーザビリティテストとは、利用者にタスクを実行してもらい、操作上のつまずきを観察する評価手法です。集めるのは「使いやすかった」という感想ではなく、どのタスクを完了し、どこで後戻りし、何を正解だと思って押したかという行動事実です。

ユーザビリティテストとは｜答えられる問いを絞る

ユーザビリティテストが答えるのは、指定した利用者が、指定した状況で、製品や試作品を使って目的を達成できるかです。需要の大きさや購入意向を証明する手法ではありません。

参加者にタスクを渡し、画面・試作品・サービスを操作する様子から問題を見つける評価が、ユーザビリティテストです。質問だけで感想を集める会は含めません。

ユーザビリティテストの方式を選ぶ

進行方法と実施環境は別の軸で選びます。モデレーテッド方式は、対面でも遠隔でも実施できます。

似た手法は、観察する対象で分けます。

「この機能は欲しいですか」と聞いても、購買の証拠にはなりません。操作の観察と本人の意見は別に記録します。

ユーザビリティテストの設計｜参加者募集より先に決める

テスト後の意思決定を先に決め、対象者、評価対象、タスク、判定条件を同じ計画へ固定します。日程と人数から決めると、結果を見ても何を直すか判断できません。

1. 実施後の意思決定：継続、修正、追加確認、保留、中止、次段階への投資のどれを判断するか
2. 判断の運用：判断者、判定日、各分岐の責任者と期限、再テストの予算と時間
3. 確かめる仮説：誰が、どの状況で、何を完了できると見込むか
4. 参加者条件：対象業務の経験、役割、製品の利用経験、除外条件、募集経路
5. 評価対象：試作品の版、端末、権限、利用できるデータ
6. タスクと判定：開始状態、終了状態、完了・失敗・介助ありの定義
7. 記録と同意：画面・音声の記録範囲、観察担当、中断条件、本人同意と社内承認

仮説は「画面が分かりやすい」と置かず、「定期的に経費申請を行う担当者が、説明なしで領収書を登録し、承認依頼まで完了できる」と書きます。

BtoBでは、利用者、管理者、導入推進者、決裁者を同じ参加者条件へまとめません。役割ごとにタスクと募集経路を分けます。人数を増やして、必要な役割の不足を埋めないでください。

ユーザビリティテストのタスク設計｜操作名を答えにしない

テストタスクは、参加者が達成したい状況を示し、使う機能名や正解の手順を隠します。「検索ボタンを押し、条件を設定して候補を保存してください」では、どの操作を使うかまで教えています。

新規取引先を探す架空の業務なら、次のように状況へ置き換えます。

来月から共同開発の候補企業を探します。製造業で、指定地域に拠点を持つ企業を1社選び、あとでチームが確認できる状態にしてください。

タスク文には、開始時点、達成したい結果、業務上の制約だけを入れます。終了条件は参加者に見せず、運営側の判定へ書きます。「候補を保存し、共有一覧に表示されたら完了」「進行役が操作を教えたら介助あり」という具合です。

未実装のボタンを参加者のミスに数えてはいけません。テスト用データ、権限、通知先まで事前に通し、進行担当以外の人がタスク文だけで実行できるか試します。

ユーザビリティテストの実施｜教えずに観察する

進行役は参加者を成功へ導く人ではなく、どこで何を期待し、何が起きて止まったかを見る人です。助けた場合は、その時点で自力完了と分けます。

1. 目的、記録範囲、中断方法を説明し、同意を確認する
2. 対象業務の経験と普段の利用環境を聞く
3. タスクを渡し、操作、発話、停止、介入の時点を記録する
4. タスク後に、迷った箇所で期待したことと判断理由を聞く
5. 記録データの扱いと、参加者が確認できる窓口を案内する

参加者が黙っても、すぐに答えを教えません。「いま何を探していますか」「ここを押すと何が起きると思いましたか」と期待を確認します。操作中の事実と、後から語った理由は分けます。

Jakob Nielsenが2001年に公開した論考も、自己申告より、利用者が実際に何をするかを見る考え方を示しています。

ユーザビリティテストの評価指標｜行動と感想を分ける

成功、効率、つまずき、本人の評価を分けます。同じ低評価でも、未完了と「完了したが不安だった」では修正箇所が違います。

少人数の結果は割合だけにしません。「完了率80%」ではなく「4/5人」と併記し、対象者条件も添えます。この数字は市場全体を推定する比率ではありません。

BtoBでは画面上の完了と業務上の完了を分けます。申請ボタンを押せても、承認者へ通知されない、必要な情報が次のシステムへ渡らないなら、業務は閉じていません。

ユーザビリティテストの参加者数｜5人を固定しない

参加者数は常に5人ではありません。同じ条件の利用者で問題を見つけ、修正後にもう一度試せる単位で決めます。役割や利用状況が異なる参加者を、一つの5人枠へ混ぜないことが前提です。

Nielsenが2000年に公開した問題発見率モデルは、1人の参加者が問題を発見する割合Lを31%と置いています。累積値は1 − (1 − L)^nです。nを5人とすると84.36%になります。

この数値は、同じ評価対象にあるユーザビリティ上の問題を見つけるモデルです。市場でどれだけの人に当てはまるか、需要のある人の割合、購入意向、売上見込み、顧客インタビューの必要人数には転用できません。

参加者を増やし続けるより、同じ条件で試し、問題を直し、次の回で再確認します。経理担当者と営業担当者、初回利用者と熟練利用者のように条件が違うなら、別の群として計画してください。

ユーザビリティテストの分析｜観察事実を修正へつなぐ

分析では、観察事実、業務への影響、原因仮説、修正案、再テスト条件を別の列へ置きます。「分かりにくい」と一語に縮めると、修正の根拠が消えます。

優先度は発生人数だけで決めません。主要タスクを止めるか、誤った情報を確定させるか、自力で回復できるか、特定条件だけで起きるかを見ます。1人だけの問題でも、月次締めを止めるなら先に直す理由があります。

修正案を出した時点で、原因はまだ仮説です。名称変更で直るか、配置を変えるべきかは再テストで確かめます。

BtoBのユーザビリティテストで見落としやすい範囲

BtoBでは、日常の操作だけでなく、初期設定、権限、引き継ぎ、例外処理まで評価範囲を分けます。複数人の受け渡しがあるなら、「担当者が申請し、承認者が差し戻し、担当者が修正する」という一連のタスクも必要です。

• 使えるか：ユーザビリティテストで完了・迷い・誤操作を見る
• 必要か：課題が起きた過去の状況と代替手段を聞く
• 買われるか：予算、決裁、契約、導入条件を関係者へ確認する
• 提供できるか：データ連携、運用負荷、支援体制をPoCで確かめる

一つのテスト会で4つすべてに結論を出しません。操作上の問題が減っても、課題仮説や事業性が正しいとは限りません。

まとめ｜ユーザビリティテストは次の修正判断まで進める

ユーザビリティテストの成果は、好意的な感想ではありません。どのタスクを妨げた何を、どの順で直し、何を再確認するかを決めた状態です。

対象者の役割と経験をそろえ、操作名を隠したタスクを渡し、完了、所要時間、誤操作、介助、自己評価を分けて記録します。分析では観察事実と原因仮説を混ぜず、修正後に同じ条件で再テストしてください。

5人という人数も、先に見たNielsenの問題発見率モデル上の計算から出た値で、固定の推奨人数ではありません。需要、購買、提供可能性は別の検証へ分けます。