解密设计系统的 11 大优点，终于可以说服你的管理层

三分设

上海/UX设计师/4年前/655浏览

版权

三分设

设计系统是一个不断进化的动态体系，它需要迭代和适配，因此你还是需要设计师和研发工程师。

在互联网行业从业多年，见证了许多世界顶级公司例如 IBM、苹果、 Adobe 等都通过构建设计系统创造了极致的用户体验给企业带来数以亿计的增长。在当下，随着原子设计方法论等设计原则的出现，设计系统也变得越来越主流。其实到现在还是有很多公司因为不了解设计系统，更别提从中获得巨大的助力和价值，作为用户体验设计师有必要告诉你的 BOSS，那如何向别人说明构建设计系统的优点呢？，那么这篇文章告诉大家答案。

设计系统的优势

在这里，我和大家谈一谈我在使用设计系统的过程中，所遇到那些显而易见的好处以及那些还不怎么让人关注的价值。在此之前，如果你认为只要拥有了设计系统，你就可以开掉所有的设计师，那就大错特错了。设计系统是一个不断进化的动态体系，它需要迭代和适配，因此你还是需要设计师和研发工程师。

设计系统对业务目标、工作流程和员工幸福感都有积极的影响，而且有助于为客户和员工塑造品牌体验。集合所有的优点我们大致可以分为四大类：可扩展性、效率&质量、文档管理以及品牌&文化。

如果你在团队里试图想说服你的顽固派老板，“搭建设计系统并不是在浪费钱”，那么了解以下这些设计系统的优点，应该会对你说服老板非常有帮助。或者你也可以告诉你的设计师们，不要过于紧张，设计系统并不会取代他们工作中的创造性的部分。

可扩展性

绝大多数的公司在扩大产品规模的时候，都会遇到相类似的问题。其中最为主要的问题常常出现在开发和维护环节中，资源投入往往呈现出非线性的增长趋势。换言之，我们在增加更多功能和产品线的时候，伴随着成倍地增加复杂性。这意味着你需要额外的人手去调整所有的产品的用户体细节。恰巧的是，设计系统可以帮助解决这个问题。

1. 扩大团队的规模

设计系统可以让你的团队在打造更多的产品功能时，无需指数级的增配团队成员。其原因是就是通过团队中心化的设计执行和体验决策以及标准化流程的工作模式。

每当多个团队一起参与到更多功能、更大体量的产品设计项目时，我发现，更多的问题往往不在于技术层面，而多半在于人。

只要扩大团队规模，组织结构往往是主要的问题根源。处在一个不断壮大的团队中，是不可能和每一位设计师或者研发工程师保持信息随时同步，换言之，你会很容易忘记他们在做什么，以及产品设计进度等等。把控所有项目和调配人员反而成为一项非常艰巨的任务，很多老板也就不得不增配人手来做这一件事情。即便如此，也很难保证所设计的产品在交互模式、视觉风格等方面符合常规的质量标准。最终，我们发现总是得到一套杂七杂八的山寨产品，往往所有组件会以不同的方式被重建——搞的一团糟糕。

一个最基础的设计系统应该包含团队里每个人都需要使用的通用设计和代码集合，它就像一个风格指南，通过使用组件集（如按钮或卡片等）作为设计和代码资源。它是一个基于中心化决策的积木式模块化框架。

设计师就可以专注于流程和解决具体的问题，而不是拘泥在一个按钮样子。对于色彩、对比度、形状等设计都应该在设计系统中被统一决策。设计系统应该由一个专门的团队来进行维护和管理。在这种方式下，在业务团队扩大规模时，还能保证产品的高质量和一致性。代码层也是如此，例如反馈组件，因为代码组件都是可以被即时调用。

2. 可维护性和持续改进

设计系统的集中性使维护产品变得更加容易，设计系统中的修正和改进是可以立即同步到所有的产品。

