テスト NEW
「いいですね」と言われたテストは、何も検証できていない——褒め言葉を行動の記録に置き換える5つの手順
プロトタイプのテストで「使いやすそう」「これなら欲しい」と言われ、全員が笑顔で終わった。それでも次の改善点が1つも出ないなら、検証は成立していない。褒め言葉と行動の記録を分け、テスト結果を意思決定に使える形にする手順を、架空の場面で順に示す。
6分で読める
プロトタイプのテストを5人に実施した。画面を見せて感想を聞くと、「分かりやすいです」「これなら使いたいです」という言葉が続く。チームは手応えを感じて、報告資料に「ユーザー評価は良好」と書いた。
ところが翌週、開発が始まると、誰も説明していない場所で使い方に迷う人が出てくる。テストでは、迷う人は1人もいなかったはずである。
テストで褒められたことと、プロトタイプが検証されたことは別である。 本稿では、褒め言葉が出たテストで何が起きているのかを整理し、結果を意思決定に使える形へ変える手順を示す。以下の場面は、説明のために作った架空のものだ。
テスト全体の設計はユーザーテスト手法5選にまとめてある。ここでは、実施したあとの結果の読み方に絞る。
褒め言葉が検証にならない理由
理由1：悪く言いにくい
テストの場には、プロトタイプを作ったチームの人がいる。協力してくれた参加者は、その人の前で「分かりにくい」とは言いにくい。好意的な感想は、プロトタイプの出来より、場の空気を映していることが多い。
理由2：感想は印象にすぎない
画面を見て「分かりやすい」と答えることと、実際に目的のボタンを探して押せることは違う。画面を見た感想は印象を表し、ボタンを押せたかどうかは行動を表す。購入や申し込みを決めるのは行動のほうなので、検証したいのも行動のほうである。
理由3：「欲しい」は無料
「これなら使いたい」と言うのに、参加者は何も支払わない。時間やお金、乗り換えの手間などを負担せずに言える。費用のかからない返事は、実際の行動を予測する力が弱い。
置き換える5つの手順
手順1：失敗の基準を書く
架空の例として、定期購入の解約画面を試作したチームを考える。感想を聞く前に、「解約の入口を30秒以内に見つけられなければ失敗」「途中で2回以上画面を戻ったら失敗」と基準を書いておく。基準を先に決めると、あとから結果を都合よく読めなくなる。
手順2：先に操作してもらう
参加者に「この画面で、解約の手続きをしてください」と頼み、黙って見る。説明はしない。迷った場所、手が止まった時間、押し間違いを記録する。シンクアラウドプロトコルで考えていることを声に出してもらうと、迷いの理由まで残せる。感想は、操作のあとで初めて聞く。
手順3：観察と意見を分ける
メモは2つの列に分ける。
| 観察（起きたこと） | 意見（言われたこと） |
|---|---|
| 解約ボタンまで42秒かかった。設定画面を2回開いた | 「分かりやすかったです」 |
| 確認画面で「戻る」を押し、最初からやり直した | 「特に迷いませんでした」 |
左の列と右の列が食い違う行が、最も学びの多い場所である。この例では、意見は「迷わなかった」と言い、観察は「迷った」と示している。 食い違いを消さずに残すことが、褒め言葉に流されないための要点になる。
手順4：行動を質問に変える
観察で見つけた迷いを、操作のあとに質問へ変える。「先ほど設定画面を2回開かれましたが、何を探していましたか」と聞く。「どう思いましたか」より、起きた事実について聞くほうが、参加者は具体的に答えられる。
手順5：次の改善を決める
テストの最後に、チームで「次に直す箇所」を最低1つ決める。1つも決まらないなら、プロトタイプが完璧なのではなく、見ている場所が足りない可能性が高い。テストカードに、次の検証で何を確かめるかを書き残しておく。
使うときの注意
- 人数を増やしても、感想だけのテストは同じ偏りを持つ。 先に増やすべきなのは、操作の観察である
- 褒め言葉をすべて捨てる必要はない。 好意的な反応は、どの場面で出たかを記録すれば、手がかりになる
- 基準は小さく始める。 最初から多くの項目を測ろうとせず、迷いの有無と所要時間の2つから始めれば運用しやすい
まとめ
- 褒め言葉は、場の空気や費用のかからない返事を映すことが多く、検証の根拠として弱い
- 操作を先に観察し、感想はあとで聞く
- 観察と意見を2列に分けて記録し、食い違う行を学びとして扱う
- テストの終わりに、次に直す箇所を最低1つ決める
最初の一歩は、感想を聞く前に「迷ったら失敗」の基準を1行書くことである。