《设计团队协作权威指南》—第1章1.1节设计团队的要素

本节书摘来自异步社区《设计团队协作权威指南》一书中的第1章1.1节设计团队的要素，作者【美】Dan M.Brown,更多章节内容可以访问云栖社区“异步社区”公众号查看。

第1章　当设计师成为参与者
设计团队协作权威指南
设计师，总是团队中最雄心勃勃的人。毕竟那些成功的设计概念和产品享有广泛的知名度。任何行业内，往往那些知名的设计师们会被人们视为唯一一个有远见的人，比如：史蒂夫·乔布斯、迪特·拉姆斯，还有保罗·兰德。然而，所有成功的产品，都不会是某个创意的灵光一闪那么简单。设计师们更喜欢这样的故事，在他们看来这种充满神秘感的体验就是设计的本质，但终有一天他们会看到事实的真相：设计不是个体行为。本书将围绕这一点阐述很多理由。至于“自家后院车库里的天才”这种故事，就算它是真的，您也别指望将来还会发生。无论如何，仅凭设计师个人的构想和努力是很难凑齐设计工作的所有要素的。

本书的最终目的就是想要让使设计师们放下思想包袱。当设计师作为一个参与者的时候，并不意味着他们驾驭、领导和影响团队的地位会不保。我们讨论这个话题时，对“设计师”进行了新的定义，从今以后，那种整天游走在漂亮图纸和概念中的纸上谈兵者不再被我们列入“设计师”之列，我们所指的设计师是那种在大型团队合作中充当潮流的引领者，具有高瞻远瞩的目光和全面视角的角色。换句话说，无论能力大小，设计师首先是一名参与者，而作为一个参与者，并不意味着让出控制权，而是说，设计师要在团队合作中借由合作的力量来寻求控制权。

下面这三点，促使设计师转变为一个参与者。

1．就算您是所参与项目中唯一一个设计师，也别妄想仅凭一己之力就能完成任务。

2．作为一个参与者，设计师将扮演许多不同的角色——领导者、协调人、专家、评审、主管，甚至发起人。不管怎么说，您都必须做出相应的贡献，同时担起相应的责任。

3．要想成为一个有影响力的设计师，您不仅要会扮演各种角色，还得在各个角色之间游刃有余。而这都取决于您对整个团队的认识和了解程度。

本章将诠释这些内容，首先解释一下设计团队的定义。

1.1　设计团队的要素
设计团队，是指由一群负责设计并创造产品的人组成的集体。有时候，这个团队被称作“项目组”或“开发组”。就像一个家庭，它有核心成员，在此基础上不断扩展，有时会融入投资方或业内专家（图1.1）。

以上要素是一个团队的主要部分。将这些要素综合起来，我们可以这样理解：如果一个设计师能称得上是经验丰富的话，那么他一定对每个人员的角色、目标和方法都了如指掌。在这里，我还会将这些要素做进一步的细分。

更重要的是，我将为设计团队提供一些原则，指导他们收集并评估这些要素。这些原则是优秀团队获取成功的法宝，也是任何团队避免失败的最后保障。这些因素决定着一个团队是否能从良好的合作习惯中获得最大的利益，这一点在后面的章节中会详细讨论。另一方面来说，这些因素也决定着一个团队是否能够最大限度地化解矛盾，优化合作。

1.1.1　角色和责任
一个项目团队通常会为团队成员分配各种角色。这些角色担负着不同的任务，承担着相应的责任。以我的经验来看，大多数设计团队通常把人员分为4类。

设计师：负责构思和汇总创意。比如产品的工作原理、外观或功能。一个项目可能涉及多个专业领域，每个领域都有相应的设计专家。这些人中，应由最具创造性视角的那个人来充当“领导者”。
项目经理：这个角色确保团队和成员有效履行其承担的义务，他们负责制订计划，并且确保计划准确高效地执行。不同的项目赋予他们不同的地位：有的项目中，首席设计师身兼项目经理，而且这种职责会得到加强，有的项目中这种职责又会被削弱。
业内专家：这些人（有时是设计师）负责在设计的过程中建言献策。他们可能是产品的使用者，也可能是在该产品领域里解独到的资深人士。
投资方代表：代表投资方的那个人最终对项目的成败负全责。他们手握着财政大权，是这个产品项目的实际拥有者和最终获益者。
其实还有其他角色，但是在我接触过的人中，九成都可以归入这四个类别中。

