第1章：识别用户原话的场景来源
用户原话不是凭空出现的——每一条“用户说……”背后都藏着具体的记录渠道、触发条件和说话人角色。这三个维度决定了原话的可信度、完整度以及它到底反映的是真实痛点还是瞬时情绪。本章帮你建立第一个分析框架：拿到原话后，先问三个问题——谁说的、在什么情况下说的、通过什么方式留下的。
核心认知：忽略场景来源是需求误判的第一根源。同一个“太慢了”，客服投诉 vs 产品体验会随口一说， 处理优先级完全不同。
1.1 记录渠道
原话被记录下来的载体直接影响了信息的保真度和可回溯性。不同渠道的语态、完整度、噪声水平差异很大。
| 渠道类型 | 典型形式 | 信息完整度 | 适用场景 |
|---|---|---|---|
| 客服/工单系统 | 文本工单、通话录音摘要 | 中等（通常经过客服转述） | 高频投诉、故障排查 |
| 用户访谈/可用性测试 | 录音/录像+逐字稿 | 极高（原话保真） | 深度需求挖掘、概念验证 |
| 问卷/反馈表单 | 开放题文本 | 低（受限于字数） | 大规模收集、满意度调研 |
| 社交媒体/论坛 | 帖子、评论 | 低-中等（情绪化、碎片化） | 竞品观察、舆情监控 |
| 产品内反馈入口 | 嵌入式弹窗/热区反馈 | 中等（上下文关联） | 功能触发时的即时反馈 |
1.2 触发条件
用户是在什么情境下说出这句话的？主动触发还是被动触发？是否受到预设问题引导？
- 主动抱怨/求助：用户遇到阻碍，自己找上门。原话通常真实、带情绪、具体，但容易放大严重性。
- 被动询问（访谈/问卷）：用户被邀请表达。可能受社会期望偏误影响，倾向说“好话”或“标准答案”。
- 操作后反馈（功能内触发）：用户在完成某个动作后被问“刚才的体验如何？”——原话与具体操作绑定，精准度高。
- 观察/监测（日志+录屏）：不是用户说的，而是通过行为推断其意图。属于“无声的原话”，需要结合上下文解读。
实用参考：在记录每条原话时，至少标注一个触发条件标签，例如
[主动投诉]、[访谈中引导]、[完成支付后弹出]，便于后续分析时决定该条原话的“权重”。
1.3 说话人角色
原话的“含金量”与说话人在产品生态中的位置密切相关。同一句话出自不同角色，解读方向完全不同。
| 角色 | 典型特征 | 需求价值 | 需警惕的偏误 |
|---|---|---|---|
| 普通终端用户 | 直接使用产品，非技术背景 | 反映日常痛点、可用性问题 | 归因不准确、提出伪解决方案 |
| 重度/核心用户 | 高频使用，对功能逻辑熟悉 | 能发现深层次效率漏洞 | 可能过分依赖现有习惯 |
| 业务决策者（老板/管理层） | 不下场操作，关注宏观数据 | 说出业务目标、战略诉求 | 脱离实操细节，要求不符实际 |
| 一线执行者（客服/运营） | 间接面对用户，处理大量案例 | 提供模式化问题和共性反馈 | 转述过程中丢失细节 |
| 合作伙伴/集成方 | 需要与产品进行对接或二次开发 | 提出接口、标准、兼容性需求 | 容易过度抽象、忽略终端体验 |
常见陷阱：不要因为“这个用户说话声音大”就优先处理，也不要只盯着决策者原话而忽略真实用户的声音。正确的做法是：先给每条原话打上“角色标签+渠道标签+触发条件标签”，再放在同一个分析池里横向比较。
场景来源结构化框架
下面这张图将三个维度整合为一个前置分析工具，帮助你快速建立场景语境。每次整理用户原话时，都可以对照这个框架进行编码。
有了这个框架，你可以把散落的用户原话按记录渠道→触发条件→说话人角色的路径编码，形成结构化的需求线索池。下一阶段（第2章）将基于这个场景标签，进一步识别原话背后的业务问题。
实践任务：从你最近接触的用户反馈中抽出5条原话，分别标注其记录渠道、触发条件、说话人角色，并简单说明每条原话在当前场景下的可信度（高/中/低）。这个任务可以在接下来的课程中持续使用，作为后续需求拆解的原始素材。