第2章 用户场景采集：场景来源、场景描述模板、场景优先级
本章核心目标：掌握从多触点收集用户场景的渠道方法，能够使用标准模板描述场景，并基于业务价值对场景进行优先级排序，为PRD中的需求拆解提供原始素材。
2.1 场景来源：五大采集渠道
用户场景的采集不是随机收集，而是有目标地从业务发生的主要触点获取。每个渠道对应不同的真实性与颗粒度，产品经理需要组合使用。
| 来源渠道 | 核心方法 | 典型产出物 | 场景真实性 |
|---|---|---|---|
| 内部收集 | 客服工单、销售反馈、技术支持日志 | 高频问题列表、用户投诉聚类 | 高（已发生） |
| 用户访谈 | 半结构化访谈、焦点小组、现场跟访 | 用户旅程地图、关键行为片段 | 中高（回忆+观察） |
| 数据分析 | 埋点事件分析、漏斗分析、留存/流失 | 行为路径、功能使用频次、断点位置 | 高（行为数据） |
| 竞品监测 | 竞品测评报告、应用商店评论、行业研报 | 竞品功能清单、用户痛点分布 | 中（间接推断） |
| 行业研究 | 政策法规、行业标准、学术论文、技术趋势 | 前瞻性场景假设、合规性约束 | 低中（推测未来） |
采集原则：至少覆盖“内部收集 + 用户访谈 + 数据分析”三个渠道才能形成完整场景视图；仅依赖单一渠道容易产生偏差。
2.2 场景描述模板
原始场景信息零散模糊，必须按固定模板结构化记录，才能进入PRD分析流程。推荐使用五要素场景模板：
【场景编号】SC-2024-XXX
【用户角色】（谁在执行操作）
【前置条件】（什么状态或环境中）
【触发事件】（什么原因启动该场景）
【行为步骤】（1. → 2. → 3. ……）
【期望结果】（用户希望达到的目标/痛点解决）完整示例（以售后换货流程为例）：
【场景编号】SC-2024-006
【用户角色】已下单且收货的普通买家
【前置条件】订单状态为“已签收”，商品存在非人为外观破损
【触发事件】买家打开APP首页，点击“我的订单”进入订单列表
【行为步骤】
1. 在订单列表中找到目标订单，点击“申请售后”
2. 在售后类型中选择“换货”
3. 上传商品破损照片（至少2张）
4. 填写换货原因描述（文本输入）
5. 选择换货寄回方式（上门取件 / 自行寄回）
6. 提交申请
【期望结果】申请提交成功，系统返回售后编号，页面展示预计审核时长；用户可在售后详情页实时跟踪换货进度。
经验警示：初学者最容易遗漏“前置条件”和“触发事件”，导致后续原型设计时无法确定初始页面状态和进入路径。每个场景必须明确从哪张页面、什么状态开始。
2.3 场景优先级：影响范围 × 紧急度
用户场景通常数量众多（一次完整采集可能在30-80个），必须定义优先级规则筛选进入PRD的需求范围。推荐使用二维矩阵评估：
- 维度一：影响范围（受众规模 + 功能依赖）
- P0（高）：覆盖核心用户群体80%以上，或被下游功能严重依赖
- P1（中）：覆盖主要用户群体30-80%，模块内独立
- P2（低）：仅覆盖小众用户或低频操作，可延后
- 维度二：紧急度（业务损失 + 竞争压力）
- 紧急：已有明确用户投诉/业务流失/竞品已上线
- 普通：用户有诉求但当前替代方案可接受
- 未来：完全新增机会点，无竞争威胁
定级陷阱：不要将所有场景都标记为P0/紧急。PRD承载的是“当前版本必须交付”的需求，每个迭代周期应控制P0场景不超过5个（含已有功能优化）。大量高优级场景堆积会削弱原型设计的聚焦能力。
| 优先级 | 影响范围 | 紧急度 | 准入PRD |
|---|---|---|---|
| P0 | 高 | 紧急 | 是，必须进入当前版本 |
| P1 | 高 | 普通 | 评估技术成本后进入或延期 |
| P1 | 中 | 紧急 | 进入当前版本，但精简范围 |
| P2 | 中 | 普通 | 放入需求池，后续迭代 |
| P3 | 低 | 未来 | 记录但暂不投入设计 |
在PRD中，每一条用户故事都必须标注其场景编号与优先级，以此作为原型设计阶段决定页面深度与交互细节的依据。