江湖笑，恩怨了；人过招，笑藏刀…
江湖笑，爱逍遥；琴或箫，酒来倒…
相信大家此刻一定轻声哼起了周华健的《江湖笑》，哈哈！日出东方，唯我不败！
有人的地方就有江湖，有江湖的地方的就会有恩怨。在产品的江湖中，“产品”、“设计”、“开发”这三大门派常常是刀光剑影，血流成河。作为一名设计师，如何才能练就“御剑之术”，行走江湖来去自如？
一、江湖背景
一般性的互联网公司，一条产品线大概能有20人左右的团队。主要由“产品”、“设计”、“开发”三大块组成（运营和销售暂不谈），详细的工种配置可参考下图。
产品线工种配置
二、恩怨情仇
产品开发通常的工作流程为：产品经理和产品设计师确定“产品功能需求”并输出“产品需求文档”。交互设计师接过文档，根据其内容进行框架结构的设计，对于文档中不合理的内容或可进一步优化的点，会及时反馈给产品人员，经商讨确认后，交互需调整设计方案，并最终输出“交互设计文档”（Demo）。
产品开发工作流程
接下来，开“产品评审会”（或“交付会”），评审结束后，下游同事（视觉、前端、开发）开始接手工作。这时，问题来了：
- 由于业务上的要求，需要增加新的功能；
- 产品人员发现漏掉了一些东西；
- 前端人员说这个交互样式实现不了；
- 开发人员找到逻辑漏洞；
面对这些问题，产品人员需要调整需求文档，交互稿也会随之进行调整，调整后会及时的发布出来（发布到公司的交互原型库中）。这时，矛盾产生了：
1. 交互稿内容调整了，下游同事不知道
下游同事不知道交互稿调整内容，将会导致已做完的工作进行返工，增加工作量。产生这种情况，主要有以下几个方面的原因：
- “产品评审会”结束后，产品和交互马上开始新的产品任务，工作时间上排的很紧；
- 对开发的分工并不是很了解，无法判定某个内容的调整会涉及到哪些开发人员；
- 一天下来，五六个“间断性”的调整内容如果通过即时通讯工具或邮件告知下游的十几个同事，中间再产生往来交流，将花费近⅓的工作时间；
- 大大增加了沟通成本，降低了工作效率，长此以往对设计师来说也是一种伤害。
2. 需求文档与交互稿内容有偏差
在产品开发中，开发人员通过交互稿来确认产品功能的框架结构，而详细的功能规则通过查看需求文档来完成。在这一过程中，开发人员常常发现需求文档与交互稿存在不一致的地方，不知道以哪个为准。每次都要去问交互或产品，很麻烦，也很恼火，主要是因为产品与交互之间没有协调好。
- 产品人员调整了需求文档，忘记告知交互；
- 产品人员调整了需求文档，告知交互，交互忘记改了；
- 交互与产品商讨确认后，交互改了，产品忘记调整需求文档；
- ……
三、冤家宜解不宜结
在尝试了多种方法之后，终于摸索出了一条可行的解决方案：
解决方案
Step1：
产品人员对需求文档进行了变更，将变更内容告知交互设计。
Step2：
交互设计根据需求文档的变更，对交互稿作相应的调整。将每次的调整内容进行记录（包括时间、内容、变更人等）。一天下来，将记录的内容进行汇总，发布变更群邮件，且对交互稿进行更新。
记录汇总模板
Step3：
相关涉及人员查看后，一方面知晓最新变更内容，另一方面发现有错误或遗漏的地方也能够及时的反馈给产品人员和交互人员。
Step4：
当变更内容比较多时，需要在交互稿的顶部新增一个“交互变更记录”的页面，用于存放每日的交互变更记录，方便项目相关人员的查阅。例如：
交互更新记录
经实践证明，该方法的成效还是很显著的。避免了相关人员对于“变更或调整”内容不知道的情况，且很少会发生需求文档与交互稿不一致的现象。
网友评论