看起来这些角色似乎挺有趣，但那只是停留在表面罢了，至少在网页设计领域，这些角色枯燥到令人作呕的程度。对我来说，真正有趣的是研究分配角色的原则。

术业专攻原则
在一个项目中，一个人可能扮演多个角色，但身兼数职会使合作的价值大打折扣。

角色的分配没必要“一个萝卜一个坑”。个人最多只可能充当三个角色：首席设计师，专项设计师和研究助理。

尽管如此，有些角色是不能兼职的。一个成功的项目通常不会让投资方代表兼职设计师，这是为了避免彼此间的干扰。大多数情况下，团队只有在设计活动和商业活动彼此独立的情况下，才会产生最大价值。虽然说这方面史上也有特例，只不过非常罕见。但是话又说回来，设计师有权力也有义务同投资方一起制定项目规划。

内部风险最小原则
在一个项目中，设计师的个性、工作风格和偏好等因素会带来额外的内部风险。

一个项目本身就面对着很多外部风险，因此团队必须尽量避免人员分配等因素带来的进一步内部风险。外部风险主要包括上游对项目的要求、目标、事务权限或设计参数的更改。

不合理的人事分配会带来风险，或者不顾对方分身乏术的窘境，强加任务。尤其是小型团队，这个问题更加突出，设计师可能同时要涉及多个项目，要让他对每个任务都做到一视同仁真的很难。

进步原则
项目团队应该让参与者感到参与项目对成长进步有积极意义，因为锻炼是人生进步的阶梯。

就算意义不大，参与者至少能够增长一些阅历吧。也就是说，如果项目本身没有什么吸引力，那么就让团队变得有吸引力好了。

利益捆绑原则
分出几杯羹来——让每一个参与者都能感觉到自己是该项目的拥有者，这有助于团队成员深刻理解大家奋斗的目标。

成员乐于了解他们的角色，因为项目中的每个角色都不是摆设。他们想知道他们能掌握和驾驭什么，他们得在哪里效力。他们还想知道别人在干什么。总之，别藏着掖着，让他们树立“团队是我家，发达靠大家”的牢固理念。

多样构成原则
团队要想取得成功，必须使来自五湖四海、各怀绝技的人们都向着一个共同的目标去努力。

一个项目需要多人合作，常言道：“花有百样红，人有百样种”。这种人与人之间的差异，可以成为优势，也可以成为劣势。当团队成员们各显神通、优势互补的时候，这种差异可以成为成功的条件。反之，一旦人心散了，队伍不好带了，这种差异又会成为借口。

1.1.2　目标和重点
用目标和工作重点来定义设计团队，相当于用角色来定义它。与角色一样，目标和重点也是由外部来定义的。

项目目标不仅仅涉及到它的最终状态，如产品的问世、专利的说明、营销的方案、建筑的竣工等，还涉及对外界因素的改变。设计项目通常服务于商业目的，例如卖出更多的部件、吸引更多的客户、创造更多的需求等。

意义鲜明原则
不知从什么时候开始，“改变世界”成为雄心壮志的范本。团队成员们更愿意去做一些能够改变人们生活的项目，尽管有时候这种改变微乎其微。

我所见过的大多数设计师优先考虑的是如何改变人们的生活，即使这个项目能带来的仅仅是感官上的刺激。尽管说，身为设计师，也要追逐利益，但是身为知识分子，有时候还是要境界高。所以现在不少设计师会投向公益项目，此时已不是为利，而是为名。

立场相符原则
人们会从与他们信仰相一致的工作中得到更多的满足感。

