本次是《设计原本》阅读笔记第三篇，主要讲协作方面的内容。
现在几乎没有那种一人包揽全活的设计者了，绝大多数都是设计团队。为什么设计会从个人转变成团队？首要原因是技术复杂性。随着人们对科技的不断探索，越来越先进的知识思想被创造出来。使得工程上跟着进行了技术改进，对技术的要求越来越复杂，这个时候如果再让一个人去包揽全活，先不提及巨额的工作量，光是掌握那么多知识就是强人所难了，毕竟我们不可能在用人时把所有人都看作是完美的。第二个原因就是快速推向市场。即使一个人再怎么强，但在工期上是远远比不上团队的，而随着科技的发展，特别是IT行业技术迭代速度更加可怖，人们往往需要快速完成新设计，新产品。因此市场竞争力变得更加激烈，所谓“双拳难敌四手”，独立设计者除非能做出超超超前的作品，否则很难长期维持下去。
当有了团队设计之后，我们引入了一个新的概念——协作。对它的理解就是它的字面意思，团队成员们互相协作完成工作，这确实能极大提升效率，而且多个设计者参与设计往往更容易想出新的点子。那么协作就一定是百利而无一害吗？显然不是，协作也存在着弊端：分割成本。往细了说，假设正在进行一个软件的开发，那么随着设计的进行，接口越来越多，而由于在团队中对接口的编写通常不是由一个人来完成的，那么为了能让其他成员明白这个接口的含义，你需要做出解释，而解释效果的好坏还取决于个人的理解问题，这其中就存在一个集成问题，极端的说就是1人完成所有任务设为1个成本，分成了n份给n个人完成就变成了n个成本。而不只是分割成本这一个问题，我们还要考虑到学习成本和沟通成本。沟通成本不必多提，一个团队中沟通是必要的，它显然是需要付出一些代价（成本）的。学习成本也好理解，一个设计团队每个人掌握的知识并不相同，为了更好的合作开发，虽说不必让其他人完全掌握你所学习的知识，最少也要明白你用的这个知识是什么意思，要做什么，该怎么用。这里就存在一个互相学习的过程，就像一个简单的补习班一样，你需要上交名为“时间”，“精力”的学费。最后就是变更问题。不要以为变更需求很容易，它往往起到了一个连锁反应，如果是1人独自开发的超小型项目（甚至都谈不上是项目），那么变更需求无非就是改改参数罢了，而变更需求放在团队项目里是灾难性的，它不只是牵扯接口变更，极可能是牵扯到多个人的工作内容，这也是协作带来的“铁索连环”。
作者在对协作的探讨还进行了进一步的深化。首先在进行协作之前，为了尽可能的规避不必要的麻烦，那么在设计之初需要为团队设计获得概念完整性。简单的说就是概念上的一致，而为了能够实现这个任务，出现了一个非常重要的职位——系统架构师。一名系统架构师必须在相关的技术领域具有能力，必须对要设计的这类系统有经验，必须对系统的特点和目的具有清晰的愿景，真正关心系统的概念完整性。作者认为协作在以下场合是有帮助的：确定利益相关人的需求和愿望。多一个人多一份智慧；概念探索。即头脑风暴。一些团队内部的良性竞争也能促进协作；设计复查。不同的成员关注点也不同，这样在检查的时候能够更加全面。同时，作者认为协作在以下场合是无用的：对设计本身。这句话似乎与前文所探讨的内容起了冲突，而通过作者后面的描写，我个人对这句话的理解是：有些所谓的“协作式设计”并不能称之为设计，而更像是对设计的改进；概念设计尤其不能通过协作完成，需要一个主设计师敲定。对概念设计这一方面，真正的协作不应该是把概念设计也分解掉，而是由一名主设计师完成，其他团队成员予以支持。
最后就是由于科技进步带来的新型协作方式——远程协作了。它的实现方式有很多：电话，视频会议等等。远程协作最大的优势在于能够一定程度上节约成本：比如你不必为了一个会议从东边跑到西边，只要一个视频会议就可以解决问题。当然，这不代表你可以直接推掉所有的面对面时间，不如说有了远程协作方式之后，面对面变得更加重要。因为有些及其重要的决策，面谈效果才是最好的。