第1章 PRD与原型的关系认知

PRD(产品需求文档)与原型是产品从抽象到具象的两个关键载体。PRD用结构化文本描述需求逻辑与边界,原型用可视界面展示交互与体验。二者不是替代关系,而是映射关系——好的映射能大幅减少理解偏差,提升团队协作效率。

1.1 需求文档的核心要素

一份完整的PRD至少包含以下要素,缺一不可:

  • 业务背景与目标:说明解决什么问题、达成什么指标。
  • 用户场景与角色:谁在什么环境下使用,典型操作流程。
  • 功能需求清单:模块、功能点、优先级。
  • 非功能需求:性能、安全、兼容性、可扩展性。
  • 验收标准:每项需求可量化的通过条件。
  • 数据与埋点要求:关键行为追踪方式。

1.2 原型的表达能力

原型按照细节程度可分为不同层次,表达能力逐层递进:

  • 线框图(低保真):快速布局,关注信息架构,不纠结视觉细节。
  • 高保真静态原型:接近真实UI,展示品牌色、间距、图标。
  • 可交互原型:包含页面跳转、状态变化、错误反馈,模拟真实操作。

原型本身无法承载全部逻辑(如异常流程、边界条件),这正是需要PRD补充的地方。

1.3 映射的价值

PRD到原型的映射并非简单的“翻译”,而是一种结构化对齐行为:

维度 PRD 原型 映射后价值
表达方式 文字+表格+流程图 视觉+交互 降低阅读门槛
受众 开发、测试、运营 设计师、客户、评审 统一各方认知
修改成本 文档修改周期长 快速迭代 加速需求验证
遗漏风险 易遗漏边缘场景 直观发现交互漏洞 补全需求闭环
建议:每次迭代要求PRD与原型同步更新,并在评审时以“PRD逐条对照原型”的方式过需求,拒绝仅凭原型评审任何逻辑分支。
PRD → 原型映射关系图 业务痛点 用户场景 PRD 文档 (需求结构化) 原型设计 (界面+交互) 映射对齐 开发实现 & 验收验证 互补关系 PRD不覆盖界面细节 原型不覆盖逻辑分支 驱动 逐条映射 反馈迭代