2. 数据原型的概念与类型
数据原型是产品需求验证过程中最直观的沟通工具——它将抽象的文字需求转化为可视、可操作、可测试的“伪产品”。在PRD验证场景中，原型承担三个核心角色：需求澄清器（消除歧义）、认知对齐器（统一团队/客户理解）、风险发现器（提前暴露设计缺陷）。本章围绕四种主要原型类型，逐一拆解其定义、适用场景、业务问题、访谈要点、需求拆解方式、验证指标及验收标准。
原型 ≠ 最终产品 —— 原型是验证假设的工具，不是交付物。每个原型都应该指向一个明确的验证目标，否则容易陷入“美化草图”的误区。
2.1 低保真原型
定义：最简单的页面框架，用线框、灰色方块和基本文字表示结构，不带视觉细节和交互。通常用纸笔、Balsamiq、Figma 线框模式绘制。
- 用户场景：早期需求探索阶段，团队尚不确定整体信息架构。
- 业务问题：需求方说“我要一个列表页”，但没说清楚列表排序、筛选方式。
- 用户访谈：把线框图摆在用户面前，问“这个页面上信息摆放的顺序对不对？你会先用哪个按钮？”
- 需求拆解：通过低保真快速区分“核心功能模块”与“次要修饰”，防止在视觉细节上过早投入。
- 方案表达：不加颜色、不加真实文字，只表达“有什么”、“大概放在哪”。
- 指标验证：结构正确率（用户能否按预期找到目标功能）、布局理解偏差数。
- 验收标准：页面区块划分与用户任务流程无逻辑矛盾。
2.2 高保真原型
定义：接近最终设计的视觉样式，包含真实配色、图标、字体、间距、图片占位。通常用 Sketch、Figma、Adobe XD 完成。
- 用户场景：信息架构基本确定，需要验证视觉层级、品牌一致性、响应式断点。
- 业务问题：客户说“这个按钮太不明显了”，但界面色值、主次关系尚未经过真实用户感知测试。
- 用户访谈：让用户执行典型任务（如“找到并点击‘提交订单’按钮”），观察视觉干扰和眼动热点。
- 需求拆解：把 UI 规范（主色、辅助色、字号层级、间距网格）从低保真中分离出来作为独立需求条目。
- 方案表达：使用高仿真的设计组件系统，每个页面都附带设计标注和组件库引用。
- 指标验证：视觉一致性得分、可发现性（按钮/链接找到时间）、品牌调性匹配度。
- 验收标准：所有页面遵循设计系统中定义的视觉规范，无未定义的颜色或字体。
2.3 交互原型
定义：模拟真实操作流程的点击/滑动/转场演示，包含页面跳转、弹出层、表单反馈、加载状态。常用 Axure、Framer、ProtoPie 制作。
- 用户场景：需要验证多步骤流程（注册、支付、审批）的操作路径是否符合用户心理模型。
- 业务问题：开发费用估算时，一个交互路径上的意外分支可能导致 30% 成本溢出。
- 用户访谈：让用户无指导地完成一个端到端任务，记录每一步的犹豫、误操作、跳回行为。
- 需求拆解：每个页面跳转对应一条状态机转化的需求，每条分支条件（输入/权限/异常）都需要明确。
- 方案表达：用流程图辅助交互原型，标注每个触发器、条件和反馈。
- 指标验证：任务成功率、错误率、操作步数、放弃率。
- 验收标准：所有逻辑分支（正常+异常）至少有一个原型片段覆盖，且测试通过率达 95% 以上。
2.4 数据模拟原型
定义：模拟真实数据结构和业务逻辑的“假后端”原型，通常带假 API、模拟 JSON 响应、本地数据库表。常用于验证数据字段完整性、计算逻辑、权限规则。
- 用户场景：报表系统、数据看板、规则引擎等对数据准确性敏感的模块。
- 业务问题：业务方说“字段 A 应该等于 字段 B 乘以 字段 C”，但实际字段 C 可能在某种条件下为 null。
- 用户访谈：给用户指定一组测试数据，询问“这个结果对吗？如果数据变化，你期望看到什么？”
- 需求拆解：把每个数据字段的定义（数据类型、约束、计算表达式、权限）写成结构化表格。
- 方案表达：输出包含 Mock API 文档、字段映射表、错误码清单的交付包。
- 指标验证：字段覆盖率（原型涉及字段数 / 最终需求字段数）、计算正确率、边界值处理正确率。
- 验收标准：所有字段定义通过数据字典审核，Mock 数据包含至少一个正常场景和一个异常场景。
最佳实践：对于复杂业务（如定价引擎、风控规则），建议在需求拆解阶段就做数据模拟原型，因为文字需求很难描述边界条件，只有让用户看到“数字变了”才能触发真实反馈。
| 维度 | 低保真原型 | 高保真原型 | 交互原型 | 数据模拟原型 |
|---|---|---|---|---|
| 主要验证目标 | 信息架构 / 内容排布 | 视觉规范 / 品牌一致性 | 操作流程 / 任务流畅度 | 数据字段 / 计算逻辑 |
| 制作工具 | 纸笔 / Balsamiq / 白板 | Figma / Sketch / XD | Axure / ProtoPie / Framer | Mockoon / Postman / 代码模拟 |
| 投入时间 | 0.5~2 天 | 2~5 天 | 3~7 天 | 2~4 天（取决于数据复杂度） |
| 典型用户访谈问题 | “这个页面分几块？您想先搜还是先浏览？” | “这个颜色能代表品牌吗？文字大小是否合适？” | “请完成一次下单，大声说出您的思考。” | “这个数字 98 是如何算出来的？您认为对了吗？” |
| 验收交付物 | 线框标注图 + 页面结构说明 | 设计系统文档 + 设计稿 | 交互流程图 + 可点击原型文件 | Mock API 文档 + 样本数据 JSON |
2.5 原型演进与验证流程
下图展示了一个典型的产品需求验证路径——从低保真到高保真，再到交互与数据模拟，每一阶段聚焦不同的风险类型。
常见陷阱：很多团队从低保真直接跳到高保真，跳过了交互原型和数据模拟原型，导致开发后期才发现流程冲突或数据规则不匹配。建议每个项目至少保留一个“数据模拟原型”验证节点，特别是涉及复杂计算公式、权限规则、跨系统接口的需求。
2.6 交付物模板清单
每个原型阶段都应有对应的归档模板，作为 PRD 的辅助证据。以下列出本章各原型的标准交付物格式：
- 低保真原型交付包：页面结构图（PNG/PDF）+ 线框标注 PDF + 口头访谈记录摘要。
- 高保真原型交付包：Figma/Sketch 源文件 + 设计规范文档（字体、颜色、间距）+ 导出的静态稿。
- 交互原型交付包：可点击原型 URL/本地文件 + 流程图（含所有分支）+ 用户测试录屏/操作日志。
- 数据模拟原型交付包：Mock API 请求/响应示例（JSON）+ 字段映射表 + 边界值测试用例。
验收标准示例（数据模拟原型）
验收项：
1. 所有字段名与 PRD 数据字典一致
2. 至少包含 3 组测试数据覆盖正常/边界/异常
3. 每个计算字段可手工验证结果
4. Mock API 响应时间 < 200ms
5. 错误码定义与 PRD 异常场景对应在下一阶段（第3章）我们将深入讨论如何根据原型验证结果迭代 PRD，重点讲解指标回溯和需求变更流程。