ユーザビリティテストのやり方｜5人で足りる理由と、改善につながる記録の取り方

人に見られていると、緊張して行動が変わる。いつもなら勢いで押すボタンも、誰かが見ているだけで一度よく読んでから押す。冷蔵庫を開けて何を探していたか忘れたときでさえ、後ろに人がいると目的が続いているような顔をしてしまう——観察する人は透明人間にはなれません。だから人が少しよそ行きになる前提で、それでもどこで止まり、戻るかを残すのです。
題材は、筆者が企画からテストまで担当した飲食店の予約アプリ。教科書どおりのテストが役立つ場面もあれば、指摘を直しても実際の使われ方が変わらない場面もあった。テストの準備と進め方、5人という人数の意味、そして記録の単位を一箇所だけ変えた話です。

ユーザビリティテストは製品を使ってもらい、感想だけでなく「迷う・止まる・戻る」という動きを見る評価です。作り手は構造も言葉の意味も知っていますが、初めて使う人にはその前提がない。説明を読まなかった人が悪いと片づける前に、読まなくても進める構造だったかを見ます。
「使いやすさを見たい」では範囲が広すぎる。「初めて来た人が目的の申込みを始められるか」まで絞ると、入口のどこを観察すればいいかが決まります。タスクは「右上の申込みボタンを押してください」では正解を教えている。「条件に合う申込み方法を探してください」と目的を渡す。対象者は年齢や所属だけでなく行動の経験・普段の端末・困っている状況で選び、製品を知る社員は顧客の代わりにしない。
人数は5人がよく目安になりますが、これは少人数で問題を見つけ、直してまた試すための目安。少人数の完了率は市場全体の割合ではなく、定量調査の必要人数は別に設計します。完成を待つ必要もなく、紙やクリック試作で確かめられる問いに絞る。パイロットで進行を確かめ、当日は進行役と記録係を分け、思考発話法で考えていることを声にしてもらい、沈黙したら「今、何を見ていますか」と尋ねる（答えは教えない）。助けないことと放置することは違うので、観察したい事実が取れたら最低限の案内で次へ進む救済条件も先に決めます。修正して同じ重要タスクで再テストするところまでが工程です。

予約アプリでは、店を探して予約してもらうと言葉の誤解や戻る動きが見つかり、観察し、記録し、直す流れはちゃんと機能していました。指摘リストが長くなるほど改善した気になり、完了の印も増える。操作は最後まで通り、テスト中の反応も悪くない。それなのに本番へ置くと、日常の予約行動にならなかった。質問を増やしメモを細かくしても、利用されない理由には近づかなかったのです。
思い出したのは以前作った社内向けRAG。検索精度は約95%まで上がり、デモでは評価され操作も完遂できたのに、本番に置いて1か月でアクセスはほぼゼロ。普段の画面から遠く、返答を待つ必要があった。デモでは「今から検索する」という目的が渡されるが、本番では別の仕事の途中に遠い画面へ移動して待つかを自分で選ぶ。自社の荷物サービスOhBagの経験も重なります。ホテルの客室で実証したとき、利用を動かしたのはフロントの声かけではなく客室のドアノブの掲示とテーブルのシールで、掲示施策のあとダウンロードは200〜300%増えた。画面の中だけでなく、その前に知ってもらう場所が見えてきたのです。
原因は、タスクを渡すと「今日は使わない」「別の方法で済ませる」という選択が取りにくくなること。テストは与えた目的を達成できるかには答えたが、普段の行動で採用されるかにはまだ答えていなかった。完遂したのに使われないなら、追加の指摘より先に本番のログや現場を見て、普段の導線・待ち時間・別の選択肢を別の問いとして観察します。

筆者が変えたのは手法の名前でも質問の数でもなく、記録の単位です。意見ではなく、行動が止まった箇所を一件として残し、感想は消さずにその行動にひもづける。「説明が長い」と言われてもそれだけでは改善案にせず、どのタスクのどの画面でスクロールが止まり戻ったかを残す。同じ停止に複数の感想が付いていれば問題は一つかもしれないし、誰も不満を言わなくても目的の直前で止まったなら改善候補。発言の数だけでは順位を付けません。
シートは「タスク・止まった箇所・その場の行動・直す仮説」。事実、発言、解釈、修正案を別の欄に分けます。「確認画面から入力画面へ戻った」が事実、「選択結果を確信できない」は原因の仮説、「確認画面へ選択条件を表示する」が修正案。「困惑した」は観察者の解釈で、「同じ文を読み直した」なら観察した動きです。修正案に別の人が反対しても、観察した事実まで消す必要はない。報告も件数ランキングから「店を探して予約する流れ」に変わり、不満が多い画面ではなく目的の行動を妨げた画面として話せます。
優先するのは目的を達成できない問題、次に繰り返しと後のタスクへの影響。最初に試す変更は一つに絞り、選ばなかった案も採用条件とともに残す。直したあとは同じ募集条件とタスクで前に止まった場所を通過できたか、別の迷いが生まれていないかを確認します。この記録は意見の回収より時間がかかるので、重要なタスクを絞り、停止の前後を丁寧に残すのです。

ユーザビリティテストは感想を聞く場ではなく、目的の操作で迷い、止まり、戻る行動を見る場。そして操作できたことは、日常で選ばれる証明ではありません。使いにくさの解消と、使う理由の創造を分けながら、少人数で早く試し、止まった箇所を直し、もう一度見る。次のテストでは指摘の数より、一つのタスクのどこで手が止まったかを残してみてください。手法の使い分けや評価の指標、費用と期間の考え方は元記事に載っています。