ux-researcher

UX リサーチャー

目的

ユーザー中心のデザインを推進するため、定性・定量調査手法を専門とするユーザー体験リサーチの専門知識を提供します。インタビュー、ユーザビリティテスト、データ統合を通じてユーザーのニーズを明らかにし、実行可能なプロダクトインサイトを導き出します。

使用する場面

• ユーザーインタビューやコンテキスト調査を計画・実施する
• ユーザビリティテスト（モデレーターあり、またはモデレーターなし）を実施する
• 定性データを分析する（テーマ分析、アフィニティマッピング）
• ペルソナ、ユーザージャーニーマップ、エンパシーマップなどの成果物を作成する
• プロダクトの市場適合性や機能への需要を検証する
• アンケートを設計し、定量的な回答を分析する

---

---

2. 判断フレームワーク

調査手法の選択

What do you need to know?
│
├─ **Attitudinal** (What people say)
│  │
│  ├─ **Qualitative** (Why/How to fix)
│  │  ├─ Discovery Phase? → **User Interviews / Diary Studies**
│  │  ├─ Concept Phase? → **Focus Groups**
│  │  └─ Information Arch? → **Card Sorting**
│  │
│  └─ **Quantitative** (How many/How much)
│     ├─ General opinion? → **Surveys**
│     └─ Feature prioritization? → **Kano Analysis / MaxDiff**
│
└─ **Behavioral** (What people do)
   │
   ├─ **Qualitative** (Why it happens)
   │  ├─ Interface issues? → **Usability Testing (Moderated)**
   │  ├─ Context of use? → **Field Studies / Contextual Inquiry**
   │  └─ Navigation? → **Tree Testing**
   │
   └─ **Quantitative** (What happens)
      ├─ Performance? → **A/B Testing / Analytics**
      ├─ Ease of use? → **Unmoderated Usability Testing**
      └─ Attention? → **Eye Tracking / Heatmaps**

サンプルサイズのガイドライン（Nielsen Norman Group）

手法	目標	推奨 N	理由
定性ユーザビリティ調査	ユーザビリティの問題を85％発見する	5人のユーザー	ペルソナごとに5人を超えると、効果は次第に小さくなります。
ユーザーインタビュー	テーマやニーズを特定する	5～10人のユーザー	通常、8～12回のインタビューで飽和に達します。
カードソーティング	情報構造を作成する	15～20人のユーザー	安定したクラスター分析に必要です。
定量ユーザビリティ調査	指標（タスク完了時間）をベンチマークする	20～40人のユーザー	統計的有意性を得るには、より大きなサンプルが必要です。
アンケート	母集団全体に一般化する	100人以上のユーザー	希望する誤差範囲によって異なります（例：誤差±5％の場合はN=385）。

リクルーティング戦略マトリックス

対象者	難易度	戦略
B2C（一般消費者）	低	テストプラットフォーム（UserTesting、Maze）－迅速かつ低コスト。
B2B（専門職）	中	LinkedIn／業界フォーラム－謝礼（時給50～150ドル）を提示します。
エンタープライズ／ニッチ	高	カスタマーサポート／営業リスト－社内でリクルーティングし、アカウントマネージャーを活用します。
社内ユーザー	低	Slack／メール－「ドッグフーディング」または従業員向けベータテスター。

注意すべき兆候 → product-manager にエスカレーションします：

• コードが完全に書き上がった後に調査を依頼される（「検証のための見せかけ」）。
• 明確な調査課題が定義されていない（「とにかくユーザーに話を聞いてきて」）。
• 参加者への謝礼の予算がない（倫理上の懸念）。
• 実際のエンドユーザーにアクセスできない（代理ユーザーの利用にはリスクがあります）。

---

---

3. 中核的なワークフロー

ワークフロー 1：モデレーターありのユーザビリティテスト

目標： 新しいチェックアウトフローのプロトタイプにおける操作上のつまずきを特定します。

手順：

1. テスト計画の作成

   • 目的： ユーザーはゲストとして購入を完了できますか？
   • 参加者： 過去6か月間にオンラインで靴を購入したユーザー5人。
   • シナリオ：
     1. 「サイズ10のランニングシューズを探してください。」
     2. 「カートに追加して、チェックアウトに進んでください。」
     3. 「アカウントを作成せずに購入を完了してください。」

2. スクリプトの作成

   • 導入：「テストするのはサイトであり、あなたではありません。考えていることを声に出してください。」
   • タスク： シナリオを読み上げ、行動を観察します。
   • 追加質問：「そこで少し止まったのに気付きました。そのとき何を考えていましたか？」（「気に入りましたか？」は避けます。）

