第3章 原型构建前的需求采集：用户场景、业务目标、核心功能
3.1 用户场景描述
用户场景是需求采集的最小单元，它回答“谁在什么情境下需要做什么”。在产品原型启动前，必须用结构化方式描述场景，避免开发团队基于假设进行设计。
- 角色：明确执行者（如普通用户、管理员、访客）
- 触发事件：导致用户进入场景的外部条件或操作
- 预期动作：用户在界面上的关键操作序列
- 前置条件：必须满足的状态或数据（如已登录、订单未支付）
- 后置条件：操作完成后系统需要保存或反馈的结果
🎯 场景示例：收银员在结账高峰时快速扫码后，系统自动合并会员折扣并显示应付金额，全程不超过2秒。
3.2 需求痛点分析
| 痛点类型 | 典型表现 | 对原型的影响 |
|---|---|---|
| 需求模糊 | “做个好看的登录页” – 无具体功能边界 | 原型反复重画，沟通成本激增 |
| 假设未验证 | PM认为用户需要A功能，实际用户首选B | 原型方向错误，交付后仍需返工 |
| 遗漏边缘场景 | 只覆盖happy path，未考虑网络中断/权限不足 | 原型缺少异常反馈流程，开发阶段才暴露 |
| 角色冲突 | 管理员与普通用户的权限在场景中混淆 | 原型给出互斥的交互逻辑，评审时推倒重来 |
⚠️ 避坑提示：不要在只有一页功能清单时就开始画Figma画板。至少完成80%的场景梳理后再进入低保真原型。
3.3 原型设计要点
- 按场景拆分画板：每个主要场景对应一个Frame或Page，用Figma的封面图标注场景名称与角色。
- 先流程后细节：使用Figma的“连接线”工具绘制场景内的业务操作步骤，确认流转无误后再填充界面组件。
- 模板化组件库：将场景中反复出现的元素（表格、表单、弹窗）提前创建为本地组件，后续所有场景复用。
- 标注关键数据：在原型中用浅色文本框写出该位置需要展示的数据字段（如“订单号”、“优惠金额”），开发可据此确认接口。
💡 Figma操作建议：使用“Auto Layout”快速搭建列表结构，配合“实例替换”功能可一键切换组件状态，适合多场景对比。
3.4 沟通协作方法
- 需求采集工作坊：邀请产品、开发、测试、业务方一起用便利贴列出用户场景，现场按优先级分组。
- 场景卡片验证：将每个场景写成卡片，推送给典型用户代表，收集“是否真实发生”、“是否需要系统支持”的反馈。
- 利益相关者地图：识别每个场景中能决策、能提供信息、能被影响到的人，确保后续原型评审时关键人物到场。
- 版本化场景列表：在Figma的评论区或Confluence中维护场景-功能映射表，每次原型更新前先更新该表。
3.5 需求采集流程（内联框架图）
3.6 检查清单
启动Figma原型前，逐项确认以下条目是否完成：
| # | 检查项 | 完成标准 |
|---|---|---|
| 1 | 场景覆盖度 | 所有已知用户角色、主流与异常场景均已在文档中列出 |
| 2 | 业务目标对齐 | 每个场景都对应至少一个可量化的业务指标（如转化率、操作时长） |
| 3 | 核心功能列表 | 功能清单中无模糊描述（如“管理订单”拆分为“筛选、批量操作、导出”） |
| 4 | 利益相关方确认 | 业务方、技术负责人已签字或在线评论“同意” |
| 5 | 优先级标注 | 场景与功能已打标P0/P1/P2，原型第一阶段只包含P0 |
| 6 | Figma项目结构 | 已创建场景文件夹，每个场景一个Page，封面图包含场景编号与角色 |
3.7 验收条件
本章交付物通过以下条件方可进入下一阶段：
- 场景列表完整性：不少于5个明确场景，每个场景包含角色、触发事件、预期动作、前后置条件。
- 业务目标可测量：每个场景的预期结果能用至少一个量化指标描述（例如：操作步骤≤3步，成功率达到99%）。
- 核心功能可追溯：从功能列表中任意一个功能按钮都能反向找到对应的用户场景和业务目标。
- 评审记录闭环：所有评审意见已处理为“接受/拒绝/暂缓”，暂缓项有明确时间计划。
- Figma文件准备就绪：包含场景封面页、组件库草稿、至少一个场景的低保真页面（仅骨架，无样式）。
✅ 验收自测问题：如果你现在要求开发根据上述输出画一个Figma原型，他们是否能辨认出“第一个场景中用户在什么情况下点击哪个按钮”而不需要额外解释？如果答案是“是”则通过。