第四章　原型设计验收标准

1. 适用场景

本章节适用于以下三类典型场景：

• 需求评审会：产品经理、数据科学家、开发工程师共同对高保真原型做正式验收，判定是否进入开发阶段。
• 迭代节点复盘：已上线数据产品的下一轮迭代前，用验收标准复盘当前原型是否遗漏关键假设或字段。
• 跨部门协作移交：数据团队将原型移交给业务方做 UAT 之前，用验收清单逐条打钩确认。

2. 前置条件

#	条件	验收说明
1	原型已完成交互定稿	所有页面跳转、弹窗、数据状态至少覆盖 happy path 和一条负面路径。
2	关键假设清单已确认	上一阶段输出的 假设表（含业务假设、技术假设、数据假设）经过干系人签字。
3	数据字段字典定稿	每个页面上展示的指标、维度、参数都有对应数据源和口径说明。
4	评审成员已分配角色	至少包含：产品负责人、数据架构师、前端/后端开发代表、QA 测试。

3. 操作步骤

验收流程按 四步检查法 执行，每一步都有对应的检查清单：

步骤一：关键假设覆盖检查（1 h）

• 取出《假设跟踪表》，逐条对比原型中的交互、文案、数据默认值是否与假设对应。
• 标记三类结果：已覆盖、部分覆盖、未覆盖。
• 部分覆盖和未覆盖的假设必须记录在案，并给出修正建议。

步骤二：交互逻辑清晰度评审（1.5 h）

• 按用户核心路径走查：每个点击、滑动、输入是否有明确反馈（加载态、空态、错误态、成功态）。
• 使用 10 条交互启发式规则 快速评估（系统可见性、一致性、容错度等）。
• 对每一个交互异常点截图并标注，归入「交互问题单」。

步骤三：数据字段完整性审计（1 h）

• 拿数据字典逐字段比对原型上的展示：字段名、单位、精度、阈值、空值处理。
• 检查计算指标的口径是否在原型上以 tooltip 或脚注形式说明。
• 输出《字段差异矩阵》，标明漏字段、多字段、口径错误。

步骤四：评审检查表集体投票（0.5 h）

• 全体评审成员对《原型验收检查表》逐项投票，2/3 以上通过 方可进入开发。
• 未通过项必须明确责任人、修正措施、预计完成时间，并在 2 个工作日内复议。

4. 输入输出物

类型	名称	格式/载体	责任人
输入	高保真原型（含交互）	Figma / Axure 链接	产品经理
输入	假设跟踪表	Google Sheets / Excel	数据科学家
输入	数据字段字典	Markdown / Confluence	数据架构师
输出	验收检查表（含投票结果）	PDF / 协作白板	产品经理
输出	交互问题单	Jira / 飞书任务	UX 设计师
输出	字段差异矩阵	Excel / 在线表格	数据架构师

5. 责任边界

角色	验收职责	否决权范围
产品经理	组织评审、维护检查表、跟进复议	功能完整性、需求对齐度
数据架构师	审计字段口径、数据血缘、空值策略	数据准确性、字段缺失
UX 设计师	走查交互一致性、易用性	核心路径交互阻断
开发代表	评估实现可行性、技术假设	不可实现的技术方案
QA 测试	从测试视角补充边界 case	无否决权，但问题单需记录

6. 记录材料

以下材料必须归档至项目 Wiki / 知识库，至少保留至该版本下市：

1. 验收检查表：含每项得分、投票明细、最终结论。
2. 交互问题单链接：标明严重等级（P0/P1/P2）。
3. 字段差异矩阵：标注修改前后对比、合入版本号。
4. 评审会议纪要：含参会人员、投票结果、待办项与负责人。

7. 异常处理

异常场景	处理措施	时限
关键假设覆盖率 < 60%	评审中止，补充假设验证实验或调研后再重新发起验收	3 个工作日内重新评审
交互阻断性问题 ≥ 3 个 P0	拒绝通过，设计师修正确认后单独走快速复议	2 个工作日内修复+复议
字段差异 > 20%	打回至数据架构师更新字典，产品经理同步修改原型	5 个工作日内二次验收
投票未达到 2/3	整理反对意见，分解为具体修正项，安排 1 轮复议	复议会议不超过 1 小时

8. 验收标准

完成本章所有步骤后，需满足以下标准方可视为验收通过：

1. 关键假设覆盖率 ≥ 90%：所有假设在原型上都有对应的交互或数据表现，剩余 10% 有明确的迭代计划。
2. 交互逻辑清晰度评分 ≥ 4.0/5.0：基于 10 条启发式规则，每条评分 1–5，平均分不低于 4.0。
3. 数据字段完整度 100%：数据字典中的字段在原型上全部出现，口径、单位、精度完全匹配。
4. 评审检查表通过率 ≥ 2/3：全体评审成员投票通过项占比不低于 66.7%。
5. 所有 P0/P1 问题已关闭或有明确解决时间表：不允许存在未处理的阻断性问题。