# 一、为什么要“留痕”
> **核心目标：** 在跨职能协作中留下一份**可追溯、可复用、可量化**的知识资产。
>
> - **减少反复对齐**：把已经确认的点固化，避免“上次是谁说的？”
>
> - **支撑后续决策**：方便开发、测试、运营随时查阅历史来源。
>
> - **沉淀最佳实践**：为后续版本或新人提供材料与经验。
>
---
# 二、典型交互节点与产物
|阶段|主要交互动作|建议产物|保存方式|关键注意点|
|---|---|---|---|---|
|需求澄清(Kick-off)|产品经理讲解业务目标、约束、受众|**需求澄清纪要**（关键业务目标 & 成功指标）|🔹Confluence / 飞书文档🔹会议录屏|- 先写“Meeting Note 模板”- 每项结论标 ❗或⭐|
|信息架构 & 流程梳理|UED 输出 IA / 流程草稿产品补充边界条件|**流程图 + 场景说明**|🔹Figma flow + 备注🔹嵌入 PRD|- 在 Figma 每个节点留 Comment- 用编号与 PRD 对齐|
|低保真原型评审|双方同步功能流程、交互细节|**低保真原型**评审清单|🔹Figma_版本迭代_🔹Jira/Teambition 评审任务|- 原型版本号 = 日期 + 负责⼈- 评审意见用 checklist 追踪|
|视觉规范 & 高保真|UED 提供视觉稿产品确认业务一致性|**视觉稿 / Design Token**|🔹Figma Library🔹Zeplin / 蓝湖|- 建立 Design Token 表- 产出色板、组件命名规范|
|开发走查|产品 & UED 联合 check 还原度|**走查缺陷单**|🔹Tapd / Jira 缺陷单|- 使用 Bug 模板：定位、截图、期望|
|上线验收 & 复盘|回顾指标、体验问题|**复盘文档**（体验+业务双维度）|🔹Confluence / Notion|- 量化：PV、点击、完成率- 体验：NPS、Heuristic 评分|
---
# 三、落地技巧
1. **单一事实源（SSOT）**
- PRD、设计稿、评审备注都链接到同一条「索引页」。
- 用互相引用（Embed、Backlink）减少信息孤岛。
2. **“决策日志”**
- 任何争议一旦拍板，快速记录：背景->选项->权衡->最终方案。
- 建议放在 PRD _Decision_ 区块或单独的 Confluence page，方便后续回溯。
3. **结构化评审清单**
```text
√ 页面信息层级符合业务优先级
√ 交互反馈（加载、成功、失败）齐全
√ 主流程无分支死角
√ 无可预见的可访问性问题
```
评审时按清单过一遍，当场标记所有修改项。
4. **版本控制与回滚**
- Figma：启用 _Branching_ 或定期 _Duplicate_ 里程碑版本。
- 文档：使用飞书 _多维表格_ 或 Confluence _版本_，自动生成 Diff。
5. **可搜索的命名规则**
```Java
[项目]_[模块]_[类型]_[版本]
ex. TripPlanner_PackageFlow_PRD_v2.1
```
6. **自动化同步**
- **Webhook / 飞书机器人**：PRD 更新→群里推送变更摘要。
- **Jira-Figma 插件**：设计评论→自动生成 Jira 子任务。
7. **可视化看板**
- 用 Jira/飞书 OKR 看板把需求->设计->开发->上线全流程串起；
- 卡片上直接挂 Design Link & Decision Link。
---
# 四、协作文化建议
|做|不做|
|---|---|
|讨论结束 15 min 内同步纪要|“等会儿再写，回头补”|
|用客观指标驱动决策|仅凭“感觉好不好”|
|在设计稿中就地留下评论|私聊导致信息断层|
|提前暴露风险/依赖|到了提测才说要接口|
|每周一次短会梳理 open issues|一口气到版本冲刺尾声才对齐|
---
## 小结（一句话）
> **让信息“活”在同一个透明的、可检索的系统里，**产品经理关注“做什么 + 为什么”，UED 关注“怎么呈现 + 用户感受”，通过结构化产物、清晰命名、可追踪流程与自动化工具，形成高效、可复用的交互协作闭环。