业务场景采集方法全景
MVP场景提炼的第一步是系统化采集业务场景。现场观察、用户访谈、日志分析、数据埋点分别从行为、认知、痕迹、量化四个维度覆盖场景发现。四种方法相互补充，形成“定性+定量”“主动+被动”的采集闭环。
核心原则： 先定性（现场观察+用户访谈）确定“是什么”，后定量（日志分析+数据埋点）验证“有多少”；避免仅凭单一方法产生场景盲区。
| 采集方法 | 核心产出 | 适用阶段 | 优势 | 局限 |
|---|---|---|---|---|
| 现场观察 | 用户行为录像、操作卡点清单 | 探索期、验证期 | 真实环境下的行为全貌 | 样本量小，受观察者效应影响 |
| 用户访谈 | 用户故事、痛点陈述、期望列表 | 探索期、概念期 | 深挖动机与决策逻辑 | 存在回忆偏差，难以量化 |
| 日志分析 | 操作路径、频率、异常退出序列 | 上线后、迭代期 | 海量客观数据，无干预 | 缺乏上下文，无法解释“为什么” |
| 数据埋点 | 事件流、转化漏斗、自定义指标 | MVP上线后、增长期 | 精准追踪预定义行为 | 埋点定义成本高，漏埋则数据缺失 |
现场观察：发现真实行为落差
走到用户的工作或生活场景中，记录他们在自然状态下与现有产品/流程的交互。重点记录：操作顺序、犹豫点、备用方案、以及环境干扰因素。每轮观察至少覆盖3个不同细分用户，产出“行为走查表”。
避坑指南： 观察员不要主动提问或指导，保持“沉默的摄像机”角色；若用户询问，回答“按您平时的做法就好”。
用户访谈：挖掘故事背后的场景
采用半结构化访谈，围绕“过去一周内最麻烦的一次使用经历”展开。用5W1H框架（Who/When/Where/What/Why/How）逐层追问，剥离出核心场景要素：触发条件、目标、障碍、情感体验。每轮访谈后生成一篇用户故事摘要，作为场景描述依据。
用户访谈输出模板：
用户身份：XX角色
场景标题：XX流程中无法完成XX操作
触发事件：当用户需要XX时
操作路径：点击A→等待→失败→尝试B→放弃
真实痛点：系统反馈不明确，导致重复尝试
期望行为：一键完成或明确提示下一步日志分析：从埋点数据反推场景
如果已有上线系统或竞品，通过分析用户操作日志（点击流、页面停留时长、错误码分布）发现高频失败路径。日志分析适合定位“沉默的流失点”——用户没有抱怨但数据异常的区域。需配合会话重绘重建操作序列。
注意： 日志维度缺失（如无唯一用户标识、无时间戳精度）将导致无法还原场景，分析前必须先校验数据质量。
数据埋点：主动定义可量化的场景边界
在MVP上线前规划埋点事件表，每个事件对应一个潜在场景节点。埋点设计必须包含：事件名、触发时机、携带参数（如用户角色、耗时）、唯一会话ID。小团队推荐采用“前端自动化埋点+关键业务手动埋点”混合方案。
示例埋点事件JSON定义（用于日志收集）：
{
"event": "create_order",
"properties": {
"user_role": "buyer",
"item_count": 2,
"total_amount": 189.00,
"elapsed_ms": 4500,
"result": "success"
},
"session_id": "sess_abc123"
}跨方法配合：避免“采集孤岛”
在MVP场景提炼中，推荐采用“观察→访谈→埋点→日志验证”的流水线：先用现场观察发现异常行为片段，通过访谈深挖原因，再将关键行为定义为埋点事件，最后用日志分析验证场景发生频率与分布。这套流程能确保提炼出的场景既有真实上下文，又有量化依据。
小团队实践建议： 第一个MVP不必四种方法全用。如果资源紧张，优先做“用户访谈+简易埋点”（自定义事件即可），覆盖70%以上的关键场景。后续迭代时再补充日志分析和现场观察。
交付物模板：场景采集卡片
每种方法完成后，将结果汇总为标准卡片，便于后续业务梳理。卡片模板如下：
【场景编号】S-2025-xxx
【采集方法】现场观察 / 用户访谈 / 日志分析 / 数据埋点
【用户画像】目标用户角色 + 典型环境
【触发条件】在什么情况下发生
【实际行为】用户做了什么（含失败尝试）
【真实痛点】用户困难、情绪、绕过的做法
【频率/规模】单用户发生次数 / 总用户占比（定量方法适用）
【业务影响】对转化、留存、成本的影响将卡片按优先级排序，即可进入第三章的“业务场景拆解”环节。