2. 数据原型设计流程概览：需求收集、分析、原型设计、评审、迭代

数据原型设计的本质是将模糊的业务问题转化为可交互、可验证的界面方案，最终用PRD需求文档锁定交付范围。整个流程围绕五个核心阶段展开，每个阶段都对应明确的用户场景、业务目标与交付物。以下流程图概括了阶段间的依赖与反馈闭环。

2.1 需求收集：从用户场景与业务问题出发

需求收集阶段的目标是捕获真实用户的场景痛点，避免产品经理坐在办公室“想象”功能。核心手段包括用户访谈、现场观察与业务数据分析。

• 用户访谈：采用半结构化访谈提纲，围绕“当前如何完成工作”“最大障碍是什么”“希望改善哪个环节”展开。
• 业务问题定义：将访谈内容收敛为 1~3 个关键业务问题，例如“库存信息更新滞后导致超卖”“客服平均处理时长>15分钟”。
• 场景卡片：为每个业务问题编写用户场景，格式为“作为<角色>，我想<目标>，以便<价值>”。

2.2 需求分析：结构化拆解与优先级排序

需求分析阶段将零散的访谈笔记、场景卡片转化为可追溯、可度量的需求条目。常用的工具有用户故事地图和影响地图，帮助产品经理看清需求之间的依赖关系。

1. 需求拆解：使用“Epic → Feature → User Story → 验收标准”层级结构，强制团队将模糊需求拆到可执行粒度。
2. 优先级排序：基于业务价值、实现成本、风险三个维度打分，输出 MoSCoW 清单（Must/Should/Could/Won‘t）。
3. 指标验证：为每个关键需求绑定北极星指标，例如“下单转化率”“工单关闭率”，用于后续原型验证。

以下是一个需求拆解的结构化示例，通常作为 PRD 需求文档的附录出现：

{
  "epic": "库存预警",
  "feature": "实时库存看板",
  "user_stories": [
    "作为仓库管理员，我希望在库存低于阈值时看到弹窗提示，以便及时补货",
    "作为运营总监，我希望按SKU查看历史库存走势，以制定采购计划"
  ],
  "验收标准": [
    "阈值可配置（最小库存≥10）",
    "弹窗出现后5秒内无操作则自动消失",
    "走势图支持按日/周/月切换"
  ]
}

2.3 原型设计与评审：方案表达与验收标准对齐

原型设计是将需求分析结果可视化的核心步骤。设计师基于用户故事绘制低保真/高保真原型，评审环节则由产品经理、开发、测试共同走查，确认原型与需求文档完全一致。

评审阶段的重点包括：

• 方案表达：用 PRD 文档中的“原型说明”字段标注交互细节，例如“点击+号展开二级菜单”“超过10字用省略号截断”。
• 验收标准验证：逐个核对原型是否满足 User Story 的验收标准，不合格项标记为“驳回”并进入迭代回路。
• 交付物模板：完整的评审应输出《原型评审意见表》，包含模块名称、问题描述、修改优先级、责任人。

2.4 迭代：持续优化与交付物模板固化

迭代阶段并非“重做”，而是基于评审反馈和用户测试数据做增量调整。每次迭代结束都应刷新 PRD 文档中原型部分的版本号，确保文档始终与实际原型一致。

建议团队在项目启动时就固化交付物模板，例如：

• PRD 需求文档模板：固定包含“业务背景→用户场景→需求拆解→原型设计→验收标准”五个章节。
• 原型评审意见表模板：线上管理（如 Excel 或协作文档），包含模块、问题描述、优先级、状态、负责人横向字段。
• 变更记录表：每次迭代更新时记录变更原因、变更范围、影响评估。

通过模板固化，产品经理可以大幅降低沟通成本，让开发与测试人员无需重复确认“需求到底是什么”。