我们都知道在产品迭代过程中，来自于各种各样的原因，产品的用户界面（UI）样式经常会有所改动。也许是我们在做完 A/B 测试之后，希望可以改善产品的可访问性（无障碍设计）或者提高转化率等等。也许随着企业战略升级而引导品牌升级，或是某个操作系统的更新。

通常业务逻辑的变化往往只限于单个产品。如果其中运用到的某个常规组件需要更新，其实会涉及到所有的产品。如果我们一一去做修正，就会特别耗费时间。如果不是所有的团队立即同步执行修正，那么也就产生了产品的不一致。

将用户界面（UI）外部化到中心化的设计系统里可以大大减少以上问题。设计令牌（design token）和组件集（components）之间的组合模式可以让产品更新变得非常的容易。在最为理想的情况下，我们只需要更新一个元素组件，那么所有产品将会随之自动更新。我们将基本的用户界面（UI）设计和研发决策外部化给第三方（系统/工具/平台），这意味着我们业务型产品团队将少了一件需要担心的事情。

效率和质量

从长远来看，设计系统能始终提高产品设计研发的效率、质量和一致性。我咨询过许多大厂产品设计团队，他们一致反馈，这就是使用设计系统的主要原因。一致性和质量对产品形象和用户体验有着巨大的影响。有一个良好的第一印象是可以让用户（客户）选择我们的产品，而非选择其他。提高产品的研发速度，这意味着，我们可以招募更少的成员就能完成更多的事情，同时也可以更快的交付（发布）。这一点对于公司而言至关重要，很好的起到降本增效作用，尤其是在大型团队更需要控制成本和支出。

3. 生产力——效率和成本改进

生产力的提高意味着更少的人可以在同样的时间内做出更多的东西。这很好的降低了设计研发成本，并且让我们可以迅速将新的功能推向市场。设计系统在提高团队的生产力这方面提供了一个巨大的作弊手段。

设计系统的主要生产力提升来自于跨产品设计、研发决策的标准化，以及将这些决策的管理外部化给一个中央团队（类似于中台部门/体验管理部门）。

产品团队只使用系统所提供的设计令牌（design token）和组件集（components ）。对于用户体验设计师而言，这意味着我们可以更专注于战略层的问题，而不是拘泥于一个按钮的外观样式。同时对于研发工程师而言，将设计稿件转化为代码（D2C）就变得更加容易了，因为大部分的接口都是用现有的组件构建的。研发工程师也就可以专注于业务逻辑和极少数量需要定制化的界面样式。

这样以来，我们为 A/B 测试构建的新功能或者更新迭代的流程就变得即快速有省钱了。因此，许多产品团队转而采用测试和数据驱动的设计模式。现在的设计策略已经不仅仅只是凭借设计者的第七感，而是通过定量数据的验证反馈。

4. 代码和设计质量

设计系统就像一款产品一样，需要有一个专属团队，团队内所有的设计师和研发工程师专注于打造一款人人都在用的设计系统，这样可以保证这款设计系统拥有最高的质量。

构建一款高质量设计系统的秘诀就是像构建一款产品一样，你需要一个全职的、敬业的团队，包括设计师、研发工程师和产品负责人。

如果一个组件，例如滑块，作为一款产品，不仅仅是需要满足基本功能，我们是还需要花更多的时间在细节上。我们需要考虑所有的极端情况，根据用户体验进行优化迭代。研发工程师是需要确保这个组件是可访问的，可自定义的，并且具备大量的测试覆盖率。

除此之外，设计系统是会被所有的产品团队所使用。这意味着我们同事（包括设计师和研发工程师）会持续不断的测试（实践），有一些设计师擅长无障碍设计，有一些则具备优秀的排版经验。通过不断使用设计系统，这些设计师们都会给予评估和决策。如果出现什么问题，他们就会告诉我们。因为我们拥有一个探寻真理的团队文化。

5. 一致性

一致性能够提高视觉的质量，让使用我们的产品变得更加容易。这是因为在我们的所有产品中都使用了相同的交互模式和视觉语言。设计系统定义和标准化模式，使所有的产品团队都能保持一致。

