场景描述结构化：人物、目标、触发条件、步骤、预期结果
在 MVP 场景提炼中，仅仅记录“用户在什么情况下做什么”远远不够。产品团队需要一套可复用、可验证、可移交的结构化描述框架，让每个场景候选都能被所有人无歧义地理解，并直接指导业务流程梳理。本章将落地五个核心要素：人物、目标、触发条件、步骤、预期结果。
五要素定义速览
| 要素 | 定义 | 检查要点 |
|---|---|---|
| 人物 | 执行该场景的用户角色或系统角色 | 角色名称是否具体？避免“普通用户”，用“新注册买家” |
| 目标 | 该场景下人物想要达成的业务/体验结果 | 目标是否可度量？例如“3 分钟内完成退货申请” |
| 触发条件 | 启动场景的明确事件或状态 | 条件是否客观可观测？避免“用户感觉不好” |
| 步骤 | 从触发到完成的关键操作序列（5~8 步） | 步骤是否跳过异常分支？异常分支另建场景 |
| 预期结果 | 场景完成后交付物、状态变化或系统响应 | 结果是否能被测试验证？例如“订单状态→已退款” |
示例：电商退货申请场景
以“买家在订单详情页发起退货”为例，看结构化描述如何落地：
| 要素 | 描述 |
|---|---|
| 人物 | 已登录且已收货的买家 |
| 目标 | 在 5 分钟内提交退货申请并看到“审核中”状态 |
| 触发条件 | 买家在订单详情页点击“申请退货”按钮 |
| 步骤 |
|
| 预期结果 | 系统生成退货单（ID: RET-xxx），订单状态变为“退货审核中”，买家收到通知弹窗 |
结构化落地要点： 每个场景的步骤应控制在 5~8 个主步骤，超过则考虑拆分为子场景；预期结果必须绑定可验证的系统状态或数据变化，避免模糊描述。
五要素关系图
下图中，五个要素按“谁 → 为什么 → 何时 → 怎么做 → 得到什么”逻辑串联，构成完整的场景描述骨架：
实践建议： 在用户访谈后，立即使用五要素格式整理场景卡片。每张卡片对应一个结构化场景，后续拆解需求、绘制异步流程、编写验收条件时都可直接引用。通过 “一个场景一张卡片” 的格式，让非产品角色（开发、测试、运营）也能独立理解业务上下文。
常见避坑
- 人物泛化：不要写“用户”，要写“已登录未付费访客”或“企业管理员”。不同角色有不同目标与步骤。
- 目标模糊：避免“成功提交”，改为“系统返回 200 且页面显示‘提交成功’”。
- 触发条件遗漏：区分“主动触发”（用户点击）与“被动触发”（定时任务/第三方回调）。
- 步骤跳跃：步骤之间不能有隐藏分支，每个步骤应明确定义输入与输出。
- 预期结果不可验：必须包含明确的系统状态、数据变更或响应码。