因为是最后一章了所以先来一张作者的照片作为开头

使设计系统经受住时间的考验

人工制品是你在考古挖掘或博物馆中发现的东西，而系统则是活生生的实体。样式指南可以提供文档并作为有用的资源，但是样式指南的简单存在并不能保证基础设计系统的长期成功。设计系统需要不断的维护，支持和贴心的关爱，才能真正蓬勃发展。

再次改变主意

我们又在做什么？

我们认为我们只是设计和构建网站和应用程序。在大多数情况下都是如此。毕竟，这就是客户付钱给我们的事情，而我们创造的产品就是为我们的组织带来金钱和成功的工具。关注最终实现而不是底层系统似乎是很自然的。实时产品仍然是每个人关注的主要焦点，而任何模式库都只是作为分支而存在，仅提供有用的文档。

这种心态的问题在于，你几乎可以看到模式库突然崩溃并万劫不复。模式库一旦停止反映其所服务产品的当前状态，它就会过时。当管理设计系统的模式库不再准确时，网站维护过程将变成少量修补程序和临时更改，从而破坏了创建原始设计系统的所有思想。

为了获得长期成功，我们必须从根本上改变我们实际创造的观念。我们必须认识到设计系统是我们最终产品和模式库的基础，而不是将最终应用程序视为我们的全部责任。

这种“设计系统优先”的心态在维护过程中出现了一些摩擦，并且这种摩擦是友好的。它迫使我们退后一步，考虑任何改进，客户要求，功能添加和迭代如何影响整个系统，而不仅仅是整个生态系统的一小部分。

假设您正在电子商务网站上，并且运行了一项测试，该测试发现“产品详细信息”页面上的自定义样式下拉菜单的性能不如浏览器的默认下拉菜单。一种措施是简单地从该特定页面中删除自定义样式的下拉菜单，并花费了一天。但是，考虑整个设计系统而不是仅仅考虑产品详细信息页面，可能会使您退后一步，并想知道：“如果此自定义下拉菜单在此处效果不佳，也许在其他地方效果不佳。” 进一步研究问题之后，您发现最佳的操作方法是在设计系统中全局修改下拉模式以删除自定义样式。现在，出现下拉菜单的任何地方都将反映这些更改，并且可能会看到类似的性能改进。

这只是设计系统思维如何导致更广泛，更深思熟虑的变化的一个示例。破碎的行为和增强UI的机会通常会在应用程序级别上实现，但是这些更改通常应该在系统级别上执行。在工作流程中添加这种友好的摩擦，可确保改进在整个生态系统中共享，并防止系统因一系列一次性更改而受到侵蚀。

创建可维护的设计系统

当你踏上这一以模式铺平的旅程时，让我们谈谈你可以做些什么来制定一套设计系统，以使你的团队取得长期成功。你如何创建一个扎根并成为团队工作流程必不可少的组成部分的设计系统？你需要注意什么陷阱？你如何确保设计系统产生重大成果？要建立设计系统以获得长期成功，你需要：

• 使其正式。
• 使其适应性强。
• 使其可维护。
• 使其跨学科。
• 使它平易近人。
• 使其可见。
• 加大尺寸。
• 使它与上下文无关。
• 使它与上下文相关。
• 最后实现它。

使其（变得）正式

你最初的样式指南可能是作为副项目，周末黑客马拉松的结果或一个或两个雄心勃勃的团队成员的创意而开始的。正如我们在上一章中讨论的那样，你的客户或老板甚至不必知道你正在创建一个周到的设计系统和随附的模式库。记住：请求宽恕，而不是允许！

有机的开端都是好事，但为了建立一个真正有影响力的设计系统，为你的团队创造长期成功，设计系统需要发展成为正式认可的工作。这意味着将其视为真正的产品而不是简单的附带项目，并因此为它分配实时，预算和人员。

设计系统的制造者和用户

使其适应性强

对设计系统的一个误解是，一旦建立了设计系统，它们就会成为无所不能且不可更改的真理来源。以这种僵化的方式思考是确保设计系统适得其反的肯定方法。如果用户感到束手无策并沉迷于使用无法解决问题的模式，他们会认为设计系统是无用的工具，并开始在其他地方搜索可以更好地满足其需求的东西。