每当用户打开我们的应用程序（APP）时，就和我们公司进行了一次互动。虽然不同的应用程序（APP）或者应用程序（APP）中的不同功能是由我们公司不同团队所构建的，然而这一点对用户而言，显而易见的并不重要。因为用户只希望它们都能够常规操作，甚至可能期望它们与手机上的其他应用程序（APP）一样操作。一旦她对你的应用程序（APP）中的一个按钮建立了认知，她就会下意识地寻找这个元素。正因为如此，重复使用相同的组件可以减少用户的认知负担。这恰恰也能带来更好的用户转化以及更好的体验，从而让用户选择我们应用程序（APP）而不是那些竞品。

在产品团队中，一致性使得互相承接工作变得更加容易，当每一位研发工程师写代码都有共同的模式的时候，岗位的空缺就会更容易被填补。

产品文档

产品文档是设计系统中最重要的部分之一。好的产品文档可以确保设计系统得到同事们理解和使用，同时也能让新人快速学习这个系统，并且传递公司的文化和价值观。

6. 知识共享

设计系统，顾名思义，就是我们公司用来设计和构建产品的系统。它包括正确的解决方案（通过正确方式解决问题的工具、方法和思维方式）

如果设计系统是一款产品，那么文档就是这款产品的前台。每当有其他人员加入项目中，是不需要额外的文件。这也是使用系统的第一个触点，并决定了产品的预期质量。

设计系统的文档之所以特别，是因为其目标用户是既定的。我们很清楚地知道受众是谁，以及他们为什么会看。这意味着我们可以很轻松地根据需求将用户引向特定的部分。你可以有一个"基础入门"部分、令牌（token）和组件库（components）"以及"产品路线图和发布"的页面。

当把内容分为"设计"和"实施"时，我们的受众会变得更加精确。这样一来，我们可以轻松的分享具体的知识和准则。设计师们从中可以了解品牌、视觉可访问性和通用交互实践；研发工程师可以了解程序的可访问性、代码风格和测试的方法。正如你所看到的，文档不只是工作指南，还是一个分享和塑造公司文化和工作方式的工具。

当我们拥有一款较为成熟的设计系统，我们就想得更远更大。增加一个博客，分享同事们成功使用该系统的故事和案例。让文档成为一个建议功能或以不同方式共创的地方。

7. 避免巴士因子

巴士因子是一个令人毛骨悚然的名词，指的是由于团队内某个成员失踪而导致知识丢失（遇到问题无法解决）的风险。往往出现这种问题，你的同事不一定是被巴士撞了。或许他生病了，或许他申请了休假，也有可能是加入了另一家公司。那么面对这种情况你准备好应对策略了吗？

拥有一款配置良好的设计系统，前期应该做好准备。主要是因为需要我们将其进行标准化。

一方面，对位置和内容进行标准化：所有与用户界面（UI）有关的知识都在设计系统中共享。从可访问性、颜色和排版到界面测试等的任何相关参数，都在这里面定义，而且只能在这里定义。这很重要，因为如果它不在设计系统的文档中，那它就不存在。

另一方面，对方法（如何使用）进行标准化：命名、组件使用、方法论和代码风格等，一切都在这里定义。

这两个方面加起来，也就可以让其他人更加容易快速参与到我们的项目当中。有了共同的"Where"、"What"和"How"，哪怕你的团队中的一个关键成员去度假，似乎也没那么可怕了。

品牌和文化

8. 缩小品牌——产品的差距

产品团队仅使用传统的视觉规范来构建/指导一款应用程序（APP），最终的呈现出来的结果往往是不一致的。品牌个性往往会在转化中“丢失”，让一个团队将品牌转化成界面元素就可以就解决这个问题。

