ユーザーリサーチの分析フレームワーク：メモからテーマへ

ユーザーリサーチの分析フレームワークは、インタビューメモから共通するテーマを見つけ、次の判断につなげるための枠組みです。何を観察したのか、どのようにパターンを見つけたのかを残しておくと、結論を見直すときも根拠に戻れます。調査計画から始める場合は、ユーザーリサーチ計画テンプレート（英語）も参照してください。

インタビューメモをコード、テーマ、プロダクトの改善判断へ整理する流れ — メモを整理し、共通するテーマから次に検証する課題を見つけます。

1. 分析で答える問いを決める

メモにコードを付ける前に、分析で何を判断したいのかを一文で書きます。たとえば「オンボーディングのどの問題を次に検証するか」という問いです。対象ユーザー、プロダクトの範囲、判断の対象期間も明記します。興味深いだけで意思決定につながらない観察に、分析が広がりすぎるのを防げます。

最初に整理する四つの項目

問い：まだ決まっていないことは何か。
根拠：どのインタビュー、タスク、資料を分析するか。
制約：今回の検討では変更できないことは何か。
成果物：プロダクト、デザイン、サポートの担当者へ何を渡すか。

2. メモの形式をそろえる

各メモを、短い観察内容、参加者の状況、参照元に分けます。参加者の言葉と調査者の解釈は混ぜません。「変化が見えなかったので、2回クリックした」は参加者の発言です。一方、「画面のフィードバックが不足している」は、その発言から考えた、検証すべき仮説です。

意味のある観察一つにつき、カードを一枚使います。インタビュー番号やタスク名を添え、共有ボードには個人を特定できる情報を載せないようにします。

3. 話題だけでなく行動にコードを付ける

コードとは、メモの内容を短く表すラベルです。「状態を探す」「同じ手順を繰り返す」「確認を求める」「エラー後に離脱する」など、行動を表すコードから始めます。「ダッシュボード」「通知」といった話題名は分類には便利ですが、何を変えるべきかまでは分かりません。根拠があれば、一つのメモに複数のコードを付けても構いません。

一通り分類したら重複するコードをまとめ、それぞれに一行の定義を添えます。ほかの調査者も同じ基準で使えるようにすることが目的です。

4. 観察をまとめ、テーマを言葉にする

似た行動やニーズを示すメモをまとめます。テーマは、状況とその結果が分かる文で書きます。たとえば「招待が送信されたか分からないため、ユーザーが同じ操作を繰り返したり、同僚に確認したりする」です。「使いにくいUI」だけでは、根拠も次に取り組むべきことも伝わりません。

テーマを裏付けるメモだけでなく、当てはまらないメモや未確認の点も残します。どこまでが今回の根拠から言えることなのかを区別してください。

5. テーマから改善の問いを作る

各テーマを「操作を増やさずに、招待の状態を伝えるにはどうすればよいか」のような問いに変えます。解決策を先に決めなければ、後で複数の案を比較できます。次の検証内容と担当者も記録します。

たとえば、次のように整理できます。

テーマ	根拠	改善の問い	次の検証
招待の状態が分かりにくい	二つのタスクにまたがる3件のメモ	招待の状態をどう伝えるか	状態表示のプロトタイプを試す
次の行動が分からない	データがない初期画面での2件のメモ	最初の一歩をどう案内するか	案内文を2案比較する

6. 判断する前に不確実な点を確認する

優先順位を決める前に、どのような情報があれば解釈が変わり得るかを考えます。調査の設計に沿って、参加者の状況、タスク、ユーザー層ごとの違いを比較します。少人数の調査や、特定の条件で参加者を選んだ調査の結果を、そのまま全ユーザーの割合として扱うことはできません。未解決の問いと、それに答えるために必要な情報を残します。