我们设计方案英语[c1跨学科设计活动方案英语]

　　好的交互设计文档，不仅是设计师本人的专业思考、表达和品牌性的体现，也能帮助设计师更顺畅地和别的部门人士相沟通，下面，莱茵教育为你讲解一下交互设计文档中有哪些促进沟通顺畅的细节。

　　维护修改历史

　　在和业务方确认、内部评审、可用性测试、开发评审等过程中，或多或少都会遇到设计方案需要调整的情况，而影响到最终方案确定的原因也是平衡多方诉求而得。

　　而勤维护记录每一次设计稿版本迭代的更新历史(包括修改内容和作出修改的原因)，虽然看似比较麻烦，但可以在后续开发过程中遇到种种对于设计细节的疑问挑战时，帮我们迅速回想起当初作出设计决策的原因，给出充分合理的答案。

　　对于节奏很快，设计-开发迭代周期短的项目，这一点的作用可能并不突出。但如果是那种设计稿交付好几个月才开始排期开发的项目，当开发来找我们提出各种疑问挑战的时候，可能我们早已淡忘了当初作出决定时的种种细节，而如果设计文档里又没有一份详细的修改历史记录的话，就会需要耗费时间去重新沟通确认一遍以前讨论决策过一次的方案，增加了更多时间成本。

　　记录客观限制

　　交互设计需要在用户、业务与技术之间做好平衡，客观的业务与技术限制也一直存在，这会使得我们的设计方案有时候看上去并不是那么完美合理。

　　当我们因为客观存在的限制而不得不在设计方案上作出折中时，不妨也将这些客观限制条件一一整理记录下来，既帮别人更好地理解我们这么设计的原因，也能帮自己在后续的同项目迭代中及时回避对同类限制条件考虑不周的情况。

　　给设计稿编号

　　当需要产出涉及多个界面的设计方案时，给每张图进行编号标记(或类似交互文档的页码)，并保证交互稿与视觉稿的编号一致。

　　这样在后续和视觉、前端、开发、测试沟通的过程中，可以通过编号迅速定位到疑问所在区域，而不需要花更多精力进行描述和查找;前端在参阅设计稿的时候，也能更方便地把交互和视觉方案对上号。

　　及时同步状态

　　当设计方案发生变动后，即使是细节微调、或口头确认得比较清楚，最好也还是及时同步更新最新的设计稿链接给项目组成员。

　　否则的话，开发按照旧版本设计方案执行，测试按照旧版本设计方案提BUG一类的乌龙状况也更容易发生;与其等问题发生了再来想办法补救，不如在更早的阶段将其掐灭。

标签：英语方案跨学科设计活动