ユーザーテストの進め方 — プロトタイプの反応を正しく読む

プロトタイプを作った。顧客に見せた。「いいですね」と言われた。

これで検証は成功か。いや、まだ何もわかっていない。

ユーザーテストの目的は、プロトタイプの「評価」ではない。「学び」だ。プロトタイプを通じて、仮説が正しいのか間違っているのかを確かめる。「いいですね」は学びではない。行動と文脈を読んで初めて、事業判断に使えるデータになる。

この記事では、ユーザーテストの進め方を設計から解釈まで4つのステップで整理する。

ユーザーテストの目的を間違えない

まず前提を揃える。ユーザーテストは「プロダクトの出来栄えチェック」ではない。

新規事業における仮説検証のユーザーテストでは、問いはこうだ。「この解決策で、顧客の課題は本当に解決するか」。プロトタイプはその問いに答えるための道具にすぎない。

テスト結果が「好評」か「不評」かは重要ではない。重要なのは、仮説のどこが合っていて、どこがズレていたか。この学びがなければ、テストをやった意味がない。

→ 仮説検証とは何か — 新規事業で「正解」を見つけるプロセス

テスト設計の4ステップ

ステップ1: 検証したい仮説を明確にする

「とりあえず触ってもらおう」は最も多い失敗パターンだ。

テストの前に、検証したい仮説を1〜3個に絞って明文化する。

例:

• 「ユーザーは初見でこの画面の操作方法を理解できる」
• 「ダッシュボードのデータを見て、次のアクションを判断できる」
• 「この機能に月額3万円の支払い意欲がある」

仮説が明確でないと、テスト中に何を見ればいいかわからない。終わった後に「なんとなく良さそうだった」しか言えない。それは検証ではなく感想だ。

ステップ2: タスクを設計する

仮説をもとに、ユーザーに実行してもらうタスクを設計する。

「自由に触ってみてください」ではダメだ。検証したい仮説に対応する、具体的な操作タスクを用意する。

例:

• 「このツールを使って、先月の売上データから上位3カテゴリを見つけてください」
• 「新規の発注書を1件作成してください」

タスクの設計で重要なのは、答えを教えないこと。「左上のメニューから売上レポートを開いて...」は操作説明であってタスクではない。目的だけ伝えて、手段はユーザーに委ねる。

→ プロトタイプの種類と使い分け — ペーパー・Figma・コード

ステップ3: 実施する

テストの実施は45〜60分が目安だ。構成はこうなる。

実施時の鉄則は3つ。

1. 説明しない。 プロトタイプの使い方を先に説明しない。「触ってみて、何をするものか理解できますか？」から始める。説明した瞬間、UIの直感性は検証できなくなる。

2. 思考発話法を使う。 「操作しながら、考えていることを声に出してください」と伝える。ユーザーの頭の中が見える。「えっと、ここを押すのかな...違う？あ、こっちか」。この迷いこそがデータだ。

3. 助けない。 ユーザーが詰まっても、すぐにヒントを出さない。30秒待つ。どこで詰まり、自力でどう解決しようとするか。それが課題の発見につながる。

ステップ4: 結果を解釈する

ここが最も重要で、最も難しい。

テストの結果は「成功/失敗」ではなく、仮説に対する学びとして整理する。

• 仮説A「初見で操作方法を理解できる」→ 5名中2名が最初の画面で迷った。ナビゲーションの改善が必要
• 仮説B「データから次のアクションを判断できる」→ 全員がグラフを見た後にアクションを起こせた。仮説は支持された
• 仮説C「月額3万円の支払い意欲がある」→ 3名が「1万円なら」と回答。価格設定の再検討が必要

→ N1分析で新規事業の仮説を確信に変える方法

反応の読み方 — 言葉と行動のギャップを見抜く

ユーザーテストで最も危険なのは、言葉を額面通りに受け取ることだ。

ポジティブバイアスを見極める

