ユーザー調査結果のプレゼン：根拠を製品の判断につなげる

ユーザー調査のプレゼンは、発言を並べるだけではありません。問い、サンプルの背景、観察、テーマを、限定した製品判断につなげます。プレゼンテーションのデータストーリー（英語）を使い、根拠と解釈を分けて示してください。

根拠から言えることが整理できたら、Presentiで調査の構成案からスライドの下書きを作成できます。観察と、それを説明する複数の仮説を構成案に含めてください。ツールは資料を整理するために使えますが、調査の分析そのものを代行するわけではありません。

調査の枠組みを先に示す

最初に調査の問い、方法、期間、参加者の背景を説明します。誰が含まれず、どの状況を観察していないかも書きます。インタビュー、モデレーション付きテスト、自由回答の調査は得られる信号が異なるため、同じ種類の証拠として混ぜません。

説明用の例を使うときは「例」と明記し、実際の調査結果と区別します。匿名化した発言は意味を変えず、特定につながる情報だけを取り除きます。

5回のセッションを一つの例として追う

ワークスペースを管理する製品の、架空のユーザビリティ調査を考えます。最近管理者になった5人に、同僚を招待して、その人のアクセス権を変更してもらいました。テスト用ワークスペースでは全員に操作権限があります。調べたいのはアカウントの権限差ではなく、操作場所を見つけられるかどうかです。製品チームは、次に画面のどの部分をテストするか判断します。

以下は分析方法を説明するために作った観察記録です。参加者の実際の発言でも、Presentiで行った調査の結果でもありません。

観察と解釈を分ける

まず、実際に見たこと、聞いたことを書きます。その後で、根拠から導いた解釈をテーマとして示します。参加者の言葉を整えすぎたり、全員の意見のように扱ったりしないでください。各観察に出典、取得日、確かさを添えます。

テーマの作り方を追跡する

似た観察をどのようにまとめたかを示し、テーマを支えるケースと反例を残します。件数は調査したケースについての説明であり、市場全体の割合ではありません。反例は隠す失敗ではなく、次の調査の問いです。

気づきと反例を同じ場所に示す

この記録から言えるのは、「3人は、最初に個人プロフィールでアクセス権の設定を探した」ということです。根拠となる記録はP1・P2・P3です。P4はすぐに正しい場所へ進み、P5は正しい場所に着いてから名称の違いに迷っています。別々の問題を「権限設定が分かりにくい」という一つの結論にまとめないでください。

アクセス管理を個人プロフィールと結び付けて考えた可能性があります。一方で、ワークスペースのメニューが目立たなかった可能性もあります。P2については、別製品での経験が経路の選択に影響したかもしれません。現時点の記録だけでは、どの説明が主な原因か切り分けられません。

3人の観察を「顧客の60%はアクセス権を管理できない」と言い換えてはいけません。今回は特定の操作と管理者像に合わせて参加者を選んでいます。英国政府の調査セッションの分析ガイド（英語）も、観察、分析から得た知見、考えられる行動を分けています。各段階を見せると、どこから解釈が加わったかを聞き手が追えます。

気づきを製品の判断につなげる

優先テーマごとに、機会、未回答の問い、次の製品判断を一つずつ置きます。提案、仮説、テスト案を別にし、行動の担当者と確認するシグナルを決めます。「さらに調査する」だけで終わらせず、何を学べば判断できるかを一文で書きます。

チームが具体的に議論できる1枚にする

スライドの見出しは、「権限設定全体を作り直す前に、設定場所の見つけやすさをテストする」とします。左側にP1〜P3の観察、別の枠にP4の直接の経路とP5の名称の問題、右側にテスト案を置きます。ここで判断するのはナビゲーションを調べるかどうかであり、権限設定全体の再設計を承認することではありません。

P5の問題は独立した記録として残し、名称の理解を確かめるテストも検討します。件数の多いナビゲーションの問題に埋めると、重要な権限の誤解を見落とすおそれがあります。件数が示すのは、この調査で何回現れたかです。影響の重大さまでは決まりません。

