プロトタイプを作った。チームは「いい感じだ」と思っている。だが、 ユーザーの前に出した瞬間に崩れる前提 が必ずある。ユーザビリティテストは、その前提を壊すための手法である。

なぜ5人で十分なのか

「もっと大勢に聞かないと信頼できないのでは」——ワークショップでよく出る質問だ。Jakob Nielsen の研究（2000年）が明快な答えを出している。 5人のテストで、ユーザビリティ問題の約85%が発見できる 。15人に増やしても発見率は100%に届かず、コストだけが膨らむ。

重要なのはサンプル数ではなく、 テストの回数（イテレーション） である。5人でテストし、改善し、また5人でテスト。この反復が問題を潰す最短ルートになる。

準備——テスト前に決めること

「全体的な使い勝手を見たい」は目的ではない。 検証したい仮説を3つ以内 に絞る。たとえば「ユーザーは3ステップ以内に申し込み完了まで到達できるか」「エラーメッセージを読んで自力で復帰できるか」のように、観察可能な行動で定義する。

ユーザーに実行してもらうタスクを文書化する。ここで手を抜くと、テスト当日に何を見ればいいか分からなくなる。

理想は実際のターゲットユーザーだが、完璧を待つ必要はない。 「近い属性の人」で十分 スタートできる。社内の別部署のメンバー、知人、家族でもプロトタイプ初期段階なら有効な発見がある。

ただし1点だけ絶対に守るべきルールがある。プロジェクトに関わったメンバーをテスターにしてはならない。文脈を知っている人間のフィードバックは、ほぼ役に立たない。

導入（5分） ——テスターに「あなたをテストしているのではなく、プロトタイプをテストしている」と明確に伝える。これを省くと、テスターが正解を探そうとしてしまう
タスク実行（20〜30分） ——タスクシートに沿って順番に実行してもらう。 「考えていることを声に出してください」 と依頼する（思考発話法）
事後インタビュー（10分） ——タスク中に気になった行動について掘り下げる。「さっき一瞬止まりましたが、何を考えていましたか？」のように具体的に聞く

実際にやってみると、ファシリテーターが最もやりがちなミスは「助けてしまう」ことだ。テスターが操作に詰まると、つい「そこは右上のボタンを」と言いたくなる。だが、 その沈黙こそが最も価値のあるデータ である。

テスト終了後、記録係の記録とファシリテーターの所感を突き合わせる。以下の3つに分類すると整理しやすい。

5人中3人以上が同じ箇所でつまずいた場合、それは個人の問題ではなく 設計の問題 である。逆に1人だけが困った問題は、優先度を下げてよい。

クリティカルな問題から対処する。全部を一度に直そうとすると、何が効いたのか分からなくなる。 1サイクルで直すのは3つまで 。修正したら再テストで効果を検証する。

ワークショップでよく起こるのは、テスト結果を「自分たちの解釈」で歪めてしまうことだ。テスターが「分かりにくかった」と言ったのに、「慣れれば大丈夫」と片づけてしまう。これではテストした意味がない。

もうひとつの典型的な失敗は、テスト結果を報告書にまとめて終わりにすること。ユーザビリティテストのゴールは報告書ではない。 プロトタイプの改善とその検証 である。テストから改善までの期間は短いほどよい。理想は同じ週のうちに修正して再テストすること。

ユーザビリティテストは、デザイン思考のテストフェーズの中核をなす手法である。5人で始め、改善し、また5人でテストする。この反復が、ユーザーにとって本当に使えるプロダクトを生み出す。

完璧なプロトタイプを作ってからテストするのではなく、 不完全な段階でこそテストする 。紙のプロトタイプでも、手描きのワイヤーフレームでも、ユーザーの前に出せば発見がある。まずは5人。まずは1回。手を動かすことから始める。

テスト結果の分析には親和図法（KJ法）を活用することで、複数のテスターにまたがるパターンを素早く発見できます。

Jakob Nielsen & Thomas K. Landauer, “A mathematical model of the finding of usability problems”, INTERCHI ‘93 Proceedings, 1993
Steve Krug, Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability, 3rd edition, New Riders, 2014
Nielsen Norman Group, “Why You Only Need to Test with 5 Users”, nngroup.com, 2000