人は目の前の相手に否定的なことを言いにくい。特に日本のビジネスシーンでは、「いいですね」「使いやすいです」が社交辞令として出やすい。

これをそのまま「好評だった」と報告するのは危険だ。

見るべきは言葉ではなく行動。以下のシグナルに注目する。

ポジティブなシグナル（行動）:

• タスクを迷いなく完了した
• 自分の業務に当てはめて具体的に話し始めた（「うちのチームなら、ここで〇〇を入力して...」）
• 使い終わった後に「いつから使えますか？」と聞いてきた

ネガティブなシグナル（行動）:

• タスク完了に時間がかかった、または完了できなかった
• 操作中に何度も「これで合ってますか？」と確認した
• 感想を聞かれて「いいと思います」とだけ答え、具体的な活用イメージが出ない

言葉と行動が矛盾するとき

「便利ですね」と言いながら、タスクの完了に5分かかっている。言葉はポジティブだが、行動はネガティブだ。

このとき信じるべきは行動の方。言葉は意識的にコントロールできるが、操作中の迷いや時間は嘘をつかない。

→ 顧客インタビューの進め方 — 準備から分析までの完全ガイド

5名テストで80%の課題が見つかる

「何名にテストすればいいのか」。答えは5名だ。

ヤコブ・ニールセンの研究によれば、ユーザビリティテストでは5名のテストで約80%の課題が発見される。6人目以降は、すでに発見された課題の繰り返しが増え、新規発見の効率が急激に下がる。

つまり、50名にテストする必要はない。5名で十分、事業判断に使えるレベルの学びが得られる。

ただし条件がある。5名が同じターゲットセグメントであること。製造業の現場担当者3名とIT企業の経営者2名を混ぜて「5名にテストした」では意味がない。同じ課題を持つ、同じ属性の5名だ。

→ ペルソナ設計の実践 — ターゲット顧客を具体化する方法

大企業での実施ポイント — 社内デモとユーザーテストを混同しない

大企業の新規事業で最もよくある失敗が、社内デモとユーザーテストの混同だ。

社内デモとユーザーテストは目的が違う

社内デモでは「うちの部門でも使えそうだ」「デザインをもう少し洗練させて」というフィードバックが出る。これは事業判断の材料ではない。社内の意見だ。

ユーザーテストでは「ターゲット顧客がこの機能を使って課題を解決できたか」を確認する。社内の人間はターゲット顧客ではない。

大企業で陥りがちな罠

罠1: 社内の偉い人の意見でプロトタイプを変える。 部長が「この画面は青がいい」と言った。青に変える。これはユーザーテストの結果に基づく改善ではなく、社内政治だ。

罠2: 社内デモの好評をユーザーテストの成功と混同する。 「役員に見せたら好評だった」は、顧客の反応とは無関係。役員はターゲット顧客ではない。

罠3: テスト結果を「成功」として報告しようとする。 ユーザーテストに成功も失敗もない。あるのは学びだけだ。「5名中3名がタスクを完了できなかった」は失敗ではなく、改善すべき箇所が明確になったという成果だ。

→ AIプロトタイピングで検証を加速する — 3日でプロトタイプを作る方法

まとめ

ユーザーテストの進め方は4ステップだ。

1. 検証したい仮説を明確にする。 仮説がなければテストではなくデモになる
2. タスクを設計する。 自由に触らせるのではなく、仮説に対応するタスクを渡す
3. 実施する。 説明しない、助けない、思考発話法で頭の中を見る
4. 結果を解釈する。 言葉ではなく行動を見る。ポジティブバイアスに騙されない

5名でテストすれば80%の課題が見つかる。50名は要らない。そして、社内デモとユーザーテストは別物だ。顧客の行動データだけが、事業判断の根拠になる。

LITMUSは、新規事業の検証に特化したスタジオです。プロトタイプ設計からユーザーテストの実施・分析、事業判断レポートまで一気通貫で提供します。

50万円から始められるEntry Moduleもあります。詳しくは LITMUS をご覧ください。