为什么数据告诉你不够，还得去聊人
数据分析能告诉你用户在产品里点了什么、卡在哪一步，但它解释不了"为什么"。一个功能没人用，是因为找不到、不好用、还是根本不需要？这些数字答不出来，只能靠和用户真正聊一次。
用户访谈（User Interview）的价值，就是把冷冰冰的行为数据背后的动机挖出来，让产品方向不再只靠猜。
数据告诉你发生了什么，访谈告诉你为什么发生。
本文核心知识点
- 选人找对真正的目标用户。
- 提问问行为与场景，不问看法。
- 编码把对话归成可复用的洞察。
- 落地洞察要变成产品决策。
招对人：访谈对象怎么选
访谈最大的浪费，是花了时间却聊了错的人。聊一个已经不用你产品的人和聊一个正在深度使用的人，得到的洞察完全不是一回事。
| 访谈对象 | 适合了解的问题 | 注意点 |
|---|---|---|
| 活跃重度用户 | 真实使用场景与价值点 | 别只听夸奖 |
| 流失用户 | 放弃的真实原因 | 给点反馈激励 |
| 新注册未激活 | 上手卡点 | 越近记忆越真 |
| 目标潜在客户 | 当前替代方案 | 别推销，只聊 |
一般来说，围绕一个问题聊六到八个典型用户，核心模式就会开始浮现。
问对问题：从要什么到为什么
新手最常犯的错，是直接问用户"你想要什么功能"。用户往往答不好，或者给一个他以为自己想要、其实并不会用的东西。好的访谈要聊的是他过去的真实行为，而不是对未来的想象。
# 访谈提问的三条原则
1. 聊具体场景：上次你是怎么解决这件事的
2. 聊真实行为：当时你先点了哪里、卡在哪
3. 少问假设：你会用吗 不如 你上次怎么做的当用户开始讲他具体的、带情绪的故事，你离真问题就近了。
把对话变成洞察：编码与归类
聊完一堆访谈，如果不整理，最后就只剩一堆印象。把录音转成文字后，要做的是编码：把反复出现的问题、痛点、场景归成几个类别，再数每一类被多少人提到。
| 原始对话片段 | 归到的类别 | 被提到次数 |
|---|---|---|
| "我不知道从哪里开始" | 上手引导缺失 | 5 |
| "导出格式我用不上" | 导出能力不够 | 3 |
| "想拉同事一起但不知道怎么弄" | 协作流程不顺 | 4 |
| "文档写得太技术" | 文档门槛高 | 2 |
被多人反复提到的，才是值得产品团队认真对待的洞察，而不是某一个人的随口抱怨。
从洞察到产品方向：别只停在结论
一份好看的访谈报告如果没人用，等于白做。洞察的价值，在于它能不能直接变成产品团队的决策依据。
- 问题重排：把洞察按影响人数与痛感排序。
- 机会定位：哪些痛点是竞品也没解决的。
- 方向输入：给下个版本的优先级提供依据。
- 持续校准：新洞察不断更新用户画像。
当访谈结论直接进了产品 roadmap，研究才算真正闭环。
常见误区：把访谈当验证已有想法
团队做用户访谈最常见的坑：
- 引导式提问：开场就暗示答案，用户顺着你说。
- 只招铁粉：全是夸你的人，听不到真问题。
- 当成推销：访谈变成现场卖产品。
- 不整理：聊完就扔，报告没人看。
- 只做一次：产品在变，用户也在变。
自查方式：把你最近一次访谈的问题单拿出来，如果每个问题都带着你心里已有答案的暗示，这份访谈基本就废了。
一套可落地的访谈节奏
把用户访谈排成可持续的节奏：
# 每月
1. 围绕一个核心问题聊 6-8 个用户
2. 把对话编码成 3-5 类洞察
# 每季度
3. 把洞察同步给产品与市场团队
4. 更新用户画像与场景库
# 持续
5. 流失与高价值用户保持长期回访用户访谈不是一次性的调研项目，而是一种持续听见真实用户的习惯。当产品团队习惯于"先聊人再动手"，方向就不再靠拍脑袋。
先听见真实的人，再做产品里的决定。