鸿影：一份好的 交互设计 文档，不仅仅是设计师本人专业思考、表达和品牌性的体现，还能帮助设计师更顺畅地和上下游利益相关方沟通。今天这篇文章，主要想总结下自己之前在设计稿中做得不到位、常常偷懒忽略的细节，导致后续开发跟进过程中出现各种沟通确认时踩坑的情况。
维护修改历史
在和业务方确认、内部评审、可用性测试、开发评审等过程中，或多或少都会遇到设计方案需要调整的情况，而影响到最终方案确定的原因也是平衡多方诉求而得。而勤维护记录每一次设计稿版本迭代的更新历史（包括修改内容和作出修改的原因），虽然看似比较麻烦，但可以在后续开发过程中遇到种种对于 设计细节 的疑问挑战时，帮我们迅速回想起当初作出设计决策的原因，给出充分合理的答案。
对于节奏很快，设计-开发迭代周期短的项目，这一点的作用可能并不突出。但如果是那种设计稿交付好几个月才开始排期开发的项目（我最近踩到坑的就是这类），当开发来找我们提出各种疑问挑战的时候，可能我们早已淡忘了当初作出决定时的种种细节，而如果设计文档里又没有一份详细的修改历史记录的话，就会需要耗费时间去重新沟通确认一遍以前讨论决策过一次的方案，增加了更多时间成本。
记录客观限制
交互设计 需要在用户、业务与技术之间做好平衡，客观的业务与技术限制也一直存在，这会使得我们的设计方案有时候看上去并不是那么完美合理。当我们因为客观存在的限制而不得不在设计方案上作出折中时，不妨也将这些客观限制条件一一整理记录下来，既帮别人更好地理解我们这么设计的原因，也能帮自己在后续的同项目迭代中及时回避对同类限制条件考虑不周的情况。
给设计稿编号
当需要产出涉及多个界面的设计方案时，给每张图进行编号标记（或类似交互文档的页码），并保证交互稿与视觉稿的编号一致。这样在后续和视觉、前端、开发、测试沟通的过程中，可以通过编号迅速定位到疑问所在区域，而不需要花更多精力进行描述和查找；前端在参阅设计稿的时候，也能更方便地把交互和视觉方案对上号。
及时同步状态
当设计方案发生变动后，即使是细节微调、或口头确认得比较清楚，最好也还是及时同步更新最新的设计稿链接给项目组成员。否则的话，开发按照旧版本设计方案执行，测试按照旧版本设计方案提BUG一类的乌龙状况也更容易发生；与其等问题发生了再来想办法补救，不如在更早的阶段将其掐灭。
