我们之间的设计体系

几个月前，我写过一篇文章，谈到早期的倡导如何承诺设计系统将改善我们产品的一致性，以及这个承诺如何从未真正实现。最近，我一直在思考早期谈话中的另一件事：即设计系统将引入新的、更具协作性的工作方式。

这是Airbnb设计团队在2016年发布的一篇帖子，他们在帖子中描述了他们的设计系统如何帮助改善设计师和工程师之间的合作：

设计师和工程师之间的差距只会越来越大。设计团队往往很难达到平衡创作过程和持续创新周期的节奏。质量受到影响，体验变得不那么有凝聚力，有才华的人仅仅是在管理跨学科的沟通上就花费了过多的时间。

您可能对Airbnb描述的流程非常熟悉。设计师可能会在Sketch或Photoshop等设计应用程序中“模拟”新功能，然后将这些设计交给工程师来实现。有两个规程，每个规程都有自己的工作空间：面向设计人员的布局应用程序；面向工程师的代码应用程序。

…。我们将代码作为一种设计工具进行投资。更接近于使用不仅包括布局和设计，还包括逻辑和数据的资产。这有助于弥合工程师和设计师之间的差距，从而减少对设计规格或红线的需求，以及愿景和现实之间的步骤。

换句话说，Airbnb构建了一套社交工具，每个工具都融合了他们设计系统中的生活模式。设计师可以将实时数据和内容放入他们的原型中；工程师可以更直接地参与早期的设计探索。这些工具让设计师和工程师可以有效地并排坐在一起，并在设计系统中快速地从活的图案中组装新的概念。根据Airbnb的说法，这种协作基础设施将设计和工程更紧密地联系在一起。

我认为这是一篇很棒的文章，甚至是一个更好的案例研究。更重要的是，它代表了当时的许多主张：一种论点，即设计系统将使设计师和工程师能够更紧密、更有效地合作。

但根据我的经验，设计系统并没有给大多数组织带来这种丰富的、跨职能的协作。相反，设计和实现之间的现有分歧已经变得根深蒂固，而且很大程度上是如此。

现在，这种竖井并不是因为设计系统--不是真的。我可以想出几个导致目前状况的因素，我将依次介绍每一个因素。

首先，令人惊讶的是，几乎没有现成的技术对将设计和工程更紧密地联系在一起感兴趣。现在，这并不是说协作完全没有改善：像gihub或glitch这样的平台让工程环境变得更加社交化和协作化；像Figma和Abstract这样的实用程序在设计方面也做了同样的事情。换句话说，设计应用程序使设计人员更容易协作；开发应用程序使开发人员更容易协作。

但自从Airbnb发布帖子以来，已经有四年多的时间了。在这段时间里，每个学科的工作空间之间的差距没有明显的变化。也许你的团队会从Airbnb的AirShots工具中受益，它允许用户在不同的设备或语言集上快速预览数千种模式排列。遗憾的是，像它这样的产品很少。更重要的是，很少有产品专注于设计和实现之间的空间-将设计工作空间和工程工作空间更紧密地联系在一起。这意味着，如果您的组织想要缩小这一差距，您将不得不承担相当数量的定制开发工作。

当然，有一些工具可以帮助实现这一点。Figma的API提供了对ART文件中定义的值的读取访问，这可以更紧密地将设计决策集成到生产代码中-例如，通过编程从Figma文件中提取设计令牌。但这些只是拼图的一部分，而不是最终的解决方案。因此，对于许多承担系统工作的组织来说，构建自定义工作流基础设施的成本可能高得令人望而却步。

在过去的几年里，我们的行业见证了围绕前端工程的复杂性的爆炸式增长。设计系统的流行与单页面应用程序模式的兴起以及ANGLE、VUE和Reaction等JavaScript框架的发展相吻合。正如Dave Rupert等人指出的那样，这些框架不是在真空中存在的：每个框架都是软件库和构建环境的生态系统，每个都需要大量的领域专业知识。

我只想强调一点：这些框架可以为使用它们的组织提供真实、切实的好处。我不是在这里暗示那些好处不存在，也不是在这里批评框架本身。(我不够资格，不太合格，像汤姆·麦克赖特(Tom MacWright)和蒂姆·卡德里克(Tim Kadlec)这样的人写的文章比我写的要好得多。)。但很少讨论的是这种复杂性带来的社会和组织成本。

当开始一个项目时，我经常会问一个新客户，一个非工程师会如何改变他们的产品设计。例如，如果设计人员想要更新一行CSS，工程师需要为他们实现吗？如果设计者可以自己完成，他们需要安装哪些技术？他们需要学习哪些成分结构或句法？他们的工作将如何审查，由谁审查？设计人员可以自己部署更改吗？

我问这些问题并不是为了建议设计师应该能够直接更新设计。脚注1相反，它们有助于评估产品技术架构中内置的协作摩擦的数量。换句话说：您的技术堆栈在允许谁为前端做贡献方面做出了什么样的决定？改变这些决定，引入一种不同的工作方式，代价会有多高？对于许多组织来说，跨职能协作的技术障碍可能高得令人无法接受。更重要的是，这种复杂性的代价很少被承认。

现代数字团队很少就其产生的协作成本来讨论决策。孤立地看待与设计或工程相关的决策是很诱人的，也是很自然的：选择Vue作为前端框架只会影响工程团队，或者迁移到Figma只会影响设计人员。但是其中的每一个都会改变团队的工作方式，从而影响其他团队的工作方式和与他们协作的方式。

是啊，我知道这听起来有点明显。但我们通常倾向于认为设计系统有别于组织的更广泛的结构，事实并非如此。通常情况下，您的设计系统会成为团队工作方式的一面镜子。如果您想重新思考您的团队的工作方式，不能将其视为您采用设计系统时就会发生的事情。改善协作需要在一开始就是一个明确的目标，并就如何实现这一目标提出明确的建议。在整个过程中做出的每一个决定都需要对照这个目标进行衡量。脚注2。

…。制作工件、可交付成果--是的，还有模式--的工作才是价值所在，而不是工件本身。

正如Alla Kholmatova在她的书“设计系统”中所说，设计系统是“一组相互关联的模式和共享的实践”。设计系统的工作远不止模式库：它是您的组织使用这些模式的方式。当您开始定义您的设计系统时，有必要对您的团队的工作方式以及设计系统如何支持更好的工作方式进行一次艰苦的、深思熟虑的讨论。

去年，我和利维亚·拉巴特一起在Vox Media工作，看到他们在一些与设计系统相关的大型活动中将这一点付诸实施。不用说，利维亚的工作对我在这里的想法产生了巨大的影响。(↩)。

我现在可以雇佣。这是我做过的一些工作。如果你想和我谈谈你即将进行的项目，请随时与我联系。