降低项目沟通成本和风险:写好交互设计说明文档(3)
4. 表单的校验
这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。
5. 浏览器的兼容性要求
你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.：D 。 这个决定谁来做？是前端工程师还是产品经理？还是你——交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。
四、 什么时间交付呢？
Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：
你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。
先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。
五、如何写DRD？
1. 选择最有效率的工具。
我的经验是这个工具最好能够提供清晰的目录导航结构，而且易标注。word确实是个写文档的好工具，不管你信不信，反正我是信了。
2. 建立固定的目录结构
下图仅供参考。
具体里面的细节，就不一一罗嗦了。
六、重要的原则
准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应项目的文档，了解过去的设计逻辑）。
不是为了写文档而写文档（而是为了解决问题）
适合于项目、合作方（大项目有大文档，小需求有灵巧的解决方案）
工具不是问题（易传播，易标注，成目录即可）
模版不是问题，大家看明白就可
完美的文档无法取代面对面的沟通（评审会和讨论不会因为文档而减少）
需要在实践中不断改进
七、谁来写？
我建议由交互设计师发起，但是由前端工程师进行修订，再传递给开发工程师。
有很多需求，交互设计师只要求实现即可，但是他可能并不在乎是前端实现还是后端实现。前端工程师对DRD进行把关和修订，能够将设计语言转化为工程师能够看懂的语言，且能够划定与开发的实现边界。
八、与其他产出物的关系
项目中交付物对应不同的使用角色，如下图所示：
但是有个问题是，虽然DRD的目标受众有开发和测试，但是让开发工程师同时参考那么多文档是不现实的，所以仍然是开发工程师的接口人，也就是事实上的RA需求分析作为需求整合传递的角色，将商业需求和设计需求，传达给具体的执行开发工程师与测试工程师：
【总结】
对于坚持撰写DRD的我来说，DRD的好处自己当然是明白的。但是并非所有人都喜欢写文档，都喜欢看文档。
解决问题有多种方案，DRD只是其中一个。不过，当你因为设计需求传递过程中发生了问题，或者你的需求被理解偏差，或者你的需求被遗漏，或者你接手的项目改版，因为要梳理过去的设计逻辑焦头烂额时，你可以试试用DRD。如果使用过程中还是存在问题，那么就想想是否还存在别的解决方案吧～