「使いやすいと思って作ったのに、ユーザーが全く使えない」——この経験をしたことがないデザイナーはいないでしょう。
開発者やデザイナーは製品に詳しすぎるため、初めて使うユーザーがどこでつまずくかを自分たちだけで発見するのは構造的に不可能です（知識の呪い）。ヒューリスティック評価や専門家レビューでは見落とす「実際の行動」を捉える唯一の方法が、ユーザビリティテストです。
この記事でわかること
- ユーザビリティテストの定義と「5人で85%」の理論的根拠
- 実施前の準備（タスク設計・リクルーティング・環境構築）
- テスト中の観察ポイントと思考発話法の使い方
- 結果の分析・優先順位付け・改善サイクルへの接続
1. ユーザビリティテストとは（定義）
ユーザビリティテスト（Usability Testing）とは、実際のユーザーに製品やプロトタイプを使ってもらい、その行動を観察することで使いにくい点や問題点を発見する評価手法です。
ユーザーの「意見」ではなく「行動」を見ることが本質。「使いやすいですか？」と聞くのではなく、タスクを与えて黙って観察することで、言語化できない課題を浮き彫りにします。
2. いつ使うか（適用場面）
特に重要になるケース
- プロトタイプ完成時: リリース前に致命的な問題を発見・修正できる
- 既存製品の改善: 離脱率が高いページ・機能の原因を特定
- 大規模リニューアル前: 現行版の課題を洗い出し、改善の優先順位を決定
- 新機能追加時: 既存の操作フローと矛盾しないか検証
避けるべき状況
- コンセプト検証段階: 「何を作るか」が決まっていない段階では、ユーザーインタビューが先
- 統計的な裏付けが必要な場合: 定量データが欲しいならA/Bテスト
3. なぜ重要か（設計判断の核）
ユーザビリティテストは「答え合わせ」ではなく「発見」のために行う。
5人で85%の問題が見つかる理由
ヤコブ・ニールセンの研究によれば、5人のユーザーでユーザビリティ問題の約85%を発見できるとされています。これは代表的な目安であり、製品の複雑さやユーザー層の多様性によって必要人数は変わります。
| ユーザー数 | 発見できる問題の割合 |
|---|---|
| 1人 | 約31% |
| 3人 | 約65% |
| 5人 | 約85% |
| 10人 | 約95% |
これは「同じ問題に複数のユーザーがつまずく」という事実に基づいています。5人を超えると、同じ問題の再発見が増え、費用対効果が下がります。
設計判断としての基準
- 行動 > 意見: ユーザーが「使いやすい」と言っても、実際に迷っていたら問題
- 早期発見 > 完璧な準備: 未完成のプロトタイプでも早くテストする方が価値が高い
- 質 > 量: 5人×3ラウンドの方が、15人×1ラウンドより多くの問題を修正できる
4. 具体の設計ルール（チェックリスト）
最低ライン（Must）
理想ライン（Better）
5. 実施手順（ステップバイステップ）
STEP 1: 目的とタスクの設計
| 要素 | 悪い例 | 良い例 |
|---|---|---|
| 目的 | 使いやすさを確認したい | 商品検索から購入完了までの離脱ポイントを特定したい |
| タスク | サイトを自由に使ってください | 「予算5,000円以内の赤いスニーカーを探して購入手続きを完了してください」 |
STEP 2: 参加者のリクルーティング
- ターゲットユーザーに近い人: 既存顧客、または属性が近い人
- 5人を目安: 予算・時間に応じて3〜8人
- 謝礼を用意: Amazonギフト券3,000〜5,000円程度が相場
STEP 3: テスト環境の準備
- 対面テスト: 静かな会議室、録画機材、プロトタイプ
- リモートテスト: Zoom + 画面共有、録画許可、事前のツール動作確認
STEP 4: テストの実施
- 導入（5分）: 目的説明、同意取得、「正解はない」「製品をテストしている」と伝える
- タスク実行（20〜30分）: タスクを1つずつ提示、思考発話を促す
- デブリーフィング（10分）: 全体の印象、特に困った点をヒアリング
STEP 5: 分析と優先順位付け
発見した問題を「重大度 × 頻度」でマトリクス化し、優先順位を決定。
| 重大度 | 頻度高（3人以上） | 頻度低（1〜2人） |
|---|---|---|
| 高（タスク失敗） | 🔴 最優先で修正 | 🟠 次回リリースで修正 |
| 中（大幅に遅延） | 🟠 次回リリースで修正 | 🟡 バックログ |
| 低（軽微な混乱） | 🟡 バックログ | ⚪ 様子見 |
6. よくある失敗パターン
❌ ファシリテーターが助けてしまう
ユーザーが迷っていると、つい「ここをクリックしてください」と言いたくなる。しかし助けた瞬間、そのデータは汚れる。
対策: 「あなたが迷っていること自体が貴重なデータです」と事前に伝えておく。
❌ 「使いやすかったですか？」と聞いてしまう
ユーザーは気を使って「はい」と答える。でも実際にはタスクに失敗している。
対策: 意見ではなく行動を見る。タスク成功率と所要時間を記録する。
❌ タスクが曖昧
「サイトを自由に使ってください」では、何を見ればいいかわからない。
対策: 「予算5,000円以内の赤いスニーカーを探して購入してください」のように、具体的なゴールを設定する。
❌ 3人で終わりにしてしまう
時間がないからと、3人で終わりにすると、目安として約35%の問題を見落とす可能性がある。
対策: 可能な限り5人を目標に。時間がないなら1人30分×5人 = 2.5時間で十分。
7. おすすめツール
リモートテスト
| ツール | 特徴 | 料金 |
|---|---|---|
| Maze | プロトタイプテストに特化、Figma連携 | 無料プランあり |
| UserTesting | 大規模なパネル、動画録画 | 有料 |
| Lookback | ライブ観察、メモ機能 | 無料プランあり |
対面テスト
| ツール | 用途 |
|---|---|
| Zoom | 画面共有 + 録画 |
| OBS Studio | ローカル録画（無料） |
| Notion / Miro | 観察メモの共有 |
8. テンプレート
テストスクリプト
【導入】（5分）
「今日はありがとうございます。これから○○という製品のテストを行います。
いくつかタスクをお願いしますが、正解はありません。
テストしているのは製品であって、あなたではありません。
できれば、考えていることを声に出しながら操作してください。
私は基本的に口を出しませんが、それはあなたが間違っているからではありません。
録画の許可をいただけますか？」
【タスク1】（10分）
「予算5,000円以内の赤いスニーカーを探して、購入手続きを完了してください」
[観察メモ]
- クリックした場所:
- 迷った場所:
- 時間:
- 成功/失敗:
【デブリーフィング】（5分）
「全体的にどうでしたか？」
「特に迷った点はありましたか？」
「この製品を使うとしたら、どんな場面で使いそうですか？」
9. 関連リンク
- 関連リファレンス（理論）: 知識の呪い、確証バイアス、美的ユーザビリティ効果
- 用語集（定義）: ユーザビリティテスト、思考発話法、ユーザビリティ、ヒューリスティック評価
- 関連するUXリサーチ手法: A/Bテスト、ユーザーインタビュー
- UXリサーチ入口: UXリサーチ完全ガイド
10. まとめ
今日から直せる一手
次のリリース前に、社内の別チームのメンバー3人に「〇〇を完了してください」とタスクを与え、黙って観察してみてください。10分で致命的な問題が見つかります。
チームに共有するなら一言
「ユーザーに聞くな、ユーザーを見ろ」——意見ではなく行動を観察することで、言語化できない課題が見つかります。
UXデザインを体系的に学ぶ
UXリサーチの手法を理解したら、次は「UI原則」と「UIコンポーネント」も学ぼう。
- UIデザイン完全ガイド — UX心理・UI原則・UIコンポーネントの3レイヤーを一本化
- UIデザイン原則まとめ — 心理法則をUI設計のルールへ翻訳する65原則
- UX心理学まとめ — UIデザインの「なぜ」を説明する119法則
ユーザビリティテストとは、実際のユーザーに製品を使ってもらい、その行動を観察することで問題点を発見する評価手法です。
