交互设计中的项目跟进怎么进行？

2016-04-10 21:54:00

从8月中旬开始接手了产品的大改版，经过半个多月的时间，基本完成了前三个阶段（输出了几经评审的交互“终”稿）。

视觉阶段

交互文档也有美丑，好的交互文档不但界面美观而且视觉逻辑清晰。虽不提倡在交互稿中使用过多的颜色而干扰了视觉设计师的发挥，但是可利用深浅对比实现界面元素的操作逻辑。展示给用户的界面都应该有所重点，引导用户以期望的路径使用产品。因此好的文档视觉设计师可以一目了然的读懂你的意思，节省了很多沟通成本。

同作为设计，交互和视觉必然相互影响，首先交互设计师自身需要具备一定的视觉素养，但是你不能指望领导也一样能够看着交互稿就在脑中浮现视觉后的样子。设计师都是独具奇思妙想的个体，同一个界面很可能你与视觉设计师理解的完全不同，又或许他们并没有get到你交互稿上想专门强调的东西，差之毫厘失之千里的情况也不足为奇。所以很可能交互评审阶段没有遇到的问题，到了视觉评审的过程中出现了，这个时候会出现两种结局：视觉设计师默默地重新出方案直至领导满意 or 丢问题给交互，让我们去改方案重新评审交互稿。我想说的是，无论是那种结果，我们都不能抛开自己作为上游的责任。不要觉得遇上第一种就可以高枕无忧，遇上第二种就开始怨天尤人。你可以跟视觉设计师沟通页面的设计思路，找一些可行性的方案给他们参考，又或者在不影响交互的前提下对交互稿重新做以调整。

开发阶段

到了开发阶段就进入了验证你交互的第一关卡，开发小哥会从各个方面对设计提出质疑，因为想问题的角度不同嘛。过程中有时会被他们提出的要求弄得很无奈，但也经常会为他们严谨的开发逻辑感到叹服。这个环节沟通很关键，要把没有生命的交互稿变成活生生可以操作的功能可不是几页文档就能搞的定的。

首先交互稿不可能做到完美无缺，改动是在所难免，这个时候要注意的是无论变更点有多小，都要做好修改记录同时告知所有相关人员。原因是大家都很忙，没有人会去天天一遍遍的盯着你的文档，所以有改必应才能让每个人做到心中有数。

如果开发过程中出现了大的交互疏漏，这个时候切勿六神无主，要知道自己已经不是小孩子，出了问题没人给你兜底。首先正视问题的存在，至少没发生在上线以后被用户黑成一片就该万幸，接下来就是做好补救措施。这个时候发封邮件是不错的选择，表明因自己疏漏造成的影响和对大家的歉意，同时说清楚问题的解决方案，接下来呢当然是就地复活重头来过喽。

有时候开发小哥会因开发难度等问题提出简化方案或取消功能的要求，这个时候最好是拉上产品经理一起协商这个问题，每一个功能的去留都不是谁一句话就能决定的。至于能不能简化方案这就要看现实情况了，不是不可以但是一定要事出有因，权衡利弊后决定的方案才能让每个人信服。这种情况下如果你能用个人魅力打动开发小哥让他欣然接受，那就是再好不过了^^

测试阶段

到了测试阶段将意味着你要被扒光了放在太阳底下晒了。啥意思，测试会根据你的交互文档写测试用例，一个符号、一个标点都将成为他们二次确认的关键，每每从测试手中经历过的交互稿都将焕然一新。所以呢，你的马虎潦草都将增添他们的工作量。

上线前会出各种的提测包，这个时候测试就会比对着用例一一跟产品进行对照，发现矛盾的地方就会再次跟开发交互沟通，以确认是哪一方出现了疏漏而造成的不统一（交互没有及时更新文档且告知 or 开发没有按照交互要求实现）。这个阶段我的经验就是一定要有耐心，不要反感他们一遍遍的问你问题让你确认。测试人员是产品上线前的最后一道防线，他们的努力辛苦都是为了能让你的设计想法最完整的展现在用户面前。

作为自己负责的平台，就要像孩子一样对他，不要觉得有专门的测试人员自己就不需要试用了。无论是视觉设计师还是交互设计师，作为最了解设计的人我们都无可厚非地要有所承担，因为最熟悉所以走查起来也会事半功倍，大家相互补充才能做到完美的契合。