1. PRD 与原型设计的关系全景
产品需求文档（PRD）与数据产品原型是需求工程的一体两面。PRD 承载需求的逻辑定义，原型承载需求的视觉与交互验证。二者的协同质量直接决定产品交付的准确性与效率。
1.1 PRD 定义
PRD（Product Requirements Document）是产品需求的系统性文字描述，包含用户故事、功能列表、数据规则、业务逻辑、验收标准等。在数据产品中，PRD 还需要明确数据源、指标口径、计算逻辑、可视化规则。
| 维度 | PRD 典型内容 |
|---|---|
| 用户场景 | 谁在什么情况下使用，解决什么问题 |
| 功能需求 | 模块、操作流、输入输出 |
| 数据需求 | 字段定义、指标公式、ETL 逻辑 |
| 验收标准 | 数据准确率、响应时间、异常处理 |
1.2 原型定义
原型（Prototype）是产品需求的视觉化表达，分为低保真线框图、高保真交互原型、数据模拟原型。数据产品中的原型需展示仪表盘布局、图表类型、筛选联动、数据下钻等。
| 原型类型 | 用途 | 适合阶段 |
|---|---|---|
| 低保真线框图 | 快速验证布局与信息架构 | 需求探索期 |
| 高保真交互原型 | 模拟真实操作，验证交互细节 | 设计评审期 |
| 数据模拟原型 | 用假数据展示图表与指标效果 | 数据逻辑确认期 |
1.3 PRD 与原型的协同价值
- 互补验证：文字描述难以表达的交互反馈、数据可视化效果，通过原型直观展示；原型无法承载的复杂业务规则、数据口径，由 PRD 明确。
- 减少返工：评审时同时对照 PRD 与原型，可提前发现逻辑矛盾或体验缺陷，降低开发阶段 60% 以上的需求变更。
- 对齐认知：业务方、设计、开发、测试基于同一套 PRD+原型 进行沟通，避免“我说 A 你理解 B”。
课程经验：在一个数据报表项目初期，仅用 PRD 描述“点击图表 drill-down 到明细”，开发实现后业务方才发现预期是弹窗而不是页面跳转。如果当时画出原型交互帧，能提前纠正。
1.4 常见误区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 先写 PRD 再画原型，完全割裂 | PRD 与原型不一致，开发理解混乱 | PRD 与原型并行迭代、相互参照 |
| 原型画得太细却无 PRD 支撑 | 需求逻辑模糊，开发自行脑补规则 | 交互细节在原型中呈现，逻辑规则写在 PRD 对应位置 |
| PRD 全是功能列表，没有场景 | 产品缺乏价值锚点，方向易偏 | 每个功能关联用户场景与业务目标 |
| 原型只做静态图，无数据模拟 | 图表展示效果与实际数据偏差大 | 关键页面使用真实数据模拟 |
1.5 课程目标
本课程使用一个真实的电商用户增长看板案例，贯穿以下环节：
- 用户访谈 → 从业务方原始需求中提取痛点与场景
- 需求拆解 → 将模糊需求拆解为可验证的用户故事与数据指标
- 方案表达 → PRD 文档结构化撰写 + 高保真数据原型设计
- 指标验证 → 用模拟数据验证指标定义与计算逻辑
- 验收标准 → 明确数据准确率、响应时间、异常场景
- 交付物模板 → 提供 PRD 模板 + 原型模板 + 评审检查清单
本章核心：PRD 与原型不是先后关系，而是互为补充的平行文档系统。理解这一关系是后续所有章节的基础。