从完成视觉稿到上线，你还需要做这些(下)

上一篇传送门：《从完成视觉稿到上线，你还需要做这些(上)》

上一篇讲的是适配标注以及切图，这次来讲后面的三步：制作Demo、跟进开发以及验收。

制作Demo

制作Demo可以在完成适配标注以及切图两步之后，与程序员搭建页面同步进行。Demo的目的是帮助程序员及测试理解整个复杂的交互流程，一边看着交互稿，一边看着视觉稿，无疑会给他们增加许多困扰。如果视觉设计师还改了交互，那就更增加了程序员与测试的困惑。所以，与其他们一遍又一遍来问你，不如给他们出一份Demo，也就省得同样的话说两遍甚至三遍了嘛。

那么制作Demo其实并不麻烦，现在市面上也有好多软件可以制作Demo，其中有一部分还与设计软件相通，支持一键导入视觉稿。这里不是要求大家做出与Dribbble上相媲美的动效，只是通过动态的方式表述清楚各个页面间的跳转以及页面内的状态切换即可，毕竟相比交互稿上冷冰冰的文字，Demo展示易于理解多了。

考虑到程序员和测试的电脑上没有安装制作Demo的软件，我们不能直接将源文件发于对方。这里有两个办法：一是在测试机上装上预览Demo的软件，让他们直接通过测试机预览Demo，这种方法自由度高(哪里不懂点哪里)，但是对配置有一定的要求(需要至少两台测试机供程序员及测试使用)；另一种方法是，录制成一个视频，里面包含每一步操作，这种方法对配置没有要求，有电脑/手机就可以预览，但是自由度就没有了(不能哪里不懂点哪里了)。

至于为什么不是由交互设计师来完成这项工作，我前面也提到了，有可能视觉设计师改了交互方式，对于新的交互方式肯定是视觉设计师更熟悉。此外，有的项目组可能并没有配备交互设计师，那这项工作理所应当由视觉设计师来完成了。

跟进开发

这项工作没有具体的时间节点，在程序员开发的过程中可以随时与他们进行沟通。主要是了解一下在样式开发上有没有遇到什么难题，可以对危机进行一个预判，提前准备好备选方案(比如阴影无法实现，用描边替代，相应的间距调整到多少合适)。避免在最后的验收阶段手忙脚乱，一边校对样式，一边还要反复修改样式。

验收

验收的重要性如同上次提到的适配，你最终呈现给用户的是线上的界面，而不是你电脑里的设计稿，所以最后的验收环节也就显得尤为重要了。

许多设计师以为的验收，是搬个小板凳坐在程序员边上，然后对着电脑上自己的设计稿指指点点。且不说这种方法程序员能不能记住你说的这些问题，光是让设计师和程序员挤出一段共有的时间来做这件事都难上加难。

既然口头说明行不通，那就改为书面说明。将测试版本截图与设计稿做比较，不仅要指出不同的地方，还要明确告诉他如何修改。因为仅仅指出不同的地方，让程序员再去找最初的标注稿，大大增加了他的工作量，不如让更熟悉设计稿的你来告诉他应该怎么改。最后，将整理出来的问题汇总到一个文档里，这里我推荐使用PPT导出PDF的形式，一页一个问题显会得比较清晰。

完成一轮的验收后，别忘记还要进行第二轮验收，来验证前一轮的问题修改得如何，如此往复直到项目deadline或者验收通过。

验收的问题中，其实有很多都是多机型适配的问题，所以做好之前的适配标注也会让验收阶段变得更为轻松。

更多关于验收的知识，可移步参考引文中，橙子的橙子总结的《如何高效的进行设计验收》。

总结

细心的小伙伴可能发现了，从完成视觉稿到最终上线的这些个环节中，都离不开程序员的身影设计师与程序员始终是一个配合的关系，而不是对立的关系，大家都是为了界面可以更好地呈现在用户面前，所以没必要在发生问题的时候急于推诿责任，而是应该静下心来站在程序员的角度想一想，怎么才能让他们更方便高效地理解我们的设计意图，毕竟他们也是我们的“用户”，我们要对他们的“体验”负责。

简单小结一下本文的内容：

制作Demo：方便程序员和测试预览各个页面间的跳转和页面内的状态变换；可以导出视频，也可以在测试机装Demo软件预览。

跟进开发：对可能出现的危机有个预判，提早做好应对方案。

验收：采用书面文档的方式，将问题点与需要如何修改一一说明；至少两轮验收。

参考引文：

《如何高效的进行设计验收》http://t.cn/E5cPQdz