ユーザーインタビューは、UI/UX改善や新規サービス開発の場面で、ユーザーの本音や隠れたニーズを掘り起こすために欠かせないリサーチ手法です。しかし、ただ質問をするだけでは十分な情報は得られません。
ベイジがこれまでの実施経験から得た知見を交え、準備から実施、分析までの流れと、インサイトを引き出すための具体的な工夫やポイントを解説します。
ユーザーインタビューとは、製品やサービスを実際に利用するユーザーとの対話を通じて、課題やニーズ、反応や意見を引き出すリサーチ手法です。定性調査(数値ではなく言語情報を分析する調査)の一種で、UI/UX戦略の立案や、課題・仮説の検証の際によく用いられます。
ユーザーと“直接”対話することで、作業手順や業務フロー上の問題点などを深堀りできることが特長です。アンケートやログデータだけでは見えにくい「背景」や「理由」に踏み込むことができます。
ユーザーリサーチの分類例
定性調査 | 定量調査 |
ユーザーインタビュー ユーザビリティテスト エスノグラフィ | アンケート調査 アクセス解析 A/Bテスト |
ユーザーインタビューの目的は、既知の行動や発言、顕在化した課題感などの裏にある“本質的な潜在ニーズ”を引き出すことです。
インタビュー対象者(=ユーザー)個人の体験に着目して質問を行い、回答や反応に対してタイムリーに「なぜそう感じたのか」といった深堀りを重ねていくことで、ユーザー自身も気づいていないニーズ・課題意識=インサイト(洞察)を明らかにできます。
このインサイトを把握することでユーザー理解の解像度が上がり、新たな視点や仮説を立てるためのヒントになります。
またユーザーインタビューは、製品やサービスの開発初期・設計段階から、リリース後の評価や改善まで活用できる汎用的な手法でもあります。
新しいシステムや機能を検討する段階で、ユーザーの業務実態やニーズを理解するために実施します。企画内容を具体化し、開発者の想定が的外れになることを防ぎます。
プロトタイプを用いてフィードバックを収集し、改善点を抽出します。ユーザビリティの確認や操作性の検証に有効です。
既存のシステムに重要な変更やアップデートを加える前に、業務フローに及ぼす影響を事前に把握するために行います。これによってリリース後の混乱リスクを未然に防ぐことができます。
定期的に収集するフィードバックの際に実施し、継続的な改善につなげます。製品やサービスユーザーニーズに適しているかを確認し改善を続けることで、ユーザーの満足度の維持や、SaaSの場合は解約防止にも寄与します。
ユーザーからの不満の声や問題報告が多発した場合に、その原因を特定し解決策を探るために実施します。
プロダクトライフサイクル×ユーザーインタビュー活用タイミング
企画 | 業務実態の把握 |
設計 | プロトタイプの確認 |
開発 | 仕様仮説の確認 |
リリース | フィードバック取得 |
改善 | 継続改善 |
ベイジでは、WebアプリケーションのUI/UX改善に向けた戦略立案の初期段階でユーザーインタビューを実施しています。
プロダクト全体の利用実態を把握したり、他の手法(例:画面の構造や操作性を専門家がチェックするヒューリスティック評価)と組み合わせて課題の立体的な理解につなげたりするなど、目的に応じて使い分けます。
ここでは、ベイジがインタビューを通じて明らかにしている主な観点をご紹介します。
以下のような質問を通じて、業務全体の流れや利用実態を把握します。
例えば、「毎日使う機能はどれか」と尋ね、その機能に対して「どのような状況で使用するか」と具体的な利用シーンを深堀することで、作業の流れや業務上の工夫を把握できます。
また、次のような回答からも、ユーザーフロー全体の正確な実態が見えてきます。
このような深掘りを積み重ねることで、ユーザーフロー全体の正確な実態が見えてきます。
問題や課題、ニーズの実態を理解し整理することで、どの改善に優先的に取り組むべきかの判断材料とします。
例えば、「税率変更を自動的に反映できる機能がほしい」(=ニーズ)と強く要望されていたとしても、インタビューによって「税率変更は数年に1度」と分かれば、発生頻度が低いという理由で優先順位を下げることも検討します。
逆に、課題としては挙がっていなかった「毎月請求書をFAXしている」という事実が明らかになり、「送信機能があれば便利だけど優先順位は低くて良い」と言われたとしても、発生頻度やペーパーレス化の観点から優先度すべきと判断するケースもあります。
こうしたインタビューで得られた事実は、クライアントの本質的なニーズを見極めるための手がかりになります。
ユーザーインタビューは有効な手法のひとつですが、目的や状況によっては他の手法を組み合わせることで、より多角的にユーザーの実態やニーズを把握できる場合もあります。
ここでは、ユーザーのニーズやインサイトを収集するための、ユーザーインタビュー以外の代表的な手法をご紹介します。
あらかじめ設計した質問票を用いて、多数のユーザーからオンラインや紙面で回答を収集する手法です。多数のユーザーから広く情報を収集でき、一貫性のある定量データを得やすい点が特徴です。統一された質問形式により、回答を比較・集計しやすく、ユーザー全体の傾向や意識を数値として把握できます。一方で、ユーザーの感情や行動の背景といった深層的な情報を掘り下げることは難しく、深い洞察には別の調査手法との併用が望まれます。
実際のプロダクトやプロトタイプを使い、ユーザーの操作や行動を観察します。ユーザーがシステムを利用している様子を直接観察できるため、インタビューでの回答とのギャップを補うことが可能です。制作プロセスのどの工程でも実施することができますが、原則として対象物が用意できる段階に限られ、調査できる内容も“使い方”に限定されます。
参考:実践から学ぶユーザーテストの進め方(https://baigie.me/blog-ui/2024/10/18/how-to-usertests/)
一定期間にわたり、ユーザーの行動や感情を自然な環境下で観察し、文章や画像・動画で記録する手法です。行動の背景やコンテクストを深く理解することができますが、実施には多くのコストと時間がかかります。
なお、実際のプロジェクトでは、ユーザビリティテストやアクセス解析など複数の手法を組み合わせることで、ユーザー行動の“実態”と“認識”のギャップを可視化するケースも多くあります。
手法 | 特徴 | 得意な情報 | デメリット |
---|---|---|---|
ユーザーインタビュー | 深い感情を引き出せる | インサイト | 主観的、時間がかかる |
アンケート | 大量の意見を収集できる | 傾向 | 深堀は難しい |
ユーザビリティテスト | 行動観察ができる | 利用実態 | プロトタイプが必要 |
エスノグラフィックリサーチ | 自然な環境でのユーザー行動観察ができる | コンテクスト | コストがかかる |
ユーザーインタビューは、ユーザーと直接対話することで、表面的な要望の裏にある背景や本質的なニーズ(インサイト)を探る手法です。ただし、万能ではないため、適切な準備や目的に応じた使い分けが必要です。
ユーザーとの「直接対話」によって、他の手法では得にくいリアルな情報や気づきを引き出せる点が大きなメリットです。
インタビューでは、回答者の反応をその場で把握できるため、想定していなかった視点や言い回しから新たな気づきを得られることがあります。
また、実体験に基づく話かどうかをその場で確認したり、曖昧な回答に対して深掘りの質問を挟んだりすることで、より具体的で信頼性の高い情報を収集できます。
反応の強さ(熱量)や戸惑いなども観察できるため、ユーザーの本音や重要度の高い課題を的確に捉えやすくなります。
ユーザーインタビューでは、その場の反応に合わせて設問を変更したり、質問の順序や目的自体を切り替えたりすることができます。
インタビュアーが柔軟に振る舞うことで、話が浅いと感じたら深掘りに注力し、インサイトが得られにくい場合はヒント探しに方針を変えるなど、状況に応じた対応が可能です。
その結果、ユーザー自身も気づいていないような潜在的なニーズ(インサイト)や課題を発見しやすくなります。
浮き彫りになったインサイトは、利便性や業務効率を高める具体的な改善策や、ユーザーとシステムとのエンゲージメントを向上させるヒントになります。
言葉だけでなく、表情の変化やジェスチャー、間の取り方などの非言語的な情報からも、ユーザーの感情や考え方など重要な気づきを得られることがあります。
こうした観察を通じて、ユーザーの本音や、言語化されていない認識のギャップを捉えられる可能性があります。
開発者の想定とユーザーの実際の行動との間にギャップが生じることは少なくありません。
例えば「Aのデータ出力ボタンがほしい」という要望に対して「Aの画面にボタンを配置すればよい」と考える場合でも、インタビューによって「Aのデータが必要なのはBの画面を見ている時」と判明すれば、より使いやすい配置に見直すことができます。
ユーザーインタビューを通じてこうしたギャップを早期に発見することで、ユーザーの実態に即した改善が可能になります。
ユーザーインタビューには多くの利点がある一方で、実施や分析に工数がかかったり、得られる情報の性質にも特有の注意点があります。
インタビューの設計から準備、実施、分析までには多くの工程があり、調査を進めるには一定の時間とリソースが必要です。実施にはインタビュアーのほか、同席者や記録担当など複数人が関わることも多く、関与するメンバーの調整も必要になります。
対象となるユーザーの人数が増えるほど、それぞれの工程にかかる負荷も大きくなります。
インタビューの回答はインタビュー対象者の主観に基づくため、バイアスが含まれる可能性があります。また、インタビュアーの質問の仕方や雰囲気によっても、回答の内容やトーンに影響を与え左右してしまう可能性もあります。
自由度の高いインタビューでは、質問内容や掘り下げの深さが対象者やインタビュアーごとに異なるため、得られる情報の粒度がばらつきやすく、データの比較や一般化が困難になる場合があります。
回答は基本的に自己申告のため、記憶の曖昧さや認識の誤りが含まれることがあります。その結果、インタビュー内容とユーザーの実際の行動の間にズレが生じる場合があります。
ユーザーインタビューは大きく以下の3ステップで実施されます。
各ステップにおいて重要となるポイントや進め方の工夫について、順を追ってご紹介します。
ユーザーインタビューでもっとも重要な工程です。
インタビュー対象者を一定時間拘束するため、一度の機会を最大限に活かす意識で、慎重に準備を行うことが重要です。
「何を明らかにしたいか」という目的を明確にし、「誰に聞くべきか」を検討します。この2点を曖昧なまま進めると、後工程で期待した結果が得られなかったり、設計のやり直しが発生するリスクがあるため、慎重に行います。
とくにクライアント社内でのみ利用する製品やサービスでは、インタビュー対象者の選定をクライアントに委ねることも多いため、クライアントと目的のすり合わせを丁寧に行うことが重要です。
ユーザーの規模や、製品・サービスの性質に合わせて、適切なインタビュー手法を決定します。代表的な手法は以下のようなものがあります。
同じ属性のユーザーを2人以上集めて実施する手法です。グループのメンバーが同じ空間で同時に質問を受けられるよう場所を設定することが重要です。
短時間で複数の意見やニーズを得られるほか、参加者同士の対話から生まれる相互作用によってインサイトを引き出すことができるのが特長です。
一方、無意識に周囲と同調することがあり、個人の本音が出にくい可能性があるというデメリットがあります。
1対1で話を聞く方法です。
個人の意見を深堀しやすく、ニーズや感情に踏み込んだ理解をしやすいという特長があります。
一方、1人あたりの所要時間が長く、回答が主観に偏る可能性もあります。そのため、ある程度のサンプル数(3人以上)にインタビューすることをおすすめします。
あらかじめ決めた質問に沿って過不足なくインタビューを行います。
質問が統一されているため、インタビュアーのスキルに左右されにくく、複数の対象にインタビューする場合に定量的な分析が可能になります。データの一貫性や比較のしやすさを確保できるので、調査目的が明確な場合や、一定のデータ収集が求められるシーンに適しています。
一方で、柔軟な深堀がしにくく、内容によってはアンケートで代替可能なケースもあります。
質問内容をおおまかに用意しつつ、回答によって質問の順序を変えたり、新たな質問を追加するなど、柔軟にやり取りを展開する手法です。
ユーザーの興味や経験に合わせて重点を置きたいテーマを深掘りしやすく、ユーザーの行動や文脈を立体的に捉えたいときに適しています。
一方、その場で質問を考えたり、時間配分に気を付けるなど臨機応変な対応が求められるため、インタビュアーのスキルが求められます。
質問内容をあまり定めず、自由な会話形式で行うインタビューです。
ユーザーが意見や感想を自由に表現できるため、予期しないインサイトを得られる可能性があります。一方で話題の広がりや方向性など会話をうまくコントロールするには、高いファシリテーションスキルが求められます。
そのため、得られた情報のばらつきが大きく分析負荷が高くなる点にも注意が必要です。
ベイジではプロジェクトに応じた柔軟な設計を心がけていますが、「デプスインタビュー+半構造化インタビュー」または「グループインタビュー+半構造化インタビュー」で実施することが多くあります。聞き漏らしを防ぎながら、個別の体験を深く聞き取ることができるためです。後者の場合は“語り合い”から偶発的な気づきが得られることもあります。
スケジュールに余裕がありユーザーインタビューに時間やコストを割けるようであれば、デプスインタビューを選択します。
プロダクトのペインを想定できる場合は、最初に構造化的な問いでポイントを絞りこみ、各ポイントに対して自由な会話で進める(非構造型)ことを繰り返す構成としています。
ベイジがこの手法を選定する背景としては、設計前にユーザーフローや業務の実態をしっかり把握したいプロジェクトが多いことがあげられます。一方で、例えばリリース直前のUI改善など、短期的で期間・コストが限られている場合は、別の手法を検討することもあります。
※手法選定時の判断基準の例
適切な対象者に話を聞くことは、ユーザーインタビューの精度を左右する非常に重要な工程です。聞くべき相手を誤ると、得られる気づき自体が的外れになってしまうこともあるため、慎重な検討が必要です。
ここでは、ターゲット層の設定とリクルート方法の考え方について解説します。
プロジェクトの目的に応じて、インタビュー対象者の属性を定めます。
例えば、同じサービスのユーザーであっても、役割や利用頻度、経験年数によって見えている課題が異なることがあります。
そのため、どの層のユーザーに、どんな問いを投げかけたいのかを事前に整理しておくことが重要です。
※ターゲット選定の例
ターゲット層が定まったら、どのような方法で対象者をリクルートするかを検討します。
対象者の属性や関係性によって、適切なリクルートチャネルは異なります。
以下に、代表的なケースを紹介します。
事案:
採用サイト(新入社員)や社内用業務システムなど
方法:
クライアントに社内で依頼してもらう。
社内アナウンスやイントラ経由で協力者を募る。
事案:
BtoBサイト(顧客)やSaaSシステムなど
方法:
クライアントの営業担当やCS部門を通じてユーザーに依頼してもらう。
メールマガジンやお知らせ機能などで協力依頼を配信してもらう。
事案:
BtoCサービス、新規プロダクト開発など
方法:
クライアントの社内やプロジェクトチームの周辺で該当する人物を探して依頼してもらう。
SNS・コミュニティ・フォーラム・イベントなどを通じて募集する。
求人媒体などを活用する。
ユーザーリサーチ専門のパネル会社・エージェントに依頼する。
顧客や一般ユーザーに協力を依頼する場合は、「○○ポイント贈呈」や「サービス1ヶ月無料」など、謝礼(インセンティブ)を設定することで参加率を高められることがあります。
ただし、その報酬コストのほか、外部エージェント利用時にはリクルート手数料が発生するため、予算とのバランスを見ながら依頼方法や対象者数を検討する必要があります。
非構造化インタビューを除き、ユーザーインタビューではあらかじめ質問項目を設計する必要があります。次のような手順でインタビュー設計を行いします。
まずは質より量を優先し、必要そうな質問を幅広く洗い出します。
1つの質問を思いついたらWhen(いつ)、Where(どこで)、Who(誰が)、Why(なぜ)、What(何を)、How(どのように)、How many(どのくらい)、How much(いくら)といった5W3Hの視点で質問を膨らませていきます。
また、インタビュー対象者を理解するために「どういう人か」「どんな生活(業務)をしているか」などの背景理解に関する質問も用意します。これらは、発言の背景を理解するヒントのほか、アイスブレイクに利用できます。
検討する際に複数人でブレストをする時間なども設けると、多様な視点から質問を用意できます。
洗い出した質問は、以下の観点で優先順位と構造を整理します。
また、ベイジでは事前に作成した仮説の業務フロー(仮説マップなど)をもとに、質問をカスタマイズします。フローを把握していないと、作業手順の確認だけで時間を使い切っていまい、インサイトまでたどり着けない可能性があるからです。
仮説の業務フローの作成手順:
このプロセスを通じて、画面上に見えない作業や暗黙のノウハウがある可能性にも気づけることがあります。
ベイジでは整理した質問を質問表にまとめ、ユーザーの業務フローや習熟度によって内容に調整を加えています。
初心者と熟練者で業務内容が異なる場合もあり、同じ質問でも得られる情報が異なるため、柔軟にアレンジします。
また、質問表を使って社内メンバーの認識合わせを兼ねたリハーサルを行います。模擬インタビューを通じて、「質問の順番は自然か」「ボリュームは適切か」を確認し、本番に備えて最終調整を行います。
テーマ | 意図 |
---|---|
仮説フローに誤りがないか | 想定外の手順や回避策を洗い出す |
作業を行う前後の行動 | プロダクトを利用しない行動も含めて全体像を把握する例:情報登録用の資料をFAXで送ってもらう |
日々のゴール設定 | 何を達成したいか、プロダクトをどのように活用しているかを探る |
やりがいやモチベーション | 仕事の意味づけから、重要な作業や価値観を逆引きする例:「売上が上がるとうれしい」→売上の重要度が高いことが推測できる |
プレッシャーを感じるタスクや苦労していること | 改善の余地がある業務や課題を把握する |
現在の解決策や工夫 | ユーザー独自の対処法・抜け道を把握する |
学習方法・操作のコツ | 習熟度による行動の違いを分析する |
とくに「やりがいやモチベーション」「プレッシャーを感じるタスクや苦労」といった主観的な要素を深掘ることで、数値では見えないユーザー体験の実感値を把握できます。
ユーザーインタビューの品質は、事前準備によって大きく左右されます。
ここでは、インタビュー実施に向けて最低限準備しておきたい項目を整理します。
開催場所は記録用の録音・録画が可能な場所を選びます。
会議室など撮影が可能で外部からの影響を受けにくい静かな場所が理想的です。
対面が難しい場合は、Google Meetやzoomなどのオンライン会議ツールも活用できます。
日程調整には、インタビュー対象者・インタビュアー・クライアント担当者など複数人の予定をすり合わせる必要があります。
対象者の確保が優先されるため、なるべく早い段階での調整・確定が望ましいです。
インタビュー設計で作成した質問票をもとに、インタビュー対象者ごとに内容を調整した最終版を用意します。インタビュー中はこの質問票を使って進行しつつ、回答を記入することで記録の役割も果たします。インタビューを行う場所や状況に応じて、プリントするかデジタルデータで運用するかを判断します。
インタビュー実施までに時間的な余裕がある場合、インタビューの1週間ほど前に質問表を共有し、事前に記入してもらうこともあります。
対象者がインタビューの内容を事前に把握できるため当日の進行がスムーズになったり、回答内容をもとに深掘りしたいポイントや追加質問を準備できるというメリットがあります。
一方でインタビュー対象者やクライアントにとって負担となる可能性もあるため、事前記入をお願いするかどうかはクライアントと相談しながら判断するのが望ましいです。
ユーザーインタビューは限られた時間の中で、できるだけ深い情報を引き出す必要があります。実施前の準備や姿勢によって、得られる示唆の質が大きく変わってきます。
インタビューは時間のロスを避けることが重要です。あらかじめ「どの業務フローの、どのポイントについて、何を聞きたいか」まで整理して頭に入れておくことで、スムーズな進行と深堀につながります。
どの業務でどのような課題が発生していそうか、仮説を立てたうえで検証の場ととらえてインタビューに臨むことで、質問の精度や回答の解釈力が高まります。
仮説がない状態では質問や受け答えが表面的なものになり、有効な情報を引き出しにくくなります。インタビューの目的を改めて確認し、「このインタビューで何を持ち帰るべきか」を自分の中で明確にしておきましょう。
インサイトは「本人の実感」から生まれることが多いため、一般論や建前ではなく、個人の意見や感じ方を引き出すことが重要です。そのためには対象者との信頼関係づくりが不可欠です。ユーザーインタビューは多くの場合一期一会ですが、アイスブレイクでの雑談や、インタビュアーの前のめりなリアクションなどで話しやすい空気をつくることができます。
実際のインタビューは次のような手順で進めます。
インタビューの入り方は、その後の雰囲気や回答の深さに影響を与える重要なポイントです。形式的なやり取りにならないよう、関係者全員が安心して会話に参加できる土台をつくります。
インタビュアーから自己紹介を始めます。インタビュー対象者が複数名の場合も全員に一言ずつ自己紹介をしてもらうことで、場が和らぎ、会話しやすい空気をつくることができます。
限られた時間を有効に使うためにも、改めてインタビューの目的を伝えます。何のために話を聞いているのかが明確になることで、対象者も回答のイメージを持ちやすくなります。
「間違った回答はない」「率直な意見が価値になる」ことをあらかじめ伝え、なんでも話してほしいと依頼をします。また、話した内容が個人の評価や査定などに影響することは一切ないという点も、明確に伝える必要があります。
後からの振り返りや共有のため、録画を行う場合はその旨を事前に説明し、必ず同意を得てから実施します。録画データの利用目的や保管・廃棄方法などにも言及しておくと安心です。
本題に入る前に雑談を交えてやりとりを行うことで、インタビュー対象の緊張がほぐし、より話しやすい雰囲気をつくります。ここで得られる情報は、質問の切り口や深掘りポイントの調整にも役立ちます。
質問:
「自己紹介に関連して、そのお仕事ではどんな業務を担当されているんですか?」
得られる効果:
実際の業務内容を知ることで、質問をインタビュー対象者に刺さりやすくアレンジしたり、質問の順番や重点を調整するヒントを得られる
想定と異なる担当業務(例:「主担当ではない」など)に気づけることで、的外れな質問を避けられる
インタビューでは、質問表に従って進めますが、その場の状況や相手の回答に応じて柔軟に調整することが重要です。
インタビュアーはどの回答にも偏らず、中立的な姿勢を意識します。対象者が回答に時間を要した際に、無意識のうちにインタビュアー側に都合の良い回答に誘導してしまわないよう以下の点に注意します。
質問表はあくまでガイドラインです。全ての質問にこだわるよりも、対象者の関心や話の深度に合わせて柔軟に進行することで、より本質的な情報が得られます。
構造化インタビュー以外では、回答の背景や理由を深掘りする必要があります。しかし、深掘りするポイントやタイミングを見つけるには慣れやスキルが必要なため、インタビュー対象者が不満を抱えていそうな点を見つけることから始めます。とくに「困っていること」の裏には、ユーザーが言語化できていない課題や改善のヒントが隠れている場合があります。
▼主な深堀ポイント
1. 困っていることは何か
業務フローの各ステップで、どのような作業をしているか実態を丁寧に確認し、違和感や不満点を探ります。
2. 困っている理由は何か
「なぜ必要と感じるか」「どんな状況で困っているか」「ほかの手段はないか」など、背景を掘り下げることで本質的なニーズを明らかにします。
例)「送信ボタンが欲しい」という回答があった場合:
それはあくまでインタビュー対象者の希望であり、本質的な困りごとや背景とは異なる可能性があります。次のような問いを重ねながら、業務フローや業務内容を再確認します。
困りごとから得られる情報はインサイトの発見につながる場合が多いため、一つの困りごとに対して複数の質問を重ね、できるだけ多角的に情報を収集しておくことが大切です。
3. 言いにくい/気づきにくい課題はないか
上司や同僚といった関係者の前では話しにくい内容も含めて確認します。慣れや個人の裁量でカバーされている課題も、業務改善のヒントになり得ます。
たとえば以下のようなケースは、当人にとって当たり前でも、改善の糸口になるケースがあります。
このような作業を丁寧に拾いあげることで、表面化しにくい困りごとを可視化し、業務フロー自体を変えるような改善につながる可能性があります。
4. イレギュラーな対応や例外処理はあるか
標準フローでは見えない負担や工夫があることも多く、深堀することで構造的な問題(=特定の人や場面だけでなく、仕組み全体に起因する根本的な課題)や属人化の実態が浮き彫りになる可能性があります。
すぐに回答が出ない場合は、焦らず、考える時間を提供することが必要です。時間の制約があるなかでも、次のような手法で対話を促すことができます。
インタビューの最後には「他に話しておきたいことはあるか」「今日の内容以外で伝えておきたいことはあるか」と問いを投げかけます。あらかじめ設けられた質問では出てこなかった、予想外の回答やインサイトの発見につながる重要なヒントが表面化する場合もあるので、必ず聞くようにします。
最後にインタビューに協力していただいたことに対して感謝を丁寧に伝え、インタビューを終了します。
ここからは、得られた事実をどのように整理し、洞察へとつなげていくかを紹介します。
ユーザーインタビューで収集した情報を、ユーザーフローに落とし込みながら整理していきます。
事前に作成した仮説の業務フローを現場の実態に合わせてチューニングしし、現場で実際に起きている事象を可視化します。
そのうえで、次のような観点で精査していきます。
「頻度が高い作業」や「間違えると大きな影響を与えるような作業」に着目し、問題の深刻度やニーズの大きさをもとに分類します。
どこから優先的に改善に着手すべきか見極める判断材料となり、同時にクライアントの意思決定にも役立ちます。
複数のユーザーインタビューを通して、共通して困りごとが集中している箇所が見つかることがあります。
たとえば「同じ画面で似たようなつまずきが繰り返されている」といったケースでは、ボトルネックになっている操作や構造が明らかになります。
失敗につながる行動パターンを見つけ出すヒントになります。
ユーザーの発言の中に散らばったヒントや証拠を拾い集めていくことで、潜在的な課題や価値観=インサイトを捉えることができます。
陥りがちな失敗として、例えばユーザーから「ボタンが欲しい」と言われたとき、鵜呑みにしてそのまま実装してしまうと、本来の課題を見逃してしまうことがあります。
それが「機能」の問題なのか、「見た目」の問題なのかを聞き直すだけでも、課題の本質に近づくことができます。
インタビューを通して見えてきた問題点は、事実ベースでリストアップして整理していきます。
分析のフェーズではどうしても「こうすればいいのでは」といった解決策のアイデアが先に立ちがちですが、まずはできるだけフラットに、ユーザーの体験そのものを拾い上げることが大切です。
そのためにも、インタビューの段階から「何が起きていたのか」「どう感じていたのか」といった事実を丁寧に引き出しておくことが重要になります。
実際にまとめていく際には、次のような点を意識しましょう。
“どうすべきか”ではなく“何が起きていたか”を書くようにします。
例)タブに関する指摘があった場合:
×タブの色を明るくした方がいい
→解決策のアイデア(=気づき)を書いてしまっている
○タブに気づきにくい
→ユーザーが体験した事実に基づいた記述になっている
誰にとって、どんな問題があったのかが伝わるように、あくまでユーザー側の言葉で記述するよう心がけます。
例)「戻る」ボタンに関する指摘の場合:
×「戻る」ボタンがない
→機能の有無という設計側の視点になっている
○前の画面に戻れない
→ユーザーの体験として捉えた記述になっている
ユーザーインタビューを通じて見えてきた問題点は、目的に応じた分析手法を使って構造化していき、質的データ分析を行います。
代表的な分析方法には以下のようなものがあります。
ユーザーがサービスを体験するプロセスを、時間軸に沿って構造的に整理する手法です。
ユーザーの行動・思考・感情などを軸に、課題や提供すべき価値を可視化します。フォーマットはプロジェクトによって柔軟に設計されることが多く、抽象度や粒度も分析の目的に応じて調整します。
ユーザーとサービス提供側の関係性を、タッチポイントごとに整理する手法です。
ユーザーが目にする表層的なインターフェースだけでなく、裏側でどのようなオペレーションが行われているかまでを明らかにすることで、提供側の課題発見や改善に役立ちます。
インタビューなどで集まった情報をカードに書き出し、グルーピング・図解・言語化していく手法です。
構造を整理することで共通項や背景にある価値観を発見し、ユーザーの行動や判断の理由を深く読み解くことができます。1枚のカードには1つの情報のみを記述しますが、思い込みや推測で分類しないようコンテクストや気持ちなども明記します。
出来事(行動や発言などの事実)を起点に、そこに潜むユーザーの気持ちや価値観を導き出す手法です。
出来事に対する心の声を推測し、それぞれの価値にグルーピングすることで、「何が大事なのか」という軸で分析できます。価値ごとにグルーピングした価値マップを作成します。
インタビューなどから気になる語句を抜き出し、それを一般化・構造化していく手法です。
語句同士のつながりをたどることで、頭に浮かんだテーマや概念を複数積み上げたストーリーライン(意味や意義を物語のように書き表したもの)から理論(命題や定義)を導き出します。
データの中で意味のある文章に概念名を与えて整理し、それらをまとめて全体像やモデルを描く手法です。数値だけでは解明できない関係性や仕組みを浮き彫りにします。
ベイジでは、カスタマージャーニーマップをベースに課題整理を行い、インサイトを見出して改善方法や対策アイデアを考える進め方をとることが多いです。
プロジェクトによってはKJ法を併用するなど、対象の特性に応じて他の手法も組み合わせます。
これらの分析内容をもとにクライアントへのリサーチ報告書や改善提案書として整理し、クライアントと認識を共有するところまでをセットで行います。
ユーザーが製品やサービスをどう使っているか。その実態は、作り手や提供者が想像している姿とは意外と違っているものです。開発者や担当者にとって“都合のいいユーザー像”ではなく”ユーザーの実態“を知ることで、現実によりフィットした製品やサービスを提供できるようになります。
ユーザーインタビューはただ質問をして答えてもらうだけではありません。目的に沿って会話を組み立てるための準備や設計、想定外の展開にも対応できる柔軟な進行力、そして相手と信頼関係を築くためのコミュニケーション力など、多くの要素が求められる奥の深いプロセスです。
とくに、得られた情報を的確に捉え、構造化して意味を読み解いていくには、定性的なデータの扱いに慣れている必要があります。
初めて取り組む方はうまくいかないこともあるかもしれませんが、経験を重ねながら少しずつコツをつかんでいくことが何より大切です。
ベイジでは、Webサイトやシステムのリニューアルなどを実施する前にできるだけ多くのユーザーの声を拾うようにしています。そしてその声を社内だけで留めず、クライアントとも共有することで、共通の理解に基づいた判断や改善につなげています。
インタビューは、相手の言葉にならない気持ちをくみ取ったり、場の空気を読みながら深掘ったりと、想像以上に多くのスキルが求められる仕事です。そのため、ベイジでは複数名でインタビューに臨むことを基本とし、経験豊富なメンバーが同席して、必要に応じて質問の補足や視点のフォローを行います。
こうした体制を整えることで、チームでインタビューの質を担保しながら、ユーザーの声を丁寧にすくい取ることができています。たとえ経験の浅いメンバーが関わる場合でも、単独で任せるのではなく、経験者がしっかりとサポートに入り、精度の高いインタビューを実現します。
ひとりで完璧を目指すのではなく、チームで補い合いながら、正しくユーザーの声を受け止めていく。その姿勢を、私たちは大切にしています。