本期 SimpleUX Talker
“增加人手会让我们的工作变得轻松。”–是理想状态
“增加人手我们并没有提高多少效率”–现实往往如此
一、设计协作中1+1>2？
协作的价值
团队协作在今天的设计工作中发挥着重要的作用。在产品初期因为业务简单，一些小型的设计项目可以有一名设计师独立完成。但是随着业务的扩展，设计项目的体量变大，一名设计师已无法快速的响应业务需求去包揽所有的设计。
那么这时候团队设计便成为了势在必行的趋势，设计协作也变成了工作的常态，通过协作对效率的提升，可以让设计师们应对越来越快的交付要求。
协作的价值
在我们的固有观念中总是认为团队协作能让效率成倍增长，分摊到每个人头上的工作量会降低。然而在我以往的协作项目中却发现了一个奇怪的现象：明明是多了一个人分摊工作量，但实际上却根本无法达到 1+1>2的效果，这让我一度变得非常沮丧。
在项目中，我可以很好的与产品、交互、开发协作，但唯独无法与跟我同一战线的设计师们达到很好的协作（这里的协作是指两个设计师在同一个端里进行设计）。
这种低效率的协作，时常会导致我面临无尽返工造成的效率延迟，更严重的后果是最终的产出物会严重丧失掉概念完整性，这对于个人和公司来讲，都是一项非常严重的损失。
在无数次碰壁过后，我不得不让自己多花点时间来研究——究竟是哪里出了问题？
二、被忽视的隐性协作成本
最终我得出了这样一个结论，造成设计师之间协作效率低下的原因是：我们往往会忽略掉项目里，双人或多人合作之间的隐性协作成本。这些隐性协作成本大致分为4类：
- 分割成本
- 学习与教授成本
- 沟通成本
- 概念完整性
接下来我们分别来阐释一下。
分割成本
分割成本指的是—管理者对团队成员的职责划分和工作边界认定所产生的额外工作量。它可能存在于3个阶段：
项目启动前，已经安排好由2名成员成立小组同步进行设计；
项目进行中，由于项目体量以及工期的调整临时增加了协作成员进行设计；
项目完成后，由于人员安排问题而不得不移交给完全没参与过的成员来负责走查和维护。
在过往的经历中，对于团队合作来说，事情的麻烦点在于：布置任务的一方，想用多人协作的方式来完成任务，但在具体的工作分配上却在用单人任务的逻辑来解决问题。
那么矛盾就来了：任务与职责的不清晰，很有可能导致相互的推诿。
一个项目同一端设计如需交由多名设计师来完成，多一个人分配的任务与职责的定位就会成倍增加。例如：任务中的主辅职责定义、关键的复查节点、业务模块的分配方式等等…
统筹和对整体负责的人，要承担更大的责任，但这也是个锻炼，这是团队领导必须承担的分割成本。
学习与教授成本
学习与教授成本指的是—团队各个成员为了达到认知程度一致性、设计风格统一性，而付诸的学习与教授的人力和时间成本。
假如参与项目的人数是n个，那么潜在的沟通渠道就是n（n-1）/2，沟通的复杂程度也在增加，特别是当多名设计师之间出现设计分歧时，要达成一致更是要花费大量的时间成本。
沟通成本
沟通成本这块不做过多解释，在同端多人协作的项目中，通常是将每个模块分配到个人头上，并且最终必须确保每个人的模块都能组装在一起形成整体，这就要求设计师之间要有结构化的沟通。
在某一次我与设计师B协同完成一项任务时，在初步的定义好规范化后就开始执行。但规范往往是设计师们一边设计一边完善的，由于时间比较紧，我们拿着规范化各自开始任务，最后在合并时，发现新增的部分组件发生了分歧，部件之间不能很好的组装在一起，然后我们又花了很多时间在彼此说服上，沟通变得困难，项目难以推进。
概念完整性
概念完整性指的是—任何产品，我们最终的产物都必须在概念上保持一致，这种一致性通常是个人设计的自然结果。而协作设计如果想要实现这种一致性，大部分时候是需要管理者或主设计师投入精力来做整体把控和复查。
三、我用到的解决办法
基于上述列举的问题，这里我也给到我自己在工作中总结出来的经验，希望给大家带来更多的思考和帮助。
关于分割成本
分割方法
- 至上而下与至下而上的充分沟通
- 一对一个别交流
- 小组讨论
分割标准
- 分解后的活动结构清晰
- 包含临时的里程碑和监控点
- 所有任务全部定义清楚
下面是分别针对3个阶段给出一些建议：
/项目启动前
我们可能会遇到两名成员之间没有明确的主次关系，或者没有更高级别的管理者角色来把控设计的走向，成员之间没有明确的职责划分与工作的边界。
这种情况分割会较为困难，我给到的建议是：在项目初期启动之前，在成员之间指定一名小组负责人，或者主设计师，管理者划分工作范围，由小组长来划分细节工作的边界，制定标准和规范并向管理者进行汇报。另外一个人可以提出建议，但有分歧时以负责任的建议为准，负责任对最终结果负责。
另外一些初小型团队如果没有完善的管理制度，那么可以邀请管理者与成员一起开会，将各自的任务进行认领，并且共同探讨在未来项目中可能会面临的风险，以及提前做好应对措施。
/项目进行中
这种情况的分割相对较轻松，我给到的建议是：只需要把一些已经定义好设计规范的模块或者已经完成了风格确认的页面交接一部分给协作设计师来完成即可。
/项目完成后
项目在完成设计阶段后，将进入开发配合与设计走查的阶段，这个阶段设计师将要面临落地的问题，可能也会因为实际落地情况再对设计进行修改。而这时假如负责此项目设计的设计师被安排进了其他的项目之中，那么这一部分的工作需要安排给一个新的设计师来接替，关于这种情况我给到的建议是：
原设计师时间充沛，则继续执行大结构的调整，辅助设计师参与小细节的改动。原设计对结果负责。原设计师时间允许，则可以继续参与设计思路和指导、评定，辅助设计师执行，原设计依然对结果负责。原设计师完全脱离项目，则全权交接给接任设计师，并且责任转由接任设计师负责。
关于学习与教授的成本
我们也需要要求每位参与的设计师在项目开始前，熟练的掌握协作工具以及规范组件库的使用方式。如果公司想要协作带来效率，那么以下几点学习和教授的成本则不可忽视：
1）对设计师来说，需要花费一定的时间成本来熟悉规范和工具，这是提升协作效率的基本前提。
2）公司安排培训，哪怕有经验的设计师到来新环境都需要一定的适应期和学习期来适应新公司的制度和工作方式，所以需要对设计师安排一定的专业培训并进行考核，保证设计师在正式进项目前拥有协作的基本能力。
3）对于一些公司比较成熟经验丰富的设计师，可以承担起专业化培训和教授的责任，在教授期间也能巩固自身的技能与沟通技巧。
关于沟通成本
多人协助下，设计的各阶段或模块都会有一个指定负责人。负责人提前准备好设计建议，然后与协作者单独沟通，这实际上是小型的设计复查。如果协作者提出了一些不同的想法，但负责人没有接受，协作者应以负责人建议为准进行执行，同时准备一个备选方案。
再次召集讨论时，以负责人思路、备选方案进行综合评选，最终进行选择、融合或转向第三种方向。这样可以节约反复讨论时间，并尽量散发更多方向。当然随着设计师之间的磨合逐渐会形成默契，沟通成本会随之降低。
关于完整性
有时候我们在一个项目中会面对不同的角色，他们可能是同一个公司的不同部门，各部门之间会有各自的需求，这种情况导致的结果是——会让同一个产品的概念发生冲突。
在面临这种情况的时候，建议有一个人负责整合需求，如果把一支协作设计师团队比做一艘船，那么管理者或主设计师，就是这艘船的掌舵人。
其他
/如无必要，勿增人手
如非必要情况下，建议始终保留原有的设计班组，这样能让最终交付的成果一致性达到最优。
/不断升级协作软件
设计师的协作软件相当于士兵手中持有的武器。
例如我们使用的sketch无法避免的会遇到协作上的问题，那么是不是可以考虑采用现在市面上更新的协同工具例如figma、摹客。
有时候选择一款适合的协作软件，能让团队彼此间的协作达到事半功倍的效果。
四、最后
这篇文章是我工作多年的经验总结提炼，希望能够帮助你开拓思路、启发灵感。
协作，已然是当前环境下势在必行的方案，但是我们不能盲目的进行协作，协作中的隐性成本也不可被忽视，怎样更科学合理的完成项目协作，是每位设计师终身都需要去提升的能力。