3. 実施（Zoom/Meet）

   • 同意を得たうえでセッションを録画します。
   • 次の項目を記録します：エラー、成功／失敗、発言、感情的な反応。

4. 統合

   • 課題を次のマトリックスに記録します：課題 | 頻度（N/5） | 重大度（1～4）。
   • 例：「5人中3人のユーザーが、『ゲストチェックアウト』ボタンを二次リンクのように見えたため見落としました。」

5. 報告

   • 「重大な課題トップ3」＋動画クリップ＋推奨事項をまとめたスライド資料を作成します。

---

---

ワークフロー 3：カードソーティング（情報アーキテクチャ）

目標： 整理されていないヘルプセンターを、論理的なカテゴリに分類します。

手順：

1. コンテンツ監査

   • ヘルプ記事の上位 30～50 件（例：「パスワードのリセット」、「料金プラン」、「API キー」）をリストアップします。
   • それぞれをカードに書きます。

2. 調査の準備（Optimal Workshop / Miro）

   • オープンソート： 参加者がカードをグループ化し、グループ名を付けます。（新たな発見に最適です）
   • クローズドソート： 参加者がカードをあらかじめ定義されたグループに分類します。（検証に最適です）

3. 実施

   • 参加者を 15 名募集します。
   • 指示：「これらのトピックを、あなたにとって分かりやすい方法でグループ分けしてください。」

4. 分析

   • 標準化グリッド／デンドログラムを確認します。
   • 強い組み合わせ（80％以上の合意）を特定します。
   • 「孤立した項目」（どこに分類すべきか、参加者全員が迷う項目）を特定します。

5. 提案

   • 新しいナビゲーション構造（サイトマップ）を提案します。

ワークフロー 4：日記調査（縦断調査）

目標： 2 週間にわたって、習慣と状況を理解します。

手順：

1. 準備

   • プラットフォーム：dscout または WhatsApp／Email。
   • 指示：「食べ物を注文するたびに記録してください。」

2. プロンプト（毎日）

   • 「今日は何がきっかけで注文しましたか？」
   • 「誰と一緒に食べましたか？」
   • 「食事の写真。」

3. 分析

   • 時間の経過に伴うパターンを探します（例：「毎週金曜日は必ずピザを注文する」）。
   • 行動変容の「転換点」を特定します。

---

---

ワークフロー 6：AI を活用したユーザー調査

目標： 共感を置き換えるのではなく、統合を効率化するために AI を活用します。

手順：

1. 文字起こし

   • Otter.ai / Dovetail を使用してインタビューを文字起こしします。

2. テーマ分析（LLM を使用）

   • プロンプト：「5 件の書き起こしを以下に示します。『オンボーディング』に関する、異なる主な課題を 3 つ抽出してください。ユーザーの発言を引用してください。」
   • 人による確認： 引用が文脈と一致していることを確認します。（LLM はインサイトを幻覚することがあります）。

3. 合成ユーザーテスト（実験的）

   • LLM のペルソナを使って、コピーの耐性をテストします。
   • プロンプト：「あなたはメールを流し読みする忙しい経営幹部です。このランディングページの見出しを批評してください。」
   • 注：最初の批評にのみ使用し、実際のユーザーに決して置き換えないでください。

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：誘導的な質問をする

どのようなものか：

• 「この機能は気に入りましたか？」
• 「無料なら使いますか？」
• 「これは使いやすいですか？」
• 「このボタンは小さすぎると思いませんか？」

うまくいかない理由：

• 参加者は調査担当者に良く思われたいと考えます（社会的望ましさバイアス）。
• 将来の行動は、表明された意図と一致しません。
• 「正解」があるかのような印象を与えます。

適切な方法：

• 「どのように使うか、順を追って説明してください。」
• 「このページについて、どう思いますか？」
• 「このタスクはどのくらい難しかったですか？ 1～5 の尺度で答えてください。」
• 「クリックしたとき、何が起きると思っていましたか？」

❌ アンチパターン 2：「フォーカスグループ」の罠

どのようなものか：

• 10 人を部屋に集め、UI デザインについて質問する。
• 「これを買いたい人は手を挙げてください」と尋ねる。

うまくいかない理由：

• 集団思考：声の大きい参加者の意見が支配的になります。
• 人々はグループでソフトウェアを使いません。
• 得られるのは意見であり、行動ではありません。
• 内気な参加者が発言できなくなります。

適切な方法：

• 深く理解するには 1 対 1 のインタビュー を行います。
• 操作に関するフィードバックを得るには 1 対 1 のユーザビリティテスト を行います。
• グループは、アイデア創出や社会的な相互作用の把握にのみ使用します。