如前所述，开发者和用户之间的频繁沟通和协作是成功管理设计系统的关键。使用户和开发者之间的交流尽可能容易。

设计系统维护的关键部分是确保UI模式保持最新，接受不断发展的设计和开发最佳实践以及继续满足组织的实际需求。

使其可维护

对任何系统来说，最大的生存威胁就是忽视。——Alex Schleifer（爱彼迎）

许多系统陷入失修状态，因为进行更新所需的工作量过高。如果更新模式，文档和应用程序既困难又耗时，人们最终会感到沮丧，以至于他们停止努力，而设计系统将开始被遗忘。对UI模式，文档和应用程序进行更新时应尽可能避免摩擦，因此减少这种摩擦应成为设计系统团队的当务之急。这需要从技术和工作流程的角度进行仔细考虑。

寻找圣杯

设计系统的圣杯涉及创建一个环境，其中模式库和实时应用程序完美同步。这个想法是，你应该能够对UI模式进行更改，并看到该更改自动反映在模式库和生产中包含模式的任何位置。

设计系统的圣杯是一个环境，其中对UI模式进行更改会同时更新模式库和生产应用程序。

该技术消除了任何重复劳动，并确保了模式库和使用模式的应用程序保持同步。

事实证明，这个梦想可以成为现实。旅行指南公司Lonely Planet是最早建立称为Rizzo的圣杯设计系统的公司之一。通过一些智能架构，他们为自己的UI模式创建了一个API，该API可以馈送到其生产环境以及其模式库中。结果是一个集中的设计系统，可确保其实时应用程序和文档保持完美同步。

使其跨学科（部门）

样式指南经常直接跳入代码段和模式使用中，以使设计系统用户受益。当然，模式库需要对实际使用模式的人员有所帮助，但是仅将样式指南视为开发人员资源会限制其潜力。

样式指南有机会为整个团队（公司）进行服务，帮助为公司数字产品的成功投入的每个学科建立共同的语言。建立此共同语言可以导致整个公司中各小组，部门之间更有效率的工作，更好的沟通和更多的协作。这就是为什么样式指南应该成为每个人的指南，而不仅仅是设计系统用户。

从组织的角度来看，此组件非常复杂。电子商务网站上的首页轮播需要公司中许多部门的投入。企业所有者和编辑人员必须选择要在轮播中展示的产品。撰稿人必须确保副本有效，并且不受设计约束。艺术总监需要确保美观的设计令人愉悦，并且产品摄影在每个屏幕尺寸上都清晰可见。用户体验设计师必须确认功能和控件是否直观。前端人员必须确保该组件具有响应能力，可访问性和性能。后端开发人员需要确保组件正确连接到后端系统。你明白了吧。

精心设计的样式指南可以帮助管理所有这些运动部件，并确保影响每种样式的许多角度都正确记录在样式指南中。使模式库对每个部门，小组都可用，并考虑如何简化它，并邀请不同角色的人员来为文档做贡献。

使其平易近人

让人趋向于吸引人的事物，这应该让人感到惊讶。使样式指南成为跨部门资源的重要部分是确保用于存放模式库和其他文档的容器美观，引人入胜且易于浏览。

创建一个有用的设计系统应该是团队的首要任务。建造一个漂亮的网站来容纳所有一切可能不会一蹴而就，但是一旦设计系统正式发布，它应该成为当务之急。制作美观的样式指南不仅是为了设计而设计；它反映了组织对制定和维护周到，深思熟虑的设计系统的承诺。

使其可见

沟通变化

一旦设计系统投入使用并在实际应用中使用，就必须将变更，更新和持续的愿景传达给整个组织。（译注：如更改日志，路线图，成功案例，提示和技巧，这些现代ui库已经有一套成熟的流程，所以后文的一些内容就省略了）

变得更大

一个可见的，跨工种岗位的，可访问的模式库是你的团队将一次又一次推出的库。利用这个优势。由于团队的眼球已经固定在这一资源上，因此有很大的机会将其扩展到包括其他有用的文档，例如我们在第1章中讨论过的语音和语调，品牌，代码，设计原则和编写准则。

