接着上次的外包项目总结说。
三、定义公共交互
如果说前面的模块化是为以后的设计做准备，那么公共交互这一块其实就是贯穿整个设计的过程。在做设计的过程中，其实会发现很多小流程的处理，之前已经做过了，做过了我当然不会再画一遍，再写一遍逻辑，我一般只会写“此处XX逻辑参考XX页的XX图”，不过慢慢地，这些一多，就发现自己也会乱掉。当出现次数超过四次时，我就每次写那句话都有点不太放心，怕自己引用的那个地方也是缺省的，所以每次都要把交互稿翻一下，然后才能信心满满地写下这句“此处XX逻辑参考XX页的XX图”。
碰巧之前在一家公司遇到过他们的交互稿，一个公司的产品那就是相当复杂了，所以他们会把一些公共的交互给罗列出来，放在交互稿的前面部分，然后每次引用的时候就是引用公共交互的东西。我觉得这个可以借鉴到小项目的交互稿里面。也就是说，交互稿除了一开始的说明以及后面的线框图之外，中间再加入一张画布“公共交互”，然后把所有出现过两次以上的交互都可以总结到这张图上，这个公共交互当然是自己一边做一边维护的，不过想来，这样子做，既可以保证自己画图的质量和效率，对于开发来说也是很有裨益的吧。
一些常见的公共交互有：删除操作、编辑操作、分享操作。只要把这些操作流程在公共交互里完整地写一遍，后面的就可以大胆地复用这些公共交互了。
四、沟通方式
正如我一开始说的，我们是一个新的团队，大家彼此之间都没有合作过，也不清楚各自的工作方式，导致在设计过程中会暴露出很多问题。我是交互设计师，可能对于整体的把控会更加良好一些，视觉设计师天生比较浪漫主义一些，所以一些事情需要我为他们考虑到，如果没有考虑到，他们可能就会耽误项目的进度。
说两点在沟通方式上出现的问题，供大家参考一下。
第一点出现在进度安排上，在我做完交互稿之后，发现页面的数量大大超出了预期，结果他们一听到就开始信心大受打击。虽然我一直反复跟他们说，增加的页面都比较简单，但是他们完全都听不进去，直到后面他们两个人的分工出现了问题。所以这时候我就只能跳出来做协调人。首先当然是统计页面的数量，然后给页面分级，分为“主-次-送”三个等级，主要页面当然是比较复杂的页面，次要页面是简单页面，考虑到有一些页面实在太简单了，就当作赠送给公司的。分级的好处就是，他们对于项目的难度有一个较为良好的认识，压力没有那么大。然后我根据他们的工作能力（一个工作经验较为丰富，另一个经验稍显欠缺）、剩余的时间以及他们之前的协商结果，把整个计划表表做出来，计划表一是可以方面地查看进度，更加重要的是对视觉设计师的一种“束缚”，束缚他们的浪漫主义。所以计划表一出来，整个项目才得以顺利实施下去。
第二点出现在成果交付上，首先就是他们的视觉稿。他们习惯用Photoshop作图，然后也比较随性，随性的结果就是虽然界面看起来很干净整洁，但是图层的管理就一坨shit，各种“组1”、“图层1”、“方块1”的命名层出不穷，外人根本没法看。你要问为什么这会是沟通的问题？因为我也要审核他们的视觉稿，有些小问题我自己就改掉了，但是面对这么杂乱的图层结构，真的是没什么改动的欲望。
接着，就是视觉稿PSD的命名了。我在做交互稿的时候已经将功能模块化了，每个模块都会有各自的命名和编号，注意这里的编号才是最重要的，因为可以方便地回溯。但是他们在命名的时候恰恰忘了把这个编号加到每一张PSD上，所以后面整理的时候出了纠纷，还是在我的强烈要求下，他们才全部改了一遍。然后是这么一堆PSD文件，不可能就随便打个包吧，至少按每个模块建立一个文件夹吧。然后如果PSD文件有改动，要怎么命名吧。这些问题都是一开始没有想到的，也没有协商好，结果导致合作上出现了问题。虽然都是小问题的，但是这些都是会在项目的末尾暴露出来，说实话，影响最大的其实是心情，真的是心好累。
林林总总，写下这四点，当作是给自己的一个总结吧。