从品牌理念出发创建一个用户界面（UI）组件库是很棘手的。一方面，需要牢记那些富有表现力的品牌演绎；另一方面，必须考虑可访问性（无障碍设计）和多端设备。这是一项繁琐的工作，而且需要进行大量的测试和调整。多亏有了设计系统，这些都由一个团队来完成。其他协同人员可以毫无疑虑的使用设计系统的成果——令牌（tokens）和组件集（components），而且完全不必担心品牌视觉识别方面的问题。

一个独立的设计系统团队还有一个优势：由于没有被束缚在一个特定的平台上，他们对所有可能触及的平台有一个更宏观的把控。在实验中，他们能够了解到同样的内容是如何在网页端、移动端等多平台上切换的。简而言之，一个精心制作的设计系统保证了品牌个性存在于所有的产品中。

9. 统一设计理念&原则

设计系统远不止是颜色和组件库。它可以让我们分享和解释我们设计师背后的理念和原则。可以说是一本关于如何在产品体系中进行设计实践指南。

虽然设计系统提供了大量的组件和选择项，但它永远无法涵盖所有的情况。这时设计师必须想出独特的解决方案。这可能是某个业务的特定问题，也可能是一个需要特别有吸引力的仪表盘（Dashboard）。即使他们的解决方案是定制化的，也必须符合我们公司的设计。这就是需要我们的设计师参考设计理念和原则。

设计理念描述了“内容（What）”和“原因（Why）”。例如，一个设计理念可能是"通过设计解决问题以吸引更多的用户"；而另一个理念可能是"通过设计使任务变得愉快和有价值"。设计原则与这些理念相关联，并解释了“方法（How）” 。例如，"我们专注于可访问性，为每一个用户提供卓越体验"。这可能是第一个理念的一个方面。"用有趣的动效来表达状态的变化 "这可能是符合第二种理念的某个原则之一。

在学习了设计理念和原则之后，将更容易理解设计系统中的令牌（tokens）和组件集（components）的设计决策。这也可以使我们的设计师能够自己设计出符合设计系统的自定义元素。

特别是当开始一个设计系统时，只能涵盖最为常见的用例。这意味着你要依靠产品设计师设计并定义他们自己的组件。在这种情况下，我们需要清楚地传达设计系统背后的内容（What）、原因（Why）和方法（How），这是非常重要的。

10. 共享所有

在团队中，沿用品牌来进行设计，常见的问题就是设计师感觉缺少把控权，然而设计系统可以让每个人都有主人翁的感觉。

产品团队往往都不怎么关心品牌类的问题。高层管理人员可能在几年前和咨询机构一起决定了品牌视觉系统。他们甚至懒得咨询那些每天专业从事品牌设计的相关人员。设计语言还停留在主要是为印刷品而构建的，颜色也没有经过屏幕的可访问性测试。

让整个设计团队参与品牌重塑真的非常困难，尤其是在大公司里面。相比之下，鼓励每个人对设计系统作出贡献是相当容易的，而且我们通过很多方式来做到这一点：

在设计系统的主页上提到"欢迎贡献"。
在组件（component）、令牌（token）和其他内容的页面上添加"发送 PR"、"提供反馈"或"说说新点子"等类似进行协作（CTA）的短语。发放调查问卷，征求反馈意见。
直接接触那些我们觉得做出贡献的人。
支持那些试图做出贡献的人。
在我们的博客、通讯等地方分享关于贡献的成功故事。
在我们的发布说明中提到贡献者。
组织内部的"见面会"，介绍系统更新，收集反馈并让用户参与进来。

让用户参与到我们的设计系统中来有很多的好处：

最重要的是，它可以帮助我们得到团队的认同。他们（理所当然地）感觉到这是他们的设计系统，并慢慢地从使用者变成拥护者。
建立设计系统是需要做很多工作。如果能从其他设计师和研发工程师那里得到帮助，这是一件好事。通常他们原本也是需要构建设计和开发组件的，我们往往只需要一点额外的努力就可以让他们适应设计系统。
同事的反馈意味着你可以在被客户发现之前就修复错误或是改进功能。

总而言之，其他成员的贡献对于设计系统的落地、提升开发速度和整体质量都是非常有利的。