1. 联调目标与价值
1.1 联调定义
PRD 与 Figma 联调是指产品经理将 PRD 中的需求描述与设计师在 Figma 中的交互方案、视觉方案进行系统性对齐的协作过程。它的核心目标是确保每一个功能点、状态分支、异常流程在文档和设计稿中保持一致，从而为研发提供无歧义的开发基线。
- 对齐对象：PRD 文字需求 ↔ Figma 界面/交互稿
- 对齐粒度：字段、状态、跳转、异常、空数据、边界值
- 对齐产出：一份联调检查表 + 标注后的 Figma 文件 + 最终 PRD 修订版
✦ 关键认知：联调不是“审一遍”，而是双向映射——PRD 中的每一条需求都能在 Figma 中找到视觉表达，Figma 中的每一个界面组件都能在 PRD 中找到功能说明。
1.2 核心价值
联调直接打通了“需求定义”与“视觉呈现”之间的断层，带来四重可量化收益：
| 价值维度 | 说明 | 影响指标 |
|---|---|---|
| 消除信息差 | PRD 文字与 Figma 视觉 100% 对齐，研发无需猜测 | 需求理解偏差降低 80% |
| 降低返工率 | 在开发前暴露需求与设计的矛盾点，而非测试阶段 | 返工工时减少 50% |
| 加速研发效率 | 联调后的 PRD+Figma 作为单一可信源，开发直接使用 | 研发启动时间缩短 60% |
| 提升还原度 | 从需求源头控制交付质量，减少“设计与实现两张皮” | 产品还原度达到 95%+ |
💡 经验数据：在一个中等规模 B 端项目中，系统执行联调后，需求澄清会议从 6 次/迭代降为 2 次/迭代，开发阶段新增需求变更减少约 40%。
1.3 常见痛点
没有联调机制的项目通常会在以下四个环节反复“踩坑”：
| 痛点类型 | 具体表现 | 典型发生阶段 |
|---|---|---|
| 需求遗漏 | PRD 中写了某个分支逻辑，但 Figma 中没有对应的界面状态 | 设计评审 |
| 设计冗余 | Figma 中出现了 PRD 未定义的 UI 组件或交互流程 | 开发前对齐 |
| 描述冲突 | 同一功能，PRD 与 Figma 在文案、跳转、操作反馈上不一致 | 联调检查 |
| 状态缺失 | 空数据、加载中、网络异常、权限不足等状态在两者中均未覆盖 | 验收测试 |
⚠️ 警示：上述痛点如果不在联调阶段解决，就会以“研发疑问→产品答疑→设计改稿→开发重做”的形式消耗团队 3~5 倍成本。联调不是“可选项”，而是“必须项”。
1.4 课程目标
完成本章及后续课程后，你应具备以下能力：
- 掌握联调标准流程——从需求冻结到设计定稿的完整联调路径
- 学会 PRD 与 Figma 的对齐方法——逐字段、逐状态、逐流程的检查技术
- 能够制定验收标准——从“感觉 ok”到“指标可衡量”的验收清单
- 熟练使用交付物模板——联调检查表、问题记录单、终版对齐报告
1.5 联调价值链路
下图展示了从业务需求到产品交付的完整链路，以及联调对齐如何阻断三大常见痛点：
1.6 验收要点检查表
每完成一次联调，请逐项核对以下清单，确保交付物达到准入标准：
| 检查项 | 验收标准 | 状态 |
|---|---|---|
| PRD 需求完整度 | 所有功能点、分支条件、异常流程均有文字描述 | □ 通过 □ 需补充 |
| Figma 界面覆盖度 | 每个需求在 Figma 中有对应的界面/组件/状态稿 | □ 通过 □ 需补充 |
| 字段级一致性 | PRD 中的字段名、类型、长度与 Figma 标注完全一致 | □ 通过 □ 需补充 |
| 流程闭环 | 主流程 + 分支流程 + 异常流程在两者中均完整映射 | □ 通过 □ 需补充 |
| 状态全覆盖 | 空数据、加载、错误、权限不足等状态已明确设计 | □ 通过 □ 需补充 |
| 问题记录单 | 联调中发现的不一致项已记录并分配修改责任人 | □ 通过 □ 需补充 |
✦ 本章核心交付物：联调检查表（纸质或在线文档）+ 问题记录单 + 双方签字确认的联调报告。一份规范的联调产出，能让研发团队直接进入编码而无需反复确认，这是产品经理专业度的直接体现。