3行でわかるユーザーリサーチとユーザビリティテストの違い
- ユーザーリサーチ ：ユーザーのニーズ・課題・文脈を理解するための調査
- ユーザビリティテスト ：作ったUIがちゃんと使えるかを確かめる検証
- 違い ：リサーチは「何を作るべきか」を見つけ、テストは「ちゃんと使えるか」を確かめる
この記事の要点（UIXHERO視点）
- ユーザーリサーチは「何を作るべきか」を発見する。
- ユーザビリティテストは「ちゃんと使えるか」を検証する。
- 両者を混同すると、順番も予算も判断もずれる。
導入：「ユーザーテストしましたか？」への違和感
「このデザイン、ユーザーテストしましたか？」
プロジェクトでよく聞くフレーズです。しかし、この質問には曖昧さがあります。
- ユーザーに ニーズを聞いた のか？
- ユーザーに プロトタイプを触らせた のか？
この2つは全く異なる活動です。前者は ユーザーリサーチ ** 、後者は ** ユーザビリティテスト です。
（なお「ユーザーテスト」という言葉は曖昧なため、本記事では正式名称である「ユーザビリティテスト」を使います）
リサーチとテストを混同すると、「何を作るべきか」と「ちゃんと作れているか」の判断がごちゃ混ぜになる。
この問題を解く鍵が、ユーザーリサーチとユーザビリティテストの使い分けです。
ユーザーリサーチとユーザビリティテストの違い（定義）
ユーザーリサーチは「発見」であり、ユーザビリティテストは「検証」である。
| 項目 | ユーザーリサーチ | ユーザビリティテスト |
|---|---|---|
| 目的 | ユーザーのニーズ・課題・文脈を理解する | UIの使いやすさを評価する |
| タイミング | 設計前（探索フェーズ） | 設計後（検証フェーズ） |
| 問い | 「何を作るべきか？」 | 「ちゃんと使えるか？」 |
| 対象 | ユーザーの行動・目標・課題 | UI・プロトタイプ・製品 |
| 手法例 | インタビュー、観察、日記調査 | タスクテスト、シンクアラウド、A/Bテスト |
ユーザーリサーチ ** は、人類学・社会学の調査手法がデザインに取り入れられ、「ユーザー中心設計（UCD）」とともに普及しました。 ** ユーザビリティテスト は、ヤコブ・ニールセンらが「5人で85%の問題を発見できる」と実証し、標準プラクティスになっています。
タップして拡大表示クリックして拡大表示
一言での使い分け ユーザーリサーチは「発見」——何を作るべきかを知るための調査。 ユーザビリティテストは「検証」——作ったものがちゃんと使えるかを確かめる。
なぜ重要なのか
1. 順序を間違えると無駄が生じる
| 順序 | 結果 |
|---|---|
| ✅ リサーチ → 設計 → テスト | 正しいものを正しく作る |
| ❌ 設計 → テスト（リサーチなし） | 誰も求めていないものを使いやすくする |
| ❌ リサーチ → 設計（テストなし） | 正しいものを間違って作る |
リサーチなしでテストだけ行うと、「そもそもこの機能は必要だったのか？」という根本的な問いに答えられません。
タップして拡大表示クリックして拡大表示
2. 得られる知見が異なる
- ユーザーリサーチ : 「ユーザーは〇〇に困っている」「△△が本当のニーズだった」
- ユーザビリティテスト : 「このボタンに気づかない」「この言葉の意味がわからない」
リサーチは「問題の発見」、テストは「解決策の検証」です。
具体例・ケース比較
ケース1：ECサイトのリニューアル
| フェーズ | ユーザーリサーチ | ユーザビリティテスト |
|---|---|---|
| 問い | 「なぜカート離脱率が高いのか？」 | 「新しいチェックアウトUIは使いやすいか？」 |
| 手法 | 離脱ユーザーへのインタビュー、行動観察 | プロトタイプを使ったタスクテスト |
| 発見例 | 「送料がいつわかるかわからず不安」「会員登録が面倒」 | 「住所入力フォームで郵便番号の位置がわからない」 |
| 次のアクション | 送料早期表示、ゲスト購入機能を設計 | フォームのレイアウトを修正 |
タップして拡大表示クリックして拡大表示
ケース2：社内ツールの改善
| フェーズ | ユーザーリサーチ | ユーザビリティテスト |
|---|---|---|
| 問い | 「現場はどんな業務で困っているか？」 | 「新機能は現場で使えるか？」 |
| 手法 | 現場観察（シャドーイング）、コンテキストインタビュー | 実際の業務データを使ったテスト |
| 発見例 | 「Excelとの行き来が多い」「承認フローが複雑」 | 「一括インポート機能の場所がわからない」 |
| 次のアクション | Excel連携機能、承認フロー簡略化を設計 | ナビゲーションにインポートボタンを追加 |
タップして拡大表示クリックして拡大表示
ケース3：新規プロダクト開発
| フェーズ | ユーザーリサーチ | ユーザビリティテスト |
|---|---|---|
| 問い | 「このプロダクトに市場はあるか？」 | 「MVPは最低限使えるか？」 |
| 手法 | 問題インタビュー、競合ユーザーへの調査 | ペーパープロトタイプ、コンセプトテスト |
| 発見例 | 「既存ツールに不満はあるが、乗り換えコストが高い」 | 「価値は伝わるが、初期設定で詰まる」 |
| 次のアクション | 乗り換えコストを下げる機能を検討 | オンボーディングを強化 |
タップして拡大表示クリックして拡大表示
実務でなぜ区別すべきか
UIXHEROがこの2つを厳密に区別する理由は3つあります。
1. 予算・スケジュールの配分が異なる
| ユーザーリサーチ | ユーザビリティテスト | |
|---|---|---|
| タイミング | プロジェクト初期 | 設計中〜リリース前 |
| 頻度 | プロジェクトあたり1〜2回 | イテレーションごとに複数回 |
| コスト | 高め（深い調査が必要） | 低め（5人で十分） |
「ユーザー調査」と一括りにすると、適切な予算配分ができません。
2. 必要なスキルが異なる
| ユーザーリサーチ | ユーザビリティテスト | |
|---|---|---|
| 聞き方 | オープンクエスチョン、深掘り | タスク指示、観察 |
| 分析 | 親和図法、テーマ分析 | タスク成功率、エラー分類 |
| アウトプット | ペルソナ、ジャーニーマップ | 課題リスト、改善提案 |
リサーチャーとテスターは、重なる部分もあれば異なるスキルも必要です。
3. 「テストすればいい」という誤解を防ぐ
「ユーザーテストすればOK」という考えは危険です。テストで発見できるのは「UIの問題」であり、「そもそも何を作るべきか」はリサーチでしか発見できません。
タップして拡大表示クリックして拡大表示
よくある質問
Q1. 時間がないときはどちらを優先すべきですか？
状況によります。
- 新規プロダクト・大きな方向転換 : リサーチを優先。間違った方向に進むと、後で大きな手戻りが発生する
- 既存プロダクトの改善 : テストを優先。すでにユーザーニーズはある程度わかっている前提で、UIの改善に集中
どちらも省略すべきではありませんが、フェーズに応じて重みづけを変えます。
Q2. インタビューはリサーチですか？テストですか？
目的によります。
- 「普段どんな課題がありますか？」→ リサーチ （課題発見）
- 「このプロトタイプを使って〇〇してください」→ テスト （検証）
同じ「インタビュー」という手法でも、目的が異なれば位置づけが異なります。
Q3. A/Bテストはユーザビリティテストですか？
別物として捉える方が実務的です。
| 観察型ユーザビリティテスト | A/Bテスト | |
|---|---|---|
| データ | 定性（観察、発話） | 定量（コンバージョン率） |
| 規模 | 5〜10人 | 数千〜数万人 |
| 発見 | 「なぜ使いにくいか」 | 「どちらが成果が出るか」 |
A/Bテストは「どちらが良いか」はわかりますが、「なぜ良いか」はわかりません。両者は補完関係にあり、組み合わせて使うのが理想です。
まとめ
- ユーザーリサーチ : ユーザーのニーズ・課題を発見する（設計前・探索）。
- ユーザビリティテスト : UIの使いやすさを検証する（設計後・検証）。
- 使い分け : リサーチで方向を定め、テストで品質を担保する。両方を適切なタイミングで行うことで、「正しいものを正しく作る」ことができる。
「ユーザーテストしました」では不十分。「何を発見し、何を検証したか」を語れるチームが、良いプロダクトを作る。
次に読む
- ユーザーリサーチとは？ — リサーチ手法の全体像
- ユーザビリティテストの進め方 — 実践ガイド
- インタビュー設計 — 質問の作り方
- ペルソナとセグメントの違い — 調査結果の活用
