プロダクト内サーベイは、ユーザーがサービスを利用している最中や、関連するアクションの直後に表示されます。タスクがどれくらい簡単だったか、目的を達成できたか、何をしようとしていたかなどを尋ねるのが一般的です。タイミングを絞ることで質問をより具体的にできる反面、誰が回答する機会を得るかもそのタイミングによって決まります。

初期設定の完了後に表示されるプロンプトは、その段階まで到達できた人の声しか拾えません。それより前の段階で離脱してしまった人たちについては、ほとんど何も分からないのです。

トリガーと質問内容を一致させる

その質問がどの体験に関するものなのか、そしてその体験を確実に示すイベントは何かを見極めましょう。機能を開いたからといって実際に使ったとは限りませんし、確認画面にたどり着いたからといって、ユーザーが結果を理解できたとは限らないからです。

たとえばデータのエクスポート機能なら、ダウンロード後の質問で「ファイルに必要なものが含まれていたか」を聞くことができます。まだファイルを開いてもいない段階での表示は、その判断をするには早すぎます。もしエクスポートが失敗する理由を理解したいのであれば、成功時にトリガーされるフィードバックとは別の情報源も必要になります。

Nielsen Norman Group による定量的調査手法の概要でも、コンテキスト内で実施されるサーベイが取り上げられています。「直後の回答のほうが常に正確だ」と思い込まず、表示のタイミング自体をリサーチ設計における重要な判断として捉えましょう。

割り込みは必要最小限に抑える

その瞬間の調査に必要なことだけを尋ねるようにします。簡単な評価スケールと自由記述の組み合わせは効果的ですが、ワーディングや尺度の設定には配慮が必要です。顧客の労力（CES）と満足度は体験の異なる側面を捉えるものであり、小さなプロンプトに収まるからといって安易に入れ替えてはいけません。

アンケートを閉じられるようにし、表示頻度も適切にコントロールしましょう。頻繁に表示されると日常的に使うユーザーの負担になり、回答してくれる層の偏りにもつながります。また、実際に使われるデバイスでアクセシビリティや挙動をテストすることも大切です。

回答者は「選ばれた一部」として捉える

配信の条件、表示回数、回答数、そして関連するコンテキストを記録しておきましょう。同一人物からの複数回の回答は別々のユーザーとは見なせませんし、トリガー条件を変更しただけで結果にトレンドが生じたように見えることもあります。

一般的な主張を導き出す前に、サーベイ設計の原則を活用し、無回答（回答しなかった人たち）の影響も検証してください。プロンプトが届かない層について知る必要があるなら、インタビューや別のリクルーティング方法で補いましょう。

この手法が最も力を発揮するのは、特定のわかりやすい瞬間に焦点を当てて声を集め、チームが分析時にもそのスコープを正しく維持できているときです。手近に集まったフィードバックを、あたかもユーザー全体の声であるかのように扱ってしまうと、判断を誤ることになります。