根拠に基づくスライド構成

1. 問いと方法
2. サンプル、期間、限界
3. 観察と匿名化した根拠
4. テーマ、反例、確かさ
5. 機会、判断、テスト
6. 次の行動と未回答の問い

詳細な出典、コーディング方法、長い引用は付録へ移します。本編では各判断を支える根拠だけを読みやすく残します。

プライバシーと範囲を守る

個人を特定できる情報、実際には得られていない発言、根拠のない割合を入れません。定性調査は方向を示せますが、市場シェアや全ユーザーの因果を証明しません。最後のスライドで、確認済み、解釈、次に検証することを分けます。

更新履歴を残す

分析をまとめた日付、確認した人、使った資料の版を記録します。新しい観察でテーマや提案が変わったら、以前の結論を削除せず、何が変わったかと理由を残します。会議の最後には、決めたこと、保留したこと、次に得る証拠を一つの表にまとめます。

これにより、資料は引用の集合ではなく、根拠から限定した判断へ進む作業の記録になります。

サンプルを正しく読む

参加者数だけで結果の強さを決めず、参加条件、募集経路、調査者と参加者の関係を確認します。特定の経験を持つ人に偏っている場合は、その偏りを限界として書きます。小さなサンプルでも、課題を深く理解する手掛かりにはなりますが、全体の発生率を示すものではありません。

参加しなかった人の特徴も確認し、偏りがどの判断に影響するかを明記します。

観察が一致しないときは、どの条件で違いが出たのかを確認します。デバイス、経験、利用目的、状況が異なる場合は、テーマを一つにまとめず、条件ごとに別の示唆として示します。

判断の境界を明記する

提案の強さが根拠の強さを超えないようにします。「試す価値がある」という判断と、「この機能が成果を上げる」という主張は別です。前者には小さなテスト、後者にはさらに検証が必要です。スライドの見出しも、根拠が示す範囲に合わせて書きます。

反対の証拠がある場合は、推奨を条件付きにします。例えば、特定の利用状況で再現できるかを確認してから、対象を広げるという形です。条件、担当者、期限を判断ログに残します。

引用と要約を管理する

引用は匿名化し、編集した部分を明確にします。要約した観察には、元の記録やセッション番号を付け、同じ発言を複数のテーマで数えないようにします。長い引用を目立たせるだけで結論を作らず、引用が何を示し、何を示さないかを一文で補います。

次の調査を設計する

未回答の問いには、次に集める情報、対象者、方法、完了条件を割り当てます。データが増えたら、以前のテーマをそのまま足すのではなく、根拠が増えた部分と変わらない部分を区別します。

最終ページでは、決定、保留、追加調査、試す行動を四つの欄に分けます。これにより、読者は研究の結果と、チームがまだ選んでいない道を混同しません。

次のテストで、競合する説明を確かめる

プロトタイプを2種類用意します。一方は文言を変えずにワークスペースのメニューを目立たせ、もう一方は位置を変えずにアクセス管理の文言を変えます。操作の課題と権限条件は同じにします。先に試した経験による慣れをデザインの改善と取り違えないように、参加者に各案をどう提示するかは調査担当者が設計します。

最初に探した場所、助けなしで設定を見つけたか、操作後に説明してもらった理由を記録します。メニューの場所を誘導してはいけません。メニューを目立たせた案では経路が変わり、文言を変えた案では変わらなければ、このテストでは一方の説明を支持する材料になります。どちらでも改善しなければ、元の知見が間違いだったと即断せず、出発点の仮定を見直します。

会議では「調査担当者がデザイン担当者の協力を得て、設定場所の発見に絞ったプロトタイプ調査を行いたい。名称の理解は別の問いとして扱い、ナビゲーションの変更を決める前に、実際にたどった経路を確認したい」と承認を求めます。この架空の5回のセッションから、コンバージョンの上昇や顧客全体の成功率を導くことはできません。