第三章：用户访谈与场景还原
好，我们进入第三章。这一章我特别想跟你聊聊——用户访谈和场景还原。
说实话，很多AI产品经理在这块栽过跟头。我自己也踩过坑。刚入行那会儿，我拿着录音笔去访谈用户，回来整理了几十页记录，结果发现——全是废话。用户说的和实际做的，完全是两码事。
为什么会这样？因为用户会撒谎。不是故意的，是大脑会自动美化自己的行为。所以，我们需要一套方法论，把用户嘴里的话，翻译成真实的需求。
3.1 结构化访谈技巧
先说说访谈。我个人的习惯是：不做无准备的访谈。你想想看，如果你连问什么都想不清楚，用户凭什么给你有效信息？
3.1.1 访谈前的准备清单
| 准备项 | 具体内容 | 我的经验 |
|---|---|---|
| 明确目标 | 这次访谈要验证什么假设？ | 一次只聚焦1-2个核心问题 |
| 用户画像 | 被访者的角色、使用频率、痛点 | 别找“典型用户”，要找“极端用户” |
| 访谈提纲 | 5-8个核心问题，留出追问空间 | 问题要开放，别问“是不是” |
| 环境准备 | 安静、无干扰、最好在用户工作现场 | 我在用户工位旁访谈，效果比会议室好3倍 |
3.1.2 提问的“三不”原则
嗯，这里要注意。提问方式直接决定你拿到的信息质量。我总结了三个“不”：
- 不问“你会不会用”——用户永远说“会”。要问“你上次用是什么时候？当时发生了什么？”
- 不问“你觉得怎么样”——太抽象。要问“你当时为什么点了那个按钮？”
- 不问“你希望有什么功能”——用户不是产品经理。要问“你遇到这个问题时，最想先解决什么？”
核心心法：让用户讲故事，而不是做判断题。
3.1.3 追问的艺术
我曾经访谈一个客服主管，她说“我希望AI能自动回复客户消息”。我追问了一句：“你希望它回复到什么程度？”她想了想说：“至少别让客户觉得是机器人。”——你看，这才是真实需求。
追问技巧就三个字：“然后呢？”。用户每说一个观点，你就追问一次。一般追问3-5次，就能挖到根因。
小技巧：访谈时录音，但别记笔记。眼神交流比文字记录重要100倍。我一般结束后30分钟内，凭记忆整理要点——这时候印象最深。
3.2 5W1H场景分析法
访谈完了，拿到一堆故事。怎么变成需求？我推荐用5W1H。
说白了，就是给每个用户行为贴上六个标签：
- Who —— 谁在做？他的角色是什么？
- When —— 什么时间？频率如何？
- Where —— 在什么环境下？
- What —— 做了什么操作？
- Why —— 为什么这么做？动机是什么？
- How —— 怎么做到的？步骤是什么？
3.2.1 一个真实的案例
我之前做一款AI客服产品。访谈了一个电商客服，她提到：“我每天要手动把客户地址复制到物流系统，太烦了。”
用5W1H拆解一下：
| 维度 | 内容 | 需求转化 |
|---|---|---|
| Who | 客服专员，日均处理200+订单 | 高频操作者，效率敏感 |
| When | 每天下午3-5点，订单高峰期 | 需要实时响应，不能有延迟 |
| Where | 在客服系统界面，同时开着物流系统 | 需要跨系统数据打通 |
| What | 复制地址→切换窗口→粘贴→提交 | 操作步骤多，易出错 |
| Why | 因为两个系统不互通，只能手动 | 核心痛点是系统集成 |
| How | 每次操作约30秒，一天浪费2小时 | ROI明确：节省人力成本 |
你看，从“复制地址太烦”这句话，我们推导出的需求是：自动识别地址并一键推送到物流系统。而不是“做个复制按钮”。
避坑指南：我曾经犯过一个错——用户说“我想要个搜索框”，我就做了搜索框。结果没人用。后来用5W1H一分析才发现，用户真正需要的是“自动推荐最近使用的功能”，不是搜索。所以，别听用户说的功能，要听用户说的场景。
3.3 从用户故事中提取需求
好，现在我们有了一堆场景卡片。怎么变成产品需求？我习惯用“用户故事”来过渡。
用户故事的格式很简单：
作为 [角色]
我想要 [功能]
以便 [价值]但这里有个坑——很多人写成了“作为用户，我想要一个搜索框，以便找到东西”。这跟没写一样。
3.3.1 高质量用户故事的三个要素
- 角色要具体：别写“用户”，要写“新入职的客服”、“每天处理200单的老手”
- 功能要可验证：别写“系统要智能”，要写“系统能自动识别地址并填充”
- 价值要可量化：别写“提高效率”，要写“每次操作从30秒降到5秒”
3.3.2 从故事到需求的转化流程
我个人习惯用三步法：
- 写故事：用用户的原话，不加修饰。比如“我每天要复制粘贴地址，手都酸了”
- 拆场景：用5W1H拆解，找到关键变量。比如“高峰期”、“跨系统”、“重复操作”
- 定需求：把场景转化为功能点。比如“地址自动识别”、“一键推送”、“操作日志”
举个例子：
用户故事：“我每次要查客户的历史订单，得翻好几个页面，烦死了。”
拆解后：Who=客服主管，When=客户来电时，Where=客服系统，What=翻页查找，Why=需要快速了解客户，How=平均耗时2分钟
最终需求：在来电弹屏中，自动展示该客户最近3笔订单的摘要信息
3.3.3 需求优先级怎么排？
嗯，这里有个实用工具——场景频率 × 痛点强度矩阵。我一般这么用：
| 痛点强度 | 高频场景 | 低频场景 |
|---|---|---|
| 高痛点 | P0（必须做） | P1（可以做） |
| 低痛点 | P1（可以做） | P2（先放着） |
怎么判断痛点强度？我有个土办法——看用户愿不愿意为这个功能多花5秒钟。如果用户说“要是能省掉这步就好了”，那就是高痛点。如果用户说“有也行，没有也行”，那就是低痛点。
我的经验：别贪多。一次只做1-2个P0需求。我见过太多团队，一口气列了20个需求，结果一个都没做好。记住：少即是多。
3.4 本章小结
好，我们来捋一下。这一章的核心就三件事：
- 结构化访谈：别问“你觉得”，要问“你做过”。追问3次以上。
- 5W1H场景分析：把用户故事拆成六个维度，找到真实场景。
- 用户故事提取需求：从故事到场景，从场景到功能，从功能到优先级。
下一章，我们会聊怎么把这些需求变成可落地的产品方案。到时候我会分享一个我踩过的巨坑——需求评审会上被开发怼到哑口无言的故事。嗯，先卖个关子。
记住：用户说的不是需求，用户做的才是。