作为一名交互设计师，如何更好地与项目里的其他人合作?如何更好地利用大家的时间?团队经理用画图的方式跟我解释了一下，有些问题并没有直接的答案，但是我觉得解释的方式很有趣，我凭着记忆把它们重新画了一下，和大家聊聊合作的问题。
今天和我的经理聊了一下最近工作上发生的事：上周做了什么，这周和下周准备要做什么。刚刚结束了设计阶段(Design Sprint)1，和客户开了远程会议，收到了许多的反馈意见，各个方面的都有。
现在项目正处于一种(我觉得)特别尴尬的阶段：视觉设计师只出了初步的几个概念图，程序员还在准备框架，尚未开始写代码，但是根据原先的计划，这周就要开始开发了。作为交互设计师，一方面留着一大堆反馈意见还没有反映到线框图中，另一方面设计阶段2的任务已经要来了。虽然还没有开始设计，但从可能的流程上来看，任务量巨大，是一个特别复杂的系统，不光是设计一个新的交互方式，还是新的工作方式和商业模式，心里真没底。
我把自己的困惑告诉了经理：作为一名交互设计师，如何更好地与项目里的其他人合作?如何更好地利用大家的时间?他用了画图的方式跟我解释了一下，有些问题并没有直接的答案，但是我觉得解释的方式很有趣，我凭着记忆把它们重新画了一下，和大家聊聊合作的问题。
什么是敏捷开发（Agile）
先说一下总体的合作方式，我们用的是敏捷开发(Agile)的方式。维基百科上是这么解释的：
敏捷软件开发(英语：Agile software development)，又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
如果把这种方法简单视觉化一下，就如下图：
IxD指的是交互设计(Interaction Design)，VD指的是视觉设计(Visual Design),Dev指的是开发(Development)。ABCDE在这里代表的是不同的阶段或任务，在frog我们叫做设计阶段(直接翻译可能是设计冲刺Design Sprint)。
这个图的意思就是：当一个设计阶段A结束时，交互设计师就会把工作移交给视觉设计师进行A的设计，同时开始B的交互设计;视觉设计师随后对A进行视觉设计，然后交给程序员进行A的开发;当程序员进行A的开发的时候，交互设计师的B也做好了，然后转交给视觉设计师……如此往复，敏捷开发的最大的特点就是不需要设计师把ABCDE全部设计完后才开始设计，而是在某个阶段结束后就开始进行软件开发。
什么是瀑布式开发（Waterfall Model）
与之相悖的方法叫做瀑布式开发(Waterfall Model)，维基百科解释如下：
瀑布模型(或称瀑布式开发流程)是由W.W.Royce在1970年首次提出的软体开发模型，在瀑布模型中，软件开发被分为需求分析，设计，实现，测试(确认)，集成，和维护这样的步骤依序进行。
纠结的交互设计师
敏捷开发现在运用得越来越广，但是据(经理)说却让设计师更加纠结，这一点我确实有体会到。因为任务被划分成了一个一个小阶段，时间又很紧。我觉得任务A还没做完时，就必须开始做B，把A移交给其他人去做他们该做的事了。而随着任务BCD的进行，可能是需求变了，可能是视觉或开发遇到了问题，经常还要回头去改A，一旦交互改了，后面的视觉设计、开发也要跟着改。因为没有足够的时间去思考透彻A甚至全局，导致回头修改之前的设计的几率大大增加。
更糟糕的情况可能是当你做完了ABCDE，却发现事情远远没有那么简单，其实还需要做FG等等才能把整个流程设计完毕(如下图)。怎么办?
可惜，并没有直接的解决办法!有两种可能解决的方法：
1. 交互设计师早一点开始，先把ABC都设计得差不多了，才移交给视觉和开发。这样做的原因是，给交互设计师更多的时间去理解问题，尝试解决多个方案，把整个的设计概念调整得差不多了，才交给视觉开始做更高保真的界面图(comps)。
2.交互设计师和视觉设计师更紧密地在一起工作，减少交互和视觉之间的时间间隔。更早地看到高保真(high fidelity)的界面图，有问题可以立即调整，然后再把已经比较成熟的方案移交给程序员。
切忌走得太深
再谈谈我纠结的“还没设计完善就就要进入下一步”的感觉。之前在我的心目中，交互设计师把线框图画完，整个设计的基本框架就定下来了，包括信息架构、交互模型(interaction model)、主要的模板，视觉设计师只是在线框之上锦上添花，表达更多的东西。而现在我移交给视觉设计师的线框图非常地低保真(low fidelity)。有些交互模型还不是最佳的选择，有些页面的非主要信息还没加上去，排版也不是特别好看，总之许多细节没有敲定。而之前在学校做项目基本上是一人全部操办，做完了线框图马上就做视觉稿了，甚至直接作出的线框图就挺简单好看了。我的经理给我的建议是，不要在一个小流程里做得太深入。打个比方，假设这是你作为一名设计师可以做出的深度：
现在，作为一名交互设计师，要想办法把一部分工作让出来，给视觉设计师，自己只做到这么深就够了：
交互设计师只负责低保真的线框图，让视觉设计师自己去操心怎么做出高保真的图来。这么做的原因有二：
1. 这体现了交互设计师对视觉设计师的尊重。让视觉做自己擅长的事去，不必要越俎代庖，把别人的活也干了。
2. 交互设计师节省了纠结细节的时间，把主要的精力放在“解决问题”上面去。让自己的头脑一直处于“解决问题”的模式。有利于项目整体的效率和成功。
初级交互设计师应走得宽
公司对于初高级设计师的期待是不同的。初级设计师应在同一个问题上走得更宽。假设下图反映的是同一个问题的不同解决方案ABC：
假设现在有一个问题要解决，随便举个例子吧：如何让用户把商品放入购物车?一般来说，初级交互设计师会给出1-3个解决方案，这三个方案可能有的非常直接，可以做得很深入，有些比较麻烦，做得比较浅。有个几个方案后，会选出一个来更深入地探索。然而，如果是更优秀的初级设计师，应走得更宽一些。同一个问题，可能会想出ABCDEFG7个方案，这当中肯定会有一些看起来很荒谬或者行不通的方案，比如E。但是方案E中的某一个点很好，最后选中继续发展的方案可能是A中的一部分，加上了E中的一点，一个有突破性的好设计就这么诞生了。这一切的根基则在于能够产生足够多的点子来挑选。
我身陷泥淖，你放心飞吧
关于为什么要把交互设计和视觉设计分开，让不同的人负责，经理打了个比喻，我觉得很有意思：
交互设计师生活在重力加速度g等于地球的10倍的地方，处理的是那些的最沉重最纠结的问题(heavy things)。视觉设计师则生活在加速度g等于地球1/6的地方，他们轻得可以飞起来。只有我们(交互设计师)竭尽全力在g等于10倍的地方把问题处理好了，他们(视觉设计师)才能够飞得更高、更自由。(我：那我可以理解为，我们使用的是不同的大脑半球吗?)部分是这样，但是在交互设计师在对解决方案进行发散分析的时候(所谓“走得宽”)，也会用到右脑。
画了个简单的示意图表示如下：
那么，就让我专心地在泥淖中越陷越深，而你放心飞吧!：)