扩展模式库功能的另一种方法是将本机平台模式的准则与基于Web的模式一起包括在内。我们可以再次参考Intuit的Harmony设计系统，以获取iOS和Android原生移动平台模式如何与基于Web的同行一起生活的示例。

Intuit的Harmony模式库包含用于在每种模式的Web，iOS和Android之间切换的按钮。这样一来，团队就可以跨平台维护一个几乎一致的设计系统，而且还可以在发生模式差异时记录它们。

使它与上下文无关

因为我们倾向于在更广阔的页面范围内建立UI模式，所以根据组件的居住位置来命名它们很诱人。但是，你无需将其命名为“首页轮播”，而只需将其命名为“轮播”，这意味着你现在可以将轮播放到任何地方！

命名显示模式的另一个挑战是，我们倾向于对它们内部的内容模式分心。例如，如果在电子商务站点上工作，你可能会想调用一个包含产品图片并标题为“产品卡”的块。但是以这种方式命名事物会立即限制其中可以容纳的内容类型。通过简单地将模式命名为“卡片”，你可以在其中放置各种内容模式：产品，促销，商店位置等。

尽管命名始终是一个挑战，但与上下文和内容无关的模式名称将更加可移植，可重用和通用。

使它与上下文相关

在模式库中展示UI模式很好，但是你需要向设计系统用户演示上下文，以了解如何以及在何处正确使用它们。大多数模式库都展示了每个UI模式的演示，但是正如我们已经讨论的那样，这些模式并不是存在于真空中的。这些模式到底在哪里使用？

演示上下文的一种方法可能包括显示正在运行的组件的屏幕截图或视频。Material Design的文档在这方面做得很棒。每个组件均包含照片，视频和用法详细信息，以使用户清楚地了解这些图案在应用程序上下文中的外观，并演示应如何使用每个图案。

最后实现它

制作设计系统是一项非常重要的工作。但是，如果没有适当的维护，设计系统的价值将贬值，就像汽车刚从经销商手中撤出一样。取而代之的是，你的设计系统应该像一瓶随时间增加的优质葡萄酒。

正如我们在本章中讨论的那样，使你的设计系统经受时间的考验需要大量的时间和精力。但是，所有生物不都使这样吗？动物需要吃饭，植物需要水和阳光才能生存。创建一个活泼的设计系统意味着给予关注和照顾，以使其继续蓬勃发展。

写在最后

我们的任务是使大量产品，站点和应用程序正常工作，并在令人眼花缭乱的各种设备，屏幕尺寸，外形尺寸和环境中保持美观。我希望本书所涵盖的概念能为你勇敢地应对日益多样化的数字环境提供坚实的基础。通过创建设计系统，认真设计用户界面的方式，建立协作和模式驱动的工作流，以及建立成功维护设计系统的流程，希望你和你的团队共同创造美好的事物。Go forth and be atomic!
（完）

小结：本章讲述的内容其实可以称为是一个ui库开发的参考指南或者教科书，当然我们开发自己的组件/插件的时候也可以参考它。从表现的结果来看，当前的流行ui库也基本都是这样的开发模式，因为有了react/vue这样的组件化开发模式，导致文中提到的圣杯设计系统实现起来也变得容易了许多，只要不涉及到传入的参数改变，组件中的样式改变是不会影响到使用者的，使用者所需要做的只需要升级插件版本即可。

又及：全篇整个看下来对我影响最大的有两点，一个是划分页面的方式——原子，分子，组织，模板。我们不必完全生搬硬套，但是这种思想给我的开发提供了很大的参考。第二个是书中提到了一些设计相关的思想，我觉得作为一个前端应该在代码之余也需要多多学习。

再及：感谢谷歌翻译和百度翻译提供的技术支持......在翻译完前面很小一部分内容之后我发现我的翻译水平在很多时候还比不上机翻。以后有机会的话，我可能最多也只会选择一些短小精悍的文章翻译一下了。

译文目录在这里： https://www.jianshu.com/nb/47456777