有时候，尽管设计团队担负的项目是有意义的，但是它可能让成员很不爽。您要一群绿色和平主义者去设计一艘捕鲸船，他们肯定感觉像吞下一只老鼠。尽管这些立场和见解是主观的，但是它们可以影响整个团队的工作热情。再牛的设计一旦指向错误的目标，那它也就称不上伟大了。

去新奇性原则
一般而言，大家都认为设计师不喜欢去做新发明，事实上也是这样。

尽管一些畅销品牌和牛逼的产品为设计师博得满堂彩，但大多数设计师只是想做一些他们感兴趣的工作。只要日常的工作能够平添几分色彩，他们可能会接受一些极其偏门的设计课题，比如为某个名不见经传的牙科诊所设计一个处理索赔业务的应用程序。

1.1.3　技术和方法
一个团队解决设计课题的方法，可以用来定义这个团队。这些方法包括以下几点。

方法论：为实现项目目标，团队所遵循或参考的思想流派、设计理念。
进程：一方面是对生产步骤进行尽可能的细分，另一方面是促进每个成员达到各自目标所需的流程。
技术：用以实现项目中某个特定阶段目标的活动，比如研究用户需求或确定设计方向。“技术”一词意义广泛，可能是正统科学，也可能是旁门左道。从技术上来讲，团队一般基于总体方案和项目目标来确定技术方案。
行为适当原则
依据正确的行为采用适当的技术。

显然，每一项活动都应该确保项目不断接近最终目标。不言而喻，很多设计团队往往围绕他们习惯性的工作来组织项目，而忽略了项目本身一些具体的需求。

新技术原则
一个项目应当以现有技术的新进展来为设计团队提出挑战。

好的技术能够适应不同的情况。技术的杠杆作用很大程度上依赖于行为的方式，可能包括以下方面。

规模：您准备做多大。
形式：项目输出什么。
深度：如何具体团队的所得。
参与：从外部引入多少资源到核心团队。
附加：有多少技术需要依赖其他的活动或产出。
例如，回访用户的技术用来收集用户反馈，这一技术在网页设计中很常用。这一技术可能大范围采用新型应用程序。但是，基本的做法没有改变——关注目标受众——但是在用户人数、人员构成与分析手段等环节的把握上，则具有相当的灵活性。

1.1.4　项目参数
项目参数是一大堆用来确定项目限制边界的数据。它们一般是如下３种类别中的一类。

范围：产品特定的边界或要求，也就是说设计师应当关注产品或市场活动的哪些部分。在网页设计中，项目的范围通常是页面或应用程序，或者是功能的各个方面。
时间、资金和地域：这些“物理”上的限制，就像做多少预算，项目周期和截止时间，团队运作的时间和空间因素等。
环境：该产品将出现的领域。这可以是技术层面的，例如一个特定的服务网络；或是物理层面的，例如一个建筑工地；还可以是虚拟层面的，例如某个组织用于获得新业务流程的领域。
优秀的团队在项目最初期就能搞清这些参数的定义。

完整定义原则
在一个项目中，应尽早定义出项目的框架。

项目初期，这些参数定义得越精确，设计团队就会越高效。一个设计团队可能被迫花费大量精力去处理项目参数的转换工作，从而没有精力集中在解决设计课题上。在这种情况下，他们会发现，他们可能已经利用很多解决方案替代了原本优秀的解决方案。参数一变，设计面对的挑战相应而变。

合理约束原则
所有参数和边界都有意义，不能随意设置。

面对设计难题，当设计师发现一个显而易见的解决方案因为一些愚蠢的业务规则或低级的技术问题而不能付诸实践时，那种沮丧可想而知。一个简单的例子是关于交付期限的——如果制定交付期限是基于项目本身的规模，这是合理的；或者是设计方允诺给客户的时间节点，这也说得过去；但是要是基于诸如“季度末”这种天然时间的划分，这就很不合理了。

参数灵活原则
项目团队会用一个范围去衡量参数的灵活性，而不是简单的“是”或“否”。

限制条件不能生硬死板。成功的项目取决于一些约束条件的回旋余地。例如，交付时限和阶段进度可以是固定的日期（几月几日）或合理的时间段（某月的第一周）。