用户场景撰写方法：场景五要素拆解
用户场景是需求从模糊到具象的起点。一个完整的用户场景必须包含场景触发条件、用户角色、操作流程、预期结果、异常分支五要素。缺少任何一项，场景都会产生歧义，导致原型走偏。
五要素定义与对比
| 要素 | 定义 | 示例（用户登录场景） |
|---|---|---|
| 场景触发条件 | 促使角色进入场景的外部或内部事件、时间、状态 | 用户打开APP后停留在登录页超过3秒未操作 |
| 用户角色 | 发起或参与场景的特定用户身份及权限 | 已注册但未登录的普通用户 |
| 操作流程 | 角色为达成目标依次执行的步骤（正常主路径） | 输入手机号 → 获取验证码 → 输入验证码 → 点击登录 |
| 预期结果 | 流程成功完成后系统呈现的最终状态或反馈 | 页面跳转至首页，顶部显示用户昵称，同时下发登录态Token |
| 异常分支 | 流程中可能出现的错误、边界、中断及系统响应 | 验证码错误 → 提示“验证码有误，请重新输入”；网络超时 → 弹窗“请求失败，请检查网络” |
实操建议：撰写场景时先写主路径（即无异常的正常流程），再逐一补充异常分支。异常分支通常是PRD中遗漏最多的部分，也是原型评审时争议的高发区。
场景五要素撰写流程
下面是一张用户场景撰写流程图，展示了从收集素材到输出完整场景的标准化步骤。每个步骤都对应DRY原则中的关键设计点。
撰写步骤详解
- 识别触发条件：从用户研究、数据分析或业务规则中提取事件。例如“用户首次打开应用”、“余额低于阈值”、“订单支付成功”。
- 明确角色：一个场景仅对应一个主要角色；若涉及多个角色，拆分为多个子场景。角色描述需包含身份、状态、权限。
- 绘制主路径流程：以步骤列表呈现，每步保持原子性（一个动作）。避免“然后重复”等模糊表述。
- 列出预期结果：包括界面变化、数据更新、通知触发、下一步状态变更等。结果必须可观测、可验证。
- 枚举异常分支：从主路径每个步骤的反向推导：如果这一步失败会怎样？至少要覆盖“输入校验失败”“接口超时”“权限不足”“状态冲突”四类。
📘 案例：某电商退款申请场景（简化）
· 触发条件：用户点击订单详情页的“申请退款”按钮
· 角色：已登录、订单状态为“已付款”或“已发货”的普通买家
· 主流程：选择退款原因 → 提交申请 → 系统创建退款单 → 页面跳转至退款详情页
· 预期结果：退款单状态=待审核，可撤销，超时72小时自动转入客服处理
· 异常分支：退款原因未填 → 弹窗提示；订单已发货且物流签收 → 提示“请联系客服人工处理”
· 触发条件：用户点击订单详情页的“申请退款”按钮
· 角色：已登录、订单状态为“已付款”或“已发货”的普通买家
· 主流程：选择退款原因 → 提交申请 → 系统创建退款单 → 页面跳转至退款详情页
· 预期结果：退款单状态=待审核，可撤销，超时72小时自动转入客服处理
· 异常分支：退款原因未填 → 弹窗提示；订单已发货且物流签收 → 提示“请联系客服人工处理”
常见错误与避坑指南
⚠️ 错误一：将多个用户角色的操作混在同一个场景中。
⚠️ 错误二：预期结果仅写“成功”，未描述具体的界面/数据变化。
⚠️ 错误三：忽略异常分支中的“系统响应”，只写错误原因不写系统反馈文案。
⚠️ 错误二：预期结果仅写“成功”，未描述具体的界面/数据变化。
⚠️ 错误三：忽略异常分支中的“系统响应”，只写错误原因不写系统反馈文案。
正确的场景文档是PRD的“微观单元”，后续需求拆解、原型设计、验收标准都直接复用此处定义的要素。每次写完场景后，可以请另一位产品经理进行“要素检查”，确保五要素无一遗漏。