不久以前，设计系统很容易理解。
在2006年九月份一个凉爽的下午，作为一名设计师的我沉浸在使用Sun.com的设计风格指南（我们称之为组件库）中。即使以今天的标准来看，这个系统仍然是我见过的最强大、最令人兴奋的基于web的组件库：有上千个组件，每一个都由模块化的HTML、CSS和JavaScript组成。
领主法则 The Overlord Rules
这个库是由一个独角兽领主（在独角兽还没有出现之前）在另一个前端开发人员的帮助下创建的。他们支持代码和人员制作两种产品：一个营销站点和一个同级开发人员的文档站点。霸王监控着整个网络的需求（包括更多使用库的外围网络应用）、选择设计和构建什么、如何设计和构建，、并每月发布一次。整个库有一笔预算，并且该项目的节奏，资源和生产效率都是可以预测的。
不喜欢组件库里的东西？那就强硬的处理它吧， 而这是由领主决定的。
领主通常很忙。 是的，他致力于为像你这样的人服务。 但是忙于通过他的实践来满足一部分人的需求，这通常比你和你的项目更重要。
过去的领主：我们应该如何组织？
快速回到2015年。如果你认为一个设计系统它所涉及的人员、所应用的产品、所包含的部件以及所采用的实践——会稍微复杂一些，请举手。那我将高举双手。
领主一般不会主动扩张。
取而代之的是，如今，大型组织采用数字化设计，其规模相当于数百名设计师，他们工作于网站/原生app、桌面/手持设备、内部/面向客户和其他维度的无数产品。
现如今，更多的设计人员在编写代码。而更多的开发者在设计。产品经理对每件事都手足无措。他们都在团队中工作，团队遍布整个企业。你不能再合理地告诉他们该怎么做了。没有人是无所不在、无所不能或无所不知的。你们必须共同努力，建立更强大和更有凝聚力的东西。
那么，如何组建一支最能帮助你保持系统凝聚力的团队？ 这取决于你是谁以及你的能力。
尽管如此，现代设计组织正在从孤立的团队（使库可用）或集中的团队（为彼此不相关的产品提供服务）转向更加联合的方法。
团队模式一：Solitary 单一式
领主作为一个单独的团队模式在实践中经常存在，并且在某些情况下是有效的。从我这样的设计师的角度来看，Bootstrap本身就是这种模式。 作为一种原型，它还激发了许多效仿者并在内部分享其产品。
“我为我的团队建立了一个小型Bootstrap系统。你应该把它完全用在你的产品上！”
这是一个崇高的事业，使一个库可用。价值显而易见，对吧？ 这是基于认可的视觉语言，由另一个团队负责维护和发展的生产级代码库。
从一个已建立的资产库开始，为缺乏设计和前端开发能力的团队提供了重要的价值。当然值得一看，特别是如果该库具有足够的模块化功能，至少可以利用其中一部分来节省时间。
然而，对于那些问题最多只能由现有系统部分解决的团队来说，这种模式是很糟糕的。例如，构建事务性web应用程序的团队连接到一个用健壮的库构建的产品营销站点时，它们之间的差异足够大，以至于需要大量的定制和扩展。
另外，共享一个库并不意味着它的所有者能够获得或者不得不接受他们自己的流程和有优先级被拖延。无论他们的心态是否是无私的，一个单独的团队的主要动机是对自己产品的内在追求。采纳团队的需求这分散了他们的注意力。
所以，你想让我使用你的库，为你的需求而构建，它只会以与你产品使命相一致的方式发展？不，我会pass的。
这样，其他团队就可以自己建立自己的团队，如果有能力的话也可以自己动手。 让不同的旅程开始吧！
团队模式二：Centralized 集中式
一个集中化的团队通过一个专门的小组来支持这个系统，这个小组负责制定和传播决策和零部件，以供其他团队使用，但不能设计任何实际的产品。也许他们自己创造了设计语言和系统，或者他们正在实现一个由外部机构产生的愿景。
我们可以帮助您学习和应用已建立的系统，所以请让我们知道您需要什么，我们会做的更多，我们是来为您服务的。
集中式系统团队可以：
- 将设计语言、组件和模式扩展到广泛的产品组合
- 服务于多个产品团队，不受任何产品优先级的偏见影响
- 识别机会并提出请求以深化库
- 建立实践和流程来验证新设计
然而，集中式团队通常缺乏：
- 上下文情境，规范化解决方案只能间接地基于实际产品或平台的约束
- 促进设计师积极参与产品团队的能力，更不用说他们的贡献了
- 对日常和特定产品带来的挑战的可见性
- 对产品设计师的影响，以平衡产品和系统目标之间的权衡
最终，一个集中式的团队可以提供出色的服务，并在效率、一致性和容量方面创造价值。但要注意的是，他们的地位是脆弱的，他们想要证明自己价值的愿景可能会削弱他们为那些想要保持自主性的产品团队服务的效率。
团队模式三：Federated 联合式
因此，如果单一和集中的模式不适合，那么就需要更复杂的方法，这与高绩效人才组织相关：
我们需要在我们最重要的产品上用最好的设计师来确定系统是什么，并将其推广到其他所有人，而无需退出产品团队的日常工作。
近年来，跨平台和产品线的设计师的系统化思考得到了极大发展。Google Design的进步就是典型。一小撮不断壮大的有能力的设计师们使用“设计委员会（committee-by-design）”的方法形成了“Material Design”。
这样的委员会将系统的设计方向与有代表性的、经过授权的设计人员和领导者的子集结成联合，这些人被指定在一段时间内在该系统上进行协作。
他们可以共同做出设计决策，即使只有一部分（或其他子集）可以通过风格指南等记录、建立并传达这些决策。
这不是言论开放的时候，不是每个人都参与或拥有发言权。相反，联合组的决策会传播到其他产品团队，这些产品团队会选择使用该结果或忽视结果，风险自负。
联合式团队将会：
- 拓宽到很多平台和业务线的合法关联
- 通过表达多种观点来限制对偏见的看法
- 通过更多的布道者来轻松地在团队中推广系统
尽管如此，还是可能会人多误事。
另外，每个设计师都保留对其产品团队的自主权和忠诚度。直到系统具有强大的功能之前，设计师可能会限制他们的承诺，不可预知地参与，可能会表达出真诚的、根深蒂固的内疚感，甚至远离他们的产品团队。为了参与到这个模式中，设计师必须能够令人信服地超越部门的归属，以在充满凝聚力的用户旅程中更好地平衡他们的时间和决策。
联合式模式还引入了决策方面的实际挑战。设计讨论会自然而然地发生在办公桌上、走廊上、午餐时或在其他人都加入的Slack频道中。一对搭档可以展开讨论，讨论如何将次要按钮样式从轮廓切换为灰色。然后另外两个人在Slack中看到了这一点，并在那儿辩论了它的优点。 另一位设计师在其iOS应用程序中将它放在上下文情境中，它看起来很粗糙，突然之间每个人都感到困惑。
每一次谈话都会带来深刻的见解，甚至是动力，但是没有人能够跟踪或回忆起导致决策的路径（或者至少是最近的迭代）。个人放弃控制权变得至关重要。另外，团队必须在决断性和进展性之间取得平衡，以及在“所有人都愿意讨论时”暂停具有更广泛影响的决策。
组建联合式团队
组建联合式团队时，需要考虑的范围非常广泛，包括哪些人可用？多长时间？ 我们什么时候需要该系统？ 谁拥有识别和构建我们所需部件的技能？
在过去的几年中我的经验表明，要考虑的因素包括代表性、学科广度、执行者和决策者，是的，这是在重要的尝试中进行的讨厌的投资。
代表重要的平台
在最近与一家小型产品软件公司的合作中，我很高兴看到网站（用于营销和社区参与）和基于Web的应用程序产品之间有足够的UX和设计参与。职责被很好地理解，设计语言和关键组件已经趋于稳定。
我和他们在一起的时间内召集了系统贡献者在紧张的一周实践内讨论细节，并在周末前在全公司范围内发布了该系统。
最令人愉快却出乎意料的结果？证明该系统如何在Windows应用程序上工作，这是该公司的现金牛。一位来自Windows应用程序旗舰团队的受人尊敬的开发人员带来了他的笔记本电脑坐在房间里。几天来，他孜孜不倦地将新的设计语言应用到他的应用程序陈旧的视觉风格中。看到基于真实代码的真实屏幕改变了许多其他持怀疑态度的Windows应用程序开发人员；这些开发人员代表了他们的绝大多数。当然，设计改进是显而易见的。但他们现在相信，在技术上也可以由他们信任的人来完成。
跨学科传播专业知识
系统团队人才的广度应该反映系统的范围。成熟的团队不会对学科的界限抱有虔诚的态度，因此可以使观点和意见充分重叠。尽管如此，一个联合式团队还是利用个人的特定技能来检查：
- 用户体验（和信息架构）的关注点，如导航、流程和任务
- 视觉风格，如颜色、版式和图标
- 特别关注UI模式、动画和动效的交互
这为与外部系统工作有关的人员建立了一条“与之交谈”的路径。但是在内部，这些人在进行协作时始终会模糊这些界限，并鼓励彼此在可能的情况下尽其所能增加价值。
这三人后来被称为怪异的缩略语UVI。大声说出来。听起来很可笑，对吧？出于摆脱真正糟糕的缩略语的动机，我成功地将一位最近聘用的内容策略总监作为第四领导者来提升他们的游戏水平。这是一个稍微更愉快和更恰当的CIVX（用X表示UX）。
混合执行者和主管
一家大型设计组织将主管们（设计师自己，但管理10到30名其他设计师的工作）与工作于旗舰网站和原生产品的设计师们混合在一起。
主管们在他们的团队中接触了各种各样的新设计。当然，他们并不是每天都在生产设计作品。但他们在设计细节上煞费苦心，比如在他们权限之外的产品中，蓝色调的使用使背景变得模糊。
主管还是出色而又闲散的员工的重要提供者，他们可以进行集中的、短时间密集的系统工作。例如，一位核心团队主管让一位设计师花了几天的时间来规范化一组图标。这位摇滚明星一样的图像设计师尽管缺乏对更广泛任务的上下文情境的了解，但还是伸出了援手，使每个人都避免了数周的繁琐迭代，也避免了供应商试图证明自己。
有效的联合式团队将系统决策和行动分配到整个管理层，将决策推迟到有才华的领导者和贡献者身上，同时将影响和决策权交给参与其中的主管及以上人员。
投资于集中记录和交流
风格指南无法凭空自己创建，而且，所有这些（廉价的）文字和（昂贵的）插图、示例以及代码片段都不会神奇地出现在向其他人展示如何做事的网页上。
随着设计系统的稳定，我观察到的每一个团队都有设计师负责构建、记录和维护系统，以及不能或愿意做但不去做的设计师。作为决策——主按钮的颜色、模态框的关闭图标、导航栏的响应——稳定，团队需要弄清楚如何流畅地、持续地传达这种变化。
好的团队对谁记录这些决策以及如何进行沟通有着清晰的认识。这些贡献者（用橙色表示）编写设计指南，用代码构建组件，更新设计工具模板等，以及做更多的事情来保持系统的活力。
高绩效团队会建立平台（例如github.com网站存储库和其他内容发布工具），使一些个人能够持续不断地改进系统的定义。
但遗憾的是有些团队没有这样的平台。更常见的情况是在联合式模式中做出决策的个人并不总是足够的能力来写下它们。
是的，一个联合式的团队需要一个集中的组成部分的工作人员专门致力于这项事业。
领导者为执行者创造了完成工作的空间。他们确保组件库是他们工作的优先责任，或者只是他们工作的一部分。如果没有这项出色的工作，那么这个风格指南可能会在十个月后完全死掉，或者至少失去活力。
自主贡献
一旦系统开始传播，联合式团队就强烈反对排他性。相反，他们拥抱愿意（并且有能力）做出贡献的外围设计师。
这种贡献可以触发一种相互激励：自主。乔恩·威利（Jon Wiley）声称，在Material Design的形成时期，外围设计师越多地参与和接受任务，核心团队就越能容忍和关注不同的想法。
留意那些有着宝贵想法和时间的设计师，他们渴望参与进来。当他们表现出兴趣时，愿意投入时间对他们的探索进行批评和评估，看看他们是否适合。
还有更多的模式吗？
毫无疑问，还有围绕设计系统的集中式决策和联合式决策的其他变体。 你的系统使用的是哪一种？
作者：Nathan Curtis
原文：Team Models for Scaling a Design System