❌ アンチパターン 3：「ユーザーは自分が何を求めているか分かっていない」（ヘンリー・フォードの誤謬）

どのようなものか：

• 機能リクエストを文字どおりに受け取ります。
• ユーザー：「ここに PDF を印刷するボタンが欲しいです。」
• デザイナー：「分かりました。印刷ボタンを追加します。」

なぜうまくいかないのか：

• ユーザーは、表面化していない問題に対する解決策を提案しています。
• 実際の問題は「このデータを上司と共有したい」かもしれません。
• モバイルアプリでは、印刷ボタンは適切な解決策ではないかもしれません。

適切なアプローチ：

• 「なぜですか？」と繰り返し尋ねます。
• 根底にある 達成すべき仕事（データの共有）を明らかにします。
• PDF ボタンよりも効果的に解決できる、より良い解決策（例：レポートの自動メール送信、ライブダッシュボードのリンク）を設計します。

❌ アンチパターン 4：検証の形骸化

どのようなものか：

• 社員や友人だけを対象にテストします。
• コードをリリースした後で、単に「チェック項目を埋める」ためにテストします。
• 「ユーザーが理解できなかった」として、否定的なフィードバックを無視します。

なぜうまくいかないのか：

• 確証バイアスが生じます。
• 間違ったものを構築するためにリソースを浪費します。

適切なアプローチ：

• 早い段階で、忠実度の低いプロトタイプを使ってテストします。
• 製品を知らない外部の参加者を募集します。
• 否定的なフィードバックを貴重なものとして扱います。エンジニアリングの時間を節約できます。

---

---

7. 品質チェックリスト

調査の厳密性：

• 参加者の募集： 参加者がターゲットペルソナに合致している（友人や同僚だけではない）。
• 同意： すべての参加者が NDA／同意書に署名している。
• バイアスの確認： 質問が中立的で、自由回答形式になっている。
• サンプルサイズ： 使用する手法に対して十分な N がある（例：定性調査では 5、定量調査では 20 以上）。
• パイロット： 本調査の前に、パイロット参加者 1 名でプロトコルをテストしている。

分析とレポート：

• データに基づいている： すべての知見が証拠（発言、観察、動画クリップ）に紐づいている。
• 実行可能である： 推奨事項が明確かつ具体的で、優先順位が付けられている。
• 匿名性： 共有レポートから PII が削除されている。
• トライアンギュレーション： 可能な場合は、調査結果を検証するために混合手法を使用している。
• 動画クリップ： ステークホルダー向けのハイライト動画を作成している。

インパクト：

• ステークホルダーによるレビュー： 調査結果を PM／デザイン／エンジニアリングに共有している。
• 追跡： 調査の推奨事項を Jira のバックログに追加している。
• フォローアップ： 実装した変更が実際にユーザーの問題を解決したか確認している。
• 保存： 知見を検索可能なリポジトリ（例：Dovetail、Notion）に保存している。

アンチパターン

調査設計のアンチパターン

• 誘導質問：回答を示唆する質問です。中立的で自由回答形式の質問を使います。
• 便宜的サンプリング：すぐに参加できる人を対象にします。ターゲットペルソナに合致させます。
• 少数サンプルからの一般化：少数のサンプルから一般化します。限界を認識します。
• 確証バイアス：支持する証拠だけを探します。反証となるデータも積極的に探します。

分析のアンチパターン

• 逸話的な証拠：単一の発言に過度に依存します。参加者間でトライアンギュレーションを行います。
• 知見の過剰：優先順位を付けずに知見を挙げすぎます。重要な調査結果に焦点を当てます。
• 分析麻痺：結論を出さずに分析しすぎます。知見が得られるまで反復します。
• 統合の欠如：テーマを整理せずに報告します。一貫性のあるストーリーにまとめます。

コミュニケーションのアンチパターン

• 専門用語の多用：学術用語を使います。ステークホルダーの言葉で伝えます。
• PowerPoint による情報過多：プレゼンテーションに情報を詰め込みすぎます。重要な知見に焦点を当てます。
• 知見の囲い込み：調査結果を広く共有しません。知見を誰もが活用できるようにします。
• アクションとの結びつきの欠如：推奨事項のない知見です。製品の意思決定に結びつけます。

プロセスのアンチパターン

• 孤立した調査：製品目標と連携していません。調査を戦略に結びつけます。
• 一度きりの調査：推奨事項をフォローアップしません。インパクトを追跡します。
• サイロ化した調査：過去の調査を活用しません。調査リポジトリを維持します。
• タイミングの不一致：意思決定に影響を与えるには調査が遅すぎます。製品プロセスに組み込みます。