原子设计第五章：维护设计系统
作者：Brad Frost 翻译：megan、maker 校对：megan、maker
其它章节
他们做了一个设计系统，交付了风格指南（style guide），并且从此过上幸福生活。对吗？
不完全是哦...
有一个非常现实的风险，那就是风格指南（style guide）以及设计过程中的PSD、PDF、各种组件等等都会最终躺在垃圾桶里。尽管每个人的意图都是最好的，为建立一个考虑周全的设计系统和风格指南（style guide）所付出的所有时间和精力依然可能直接付诸东流。
怎么会这样？
风格指南（style guide）是设计过程中的产出物。设计系统是个拥有线路图和待办事项的有生命的和被资助的产品，它服务于某个生态系统。——内森·柯蒂斯
产出物是你在一个考古挖掘过程或在博物馆中会发现的某种东西，而系统是一个活生生的实体。 风格指南（style guide）可以提供文档并且作为一个有用的资源，但风格指南（style guide）的简单存在并不能保证底层设计系统的长期成功。设计系统需要对它持续的维护，支持和温柔呵护以真正茁壮成长。
# 再次改变思维
我们已经讨论了重新设定大家期望以建立一个更具协作性的和模式驱动的工作流程的重要性。为了从垃圾桶的肠子里拯救我们的风格指南，我们必须再次从根本上重新打开人们的大脑。
# 我们再一次做的是什么？
我们认为我们只是设计和建设网站和应用。这在大多数情况下的确如此。毕竟，这就是我们的客户付钱让我们做的事情，我们创造出的产品是为我们的组织产生金钱和成功的车辆。更关注最终实现而不是底层系统这件事看起来很自然。存在的产品持续成为大家关注的主要焦点，而任何模式库还存在着仅仅提供有用文档的分支。
有这种心态的问题是，你几乎可以看到模式库被折断并滑向深渊。一旦模式库（pattern library）不再反映其所服务的产品当前的状态，它就变得过时。 而当管理设计系统的模式库（pattern library）不再准确时，网站的维护过程就下落为一塌糊涂的修补和临时变更，破坏了所有创造原始设计系统时的周全考虑。
为长期成功做打算，我们必须从根本上对我们实际上在创造的东西转变愿景。我们必须认识到设计系统是支撑我们的最终产品和模式库（pattern library）的东西，有关最终应用的思考不仅仅是我们唯一的责任。
这种“设计系统第一”的心态在维护过程中加入了一点阻力， 并且那个阻力可以很友好。它迫使我们退后一步考虑任何的改进，客户的请求，功能的增加和迭代会怎样影响整个系统，而不是仅仅影响整个生态系统的一小部分。
假设你基于一个电子商务网站运行一个测试，发现产品详细页面中的自定义风格的下拉菜单并不像浏览器的默认下拉菜单那样好用。一个显然的行动是简单地将特定页面自定义风格的下拉菜单删除并收工。但考虑到整个设计系统，而不仅仅是产品详细信息页面可能会导致你后退一步并怀疑，“如果这个自定义下拉菜单在这里效果不好，也许它在别的地方效果也不会好。”这个问题更进一步后，你会发现最好的行动当然是在设计系统内全体修改下拉列表模式以删除自定义样式。现在，任何出现下拉模式的地方都会反应这些变化并将有相似的性能改进。
这只是设计系统思考如何导致更广泛，更深思熟虑的改变的一个例子。可以提高用户界面的破碎的行为和机会往往会在应用层实现，但这些变化要经常在系统层采取行动。 将这种友好的阻力加入您的工作流程，确保整个生态系统共享改进，并防止系统被一系列的一次性变动蚕食。
# 完结与完成
我们必须重新审视的另一个期望是我们对于完成的定义。为印刷和其他物理介质创造出的东西需要做出永久的，有形的物体。这个完结的意义并不存在于数字世界中，它意味着相比其他的介质，发生改变将花费更少的精力和阻力。客户，同事和利益相关者应该拥抱数字世界的柔韧性以创造可适应媒介、用户需求和业务需求的不断变化的性质的并有生命力的设计系统 。
这种思维的转变从根本上影响我们的工作范围。在乙方工作的人习惯于以压缩文件包的方式交付一个项目，然后就结束一天的工作。内部团队也没有做的好太多，因为他们倾向于从一种可能性浮动到另外一种。无论你是内部团队的一员还是外包的雇佣方式，我猜你已经体验了基于项目工作的缺点。我们倾向于谈论永远不会到来的未来，而我们设置它，又遗忘它，然后继续前进到下一个闪亮的项目。
如果我们致力于创造真正满足我们的客户和机构的需求的有用的工作，我们必须从根本上重新定义我们的工作范围。正如Nathan Curtis所说，一个设计系统不应该是个有限范围内的项目 ，而应该意味着一个随时间推移成长着并进化着的产品：
着眼于交付风格指南作为高潮是错误的方式。设计系统不是一个会结束的项目，而是一个会服务其他产品的有生命力和不断发展的产品的起源故事。——Nathan Curtis
网站是永远做不完的，系统设计的建立仅仅是万里远征的第一步（希望是卓有成效的！）。一个设计系统应该是个以改革你组织创建数码工作的方式为宏伟目标的长期承诺。很令人兴奋，是吧？那么，我们如何确保这种事情可以发生？
# 创建可维护的设计系统
当你踏上这个由模式铺成的旅程，让我们来谈谈你为制作一个可使你的组织获得长期成功的设计系统可以做的事情。如何创建一个设计系统，使它可落地并成为你的组织的工作流程中必不可少的一部分？你需要警惕怎样的陷阱？你如何保证设计体系产出大的效果？要建立长期成功的设计系统，你需要：
- 使其官方认可。
- 使其有适应性。
- 使其易于维护。
- 使其跨学科。
- 使其平易近人。
- 使其可见。
- 使其更大。
- 使其上下文无关。
- 使其情境化。
- 使其可持续。
让我们更详细地深入到每个点。
# 使其官方认可
你最初的风格指南可以是一个辅助项目，一个周末黑客马拉松的结果，或者作为一个或两个雄心勃勃的团队成员的心血结晶。正如我们在前面的章节中讨论的那样，你的客户或者老板甚至不必知道你正在创建一个考虑周全的的设计体系和相应的模式库。记住：请求原谅，而不是请求许可！
逐步的开始是好的，但是为了为您的组织建立一个真正有影响力的能够长期成功的设计系统，设计系统需要努力通过官方认可的方式发展。这意味着将它视作是一个真正的产品，而不是一个简单的辅助项目，于是相应地分配时间，预算和人员。
说服利益相关者承诺投入大量资金，时间和资源在一个设计系统上可以说是件非常具有挑战性的事情。那我们该怎么办？我的建议是：
- 把东西做出来。
- 表明它是有帮助的。
- 使官方认可。
让我们来更细化一下这些步骤。
# 1：把东西做出来
你必须从某个地方开始，有一些事情可以起步总比没有要好。选择一个会成为建立你的设计系统过程中的一个伟大的试点项目，遵循类似第4章中讨论过的过程；想想第2章中详述的原子设计心智模型 ；最终你会为帮助你的团队更有效地合作而设计出一个考虑周全的系统和模式库。
抽时间打包一个模式库中的UI模式，并准备推销出去。我已经和几个在一个周末课程的过程中建立了自己的模式库的要旨的雄心勃勃的团队成员谈过了话。这方面的努力有所作为，因为它提供了有形的东西可以给到利益相关者以作出反馈。还是那句话： 展示，不要讲述。
# 2：表明它是有帮助的
有了一个新生的尚未明确的设计系统，你可以同控制金钱，计划和资源的人更有意义地对话。您可以讨论设计系统如何帮助节省时间和金钱（参见第4章中的“ 推销模式”），然后描述一幅蓝图：如果组织投资于这样一个正式全面的设计系统的话，这些好处将如何进一步扩大。
从不同学科背景的团队成员那里获得支持并讨论系统的初步成功，并且拉入其他关心从一个扩展的设计系统里获益原因的人。
# 3：使官方认可
你已经证明了你最初的设计系统的价值，并提出了如何使其更好的路线图。如果幸运的话你的组织将致力于使系统设计成为官方的事情。
最高层批准后，你现在能够把计划付诸相关行动：分配或雇人来设计系统；制定一项计划，以使其更加坚固；制定明确的治理战略；并编制产品路线图。
值得指出的是，事情可能不按你所希望的方式发展。尽管表现出真正的价值，并提出具体的行动计划，上级仍可毙掉你的倡议。不要气馁。 虽然你可能已经输掉了这次战斗，但你肯定可以赢得战争。无论程度如何你的团队都应该继续增长和扩大设计系统直到它的价值成为不可否认的事实。随着越来越多的人从系统中获益，你将看到一个从基层支持的系统可以通过推动努力起到帮助作用。
# 建立设计系统团队
在设计系统的倡议被批准后，是时候把合适的人员和流程引入到系统中以确保设计系统能够在组织内生根发芽。
# 设计系统的设计者和用户
先说最重要的事情吧。重要地是要认识到团队中不可避免地要有人去设计和维护设计系统，并且也有人会是设计系统的用户（受益者）。也许这两个群体之间有所重叠，但确立设计者和用户的角色是至关重要的。
当我谈到创建一个更协作的流程，就像我在前一个章节中谈到的那样，肯定会听到那些在大型组织中工作的人说，“布拉德，我们有数以百计千计的开发工工程师开发我们的产品。让所有人协作在一起，那真的太困难了。”
很可能确实如此。如果整个组织采用敏捷、更具协作性的流程，花费在繁复工作上的精力真的让它不具备可能性，也过于理想化。但有一件事情要说明：不是团队中的每一位成员都需要直接参与到设计系统中，但至少有一个人（或者有可能的话，几个人）必须要为设计系统负起责任。
设计系统的设计者是创建、维护并管理设计系统的那批人，他们需要紧密的协作在一起以确保该系统是智能的、灵活的、可扩展的，并且满足用户和商业的需求。设计系统的用户，是企业组织结构中那些将界面设计样式应用到特定应用程序中的那些团队。
设计系统的设计者和用户
设计系统的设计者和用户需要保持紧密的协作关系，确保系统中定义的样式库满足应用程序的需求，并且所有的文件都是明确的。设计者需要有一个服务整个生态系统的鸟瞰视角，而用户需要有一个专注于系统中具体应用程序的落地视角。 Salesforce的Jina Bolton相当不错地总结了设计者和用户之间的关系：
设计系统指导我们进行产品设计。我们的产品设计也会反过来告诉我们如何完善设计系统。-- Jina Bolton, Salesforce
这两个观点对于设计系统的成功至关重要，这就是为什么对于设计者和用户来说，要保持一个健康的关系，这是频繁的沟通和协作的重要原因。
# 设计系统的设计者
谁来更新设计系统？由谁批准变更？由谁来和设计系统的用户进行沟通，以确保它能满足他们的需求？由谁来决定哪个样式需要保留，删除，或调整？
这些问题的答案很大程度上取决于你的组织结构的规模和架构设置。
大型组织能够分配特定的资源来管理设计系统。以Salesforce来说，他们保留有一个官方的设计系统团队 ，后来我听说目前包括大约十几个全职员工。该专业团队负责管理设计系统，并确保满足内部产品团队的需求以及基于企业平台上的外部开发者的需求。当一个设计系统服务于成千上万的用户时，配备几名全职员工去管理和扩展设计系统是一个不错的想法。
小型组织很可能没有奢侈到构建维护设计系统的专业团队。小型组织的团队成员由于需要，需要兼顾多个角色，因此管理设计系统可能会成为另一个责任。这听起来像一个额外的负担（“哦，好极了，我还要负责另一件事，但不涨薪水！”），你应该为这个特殊的角色而高兴，因为它提高了所有其他工作的效率和质量。设计系统万岁！
通常，较小组织的设计系统的设计者，是具有决策经验和执行设计系统权限的高级别的员工。
再有就是外部机构，承包商和顾问 。在一个长期需要维护的客户设计系统中，第三方所起的角色是什么？一方面，外部合作伙伴都处于比较不利地位，因为他们并没有真正为客户组织而工作。一个成功的设计系统需要成为组织DNA的一部分，因为第三方独立于公司之外，他们的影响力本质上是有限的。
但在另一方面， 外部各方往往可以提供一种看待问题的新角度，而这通常在公司内部工作时很难发现。这也是外部第三方能够真正大放异彩的地方。在我的顾问生涯中，我与企业组织工作在一起，建立长期的设计系统维护策略，帮助获取合适的人员和流程。虽然系统的长期成功最终将取决于组织，但第三方可以教会他们怎么做设计系统，除此以外还能提供重要的战略指导，反馈和观点。
# 设计系统的用户
负责使用设计系统来构建新功能和应用程序的是哪些人呀？与系统设计者谈论问题和提出产品需求的又是哪些人？
再一次的，这些问题的答案将在很大程度上取决于你组织的规模和结构。
该系统的设计人员可以在同一个创建设计系统的团队中，或者在同一个组织的独立开发团队中、在初中级设计师和开发者中、在合作伙伴组织中、在外部研发工作室中、或其他第三方团队中。
用户接近并参与设计系统的创建，无疑将会有所不同。你可能在一个斗志旺盛的创业团队负责单一产品的工作，这样小型团队可以同时创建并使用此设计系统。或者，你可以与世界各地的所有分散的开发团队和第三方合作伙伴一同在大型跨国公司工作。如果是这种情况，设计系统的设计者和用户可能很少会面，这意味着有用的文档、清晰的鸟瞰视角就变得更加地重要。
设计系统用户和设计者之间存在一系列潜在的关系，你的公司的规模和构成无疑将塑造这些关系。
建立一个贴心的设计系统的最大优点是，它允许组织去测量最佳实践。如果所有这些最佳实践 - 响应能力，可访问性，高性能，用户体验，人体工程学等等都被系统化，那使用者可以简单地接入模式并获得奖励。这意味着设计系统的用户不必是高级设计师或开发人员才能做好工作；无论每个人的技能水平如何，设计系统都能作为质量控制工具来帮助用户应用最佳实践。
# 设计系统团队的构成
一个跨学科的团队应被建立以适当的管理，维护和扩展系统。 在组织中的所有学科——UX设计师，视觉设计师，内容战略运营，前端开发，后端开发人员，产品经理，项目经理，高管和其他利益相关者——都有独特的视角，可以毫无疑问地帮助改进工作。将这些观点融入到设计的系统是非常重要的，但并不一定需要每一个学科不间断地参与其中。
难免会有学科要积极去完成工作，而其他角色可能要承担更多的咨询作用。那些负责设计和构建用户界面的人员 -- UX设计人员、视觉设计人员、前端开发人员，将成为完成工作并对设计系统进行更新。 他们应该协同工作（详见第四章），并与其他学科进行协调，以确保系统反映整个业务的价值和考量。
其他人可能不需要积极参与到这项工作，但也可以咨询他们，以确保他们的观点在系统中得到适当反映。 后端工程师需要使团队了解影响前端UI的任何架构决策; 高管需要使团队意识到将影响系统作用和效用的重要举措; 并且，设计系统的使用者需要与设计者协调，确保这个系统能满足各个应用程序的需求。
# 使其有适应性
如哲学家说的：变化才是唯一不变的东西。活着的设计系统有生命的部分意味着需要不断调整、接受反馈、持续迭代，并与其服务的产品一起发展。
有关设计系统的一个误解是，一旦它们被建立，它们就成为一个无所不能的和不可改变的真理来源。这样僵化的思考方式一定会让你对设计系统所做的努力事与愿违。如果用户使用不能解决他们问题的模式时有束缚和束之高阁的感觉，他们将认为设计系统是个没帮助的工具并开始在别处搜索某些可以更好地满足他们需求的东西。
创建一个清晰的管理计划对于确保你的设计系统可以随着时间的推移适应与发展是必不可少的。坚实的管理计划从回答关于处理变更的一些重要问题开始。需要考虑以下内容：
- 当现有的模式对特定的应用程序并不完全起作用会发生什么？模式被修改了吗？你建议使用不同的模式吗？是否需要创造新的模式？
- 新模式的要求是如何被处理的？
- 旧的模式是如何下架？
- 当出现错误时会发生什么？
- 谁批准设计系统的更改？
- 谁是负责保证文档处于最新状态？
- 谁来实际更改系统的UI模式？
- 设计系统更改后如何安排到应用中？
- 人们如何了解更改？
有可能有更具体的问题等待回答，但重要的是你的团队应该有答案和流程来解决系统中不可避免的变化。
前面已经提过几次，设计者和使用者之间的频繁交流和协作是成功管理设计系统的关键。让它尽可能方便用户和设计者沟通。 为设计系统成立Slack或者Yammer频道，建立常规办公时间，确保你的故障提交系统有助于促进对话，对特定的网络聊天与电话敞开大门。如果用户困在某件事上，他们应该知道该向谁寻求帮助。
除了设计者和用户之间的非正式日常对话， 与设计者，用户和其他关键利益相关者计划定期的“国情咨文”会议来审查设计系统。讨论什么起作用，诚实地对待需要改进的东西，审查优先事项和路线图以确保该系统服务于企业的需求。这些定期的检查对保持利益相关者的进度特别有用，因为他们经常并不涉及设计系统的日常操作。
# 模式的更改
维护设计系统的关键部分是确保UI模式保持最新状态，拥抱不断变化的设计与开发的最佳实践并不断满足组织的真正需求。
开发用于处理模式的计划是至关重要的，这就是为什么Inayaili de León Persson和Canonical网络团队花时间绘制出他们的策略并创造出Vanilla前端框架（Vanilla front-end framework）。
我们认为一个模式应该遵循以成为Vanilla模式的过程应该被记录下来，所以在一点头脑风暴后，我们创造出这样一个展示了从一个模式提议开始到作为一个Vanilla模式被完全接受的不同步骤的流程图。——Inayaili de León Persson, Canonical
其结果是一个华丽的决策树，勾勒出在一个新的模式被添加到设计系统时到底需要发生怎样的流程。
Canonical网络团队制定了用于管理更新和补充Vanilla前端框架模式的决策过程。
模式变化中可能出现的三种类型分别是修改，添加和删除。
# 模式的修改
UI模式可以并且应该因为一些原因被修改：功能的增加，bug修复，微小或重大视觉设计调整，性能改进，辅助功能增强，代码重构，UX最佳实践的更新，等等。
设计系统的维护人员需要理解为什么以及何时调整模式，如何去进行这些更改，以及如何将这些改动推进到单个程序中。
保持模式是最新的对于设计系统的长期健康至关重要。没有人愿意使用和维护一个拥有Web 2.0外观的充满歪斜和脆弱代码的设计系统！
# 模式的添加
随着您的团队越来越智能，你可能不会立即想到你设计系统中的各种可能的模式。当该系统被应用到更多的产品时，应用程序的需要不被现有的模式解决的差距将不可避免地出现。在这种情况下，很显然新模式将需要被创建以满足这些需求。
添加模式到库中需要谨慎。如果每个心血来潮的结果都是个全新的模式，设计系统将成为一个粗笨而狂野的西部。这是否是一次性的情况还是可在其他应用程序中加以利用的东西这样的问题是值得被提出的。
可能你假设它只是一次性情况，直到其它的团队遇到了类似的问题。如果应用2的团队对应用1说：“我要那个！”也许这是这个一次性模式应该被添加到模式库的好迹象。
# 模式的删除
模式可由于很多原因被弃用。也许是你通过使用一个特定的模式发现它很可怕。事后诸葛亮太常见了，我的朋友。也许这个行业已经出于UX或者技术原因移除模式了。也许一个模式在那里多年未被任何程序使用。也许用户报告回来了很多关于与特定的工作模式的负反馈。
具有弃用模式的计划是一个伟大的想法。但你如何从设计系统里删除模式却又不让那些他们的程序里依靠这些模式的人受到牵连呢？为了解决这个问题，Salesforce创建一个整洁的工具，叫做Sass Deprecate来给那些不久将前往砧板的模式加旗标。通过Sass可变标志和造型的一些巧妙利用，制作团队可以给一个使用已被弃用的特定模式的用户一个警告，并推荐一个不同的模式来代替。
# 使其易于维护
当一切都在谈论修改，添加和删除模式时，你可能想知道，“我们的应用程序到底应该怎样跟得上这些变化？”而在问这个问题的时候，您将无意中发现在成功维护设计系统中组织面临的最大挑战之一。
任何系统最大的生存威胁是疏于照顾。——Alex Schleifer, Airbnb
许多系统落入了年久失修的状态，因为更新所需的工作量太高了。如果更新模式、文档和应用是件困难并耗时的事情，人们最终会很沮丧，以致他们停止努力，设计系统将开始被遗忘。更新UI模式文档和应用程序应该尽可能地无阻力 ，因此减少这种阻力应该成为设计系统团队高度重视的事情。这包括来自技术和工作流程立场的慎重考虑。
# 寻找圣杯
圣杯设计系统包括创建一个这样的环境，在该环境中模式库和应用完全同步。 这个想法是，你应该能够做出UI模式的改变并看到这种变化自动反映在模式库和包括模式的任何其他地方。
设计系统的圣杯是这样一个环境，在此环境中UI模式的改变可以同时更新模式库和包括模式的应用。
这项技术消除重复工作，并确保模式库和使用模式的应用程序保持同步。听起来像个梦，对不对？
事实证明，这个梦想可以成为现实。Lonely Planet是旅游指南公司，首先建立了一个叫Rizzo的圣杯设计系统。通过一些智能架构，他们创造了一个API为其UI模式反馈到他们的工作环境和模式库。其结果是一个集中化了的设计系统，以确保他们的应用程序和文档完美同步。
Lonely Planet创造了一个API，UI模式可同时被它们的模式库和工作环境使用。通过用这种方式构造设计系统，UI模式的改变会自动反映在模式库和工作环境中。
这种方法并不是个容易的任务，因为它需要复杂的技术架构，聪明的人来设置这一切，和相对集中的组织文化。你如何去追逐圣杯 - 或者即使可以得到它 - 取决于各种因素，包括您的技术架构和组织。
# 清除技术障碍
保持模式库和工作环境中同步需要以智能、可扩展性和可维护性的方式共享代码。围绕圣杯详细介绍各种不同的技术策略和考虑将会有用，但请让我们关于保持前端代码同步方面谈谈几个重要方面。
# 事物的前端
一个UI设计系统常表现为前端的网络体验，由HTML，CSS和JavaScript组成。我们如何在工作环境获取前端代码，应用复杂的应用程序逻辑和后端代码，是手头的任务。
在他的文章“ 追逐圣杯 ”中Web开发人员Marcelo Somers详细描述了可实现圣杯的各种技术手段。他强调了每种用于输送设计系统到应用程序，以保持两者的代码库步调一致的策略的优劣。虽然我不详细叙述每个Marcelo的策略，值得注意的是有一类方法可供选择：在一边复制和粘贴未加工的，手动的前端代码，在另一边直接制作模式库到工作环境。
根据我的经验，我发现与工作环境共享CSS和演示JavaScript相对容易，而共享标记却很艰难。因为CSS和JavaScript往往会被编译成一个文件（或者几个文件），可以将它们扔到CDN，然后简单地在每个应用程序中链接到这些文件。Marcelo解释了如何保证版本更新的同时做到这一点：
你会向开发团队提供一个版本化的URL（例如，http://mycdn.com/1.3.5/styles.css）并随着升级改变URL中的版本号。——Marcelo Somers
共享CSS和JavaScript是一个好主意，但当你想在环境之间共享标记时事情将变得棘手。为什么会这样？你会问。好吧，标记和后端逻辑往往在应用程序的代码库中相互缠绕，这往往使人难以从你的模式库到工作环境简单地复制粘贴标记。值得庆幸的是，有方法可以解决这个问题。
# 通过模板语言消除标记差距
使用HTML模板语言（如Mustache, Handlebars, Twig, Underscore, Jade, Nunjucks, 和其他的一些），可以使标记更轻便和动态化。模板语言分开了结构和数据，并且加强了我们的HTML以保证我们不必一遍又一遍写相同的标记。好消息是，许多CMSes和应用程序环境也利用模板语言来提供前端标记。
模板语言还可以作为你的模式库和工作环境之间的桥梁。 如果你在设计系统中使用模板语言来创建模式（我们之前在第3章中讨论过），你可以轻松地和利用相同模板的工作环境共享模式。
像Mustache, Handlebars, Twig, Underscore, Jade,和其他的模板化语言可以作为一个桥梁，它可以使图形库和应用程序之间共享前端代码。
在第2阶段的技术团队通过使用模式实验室作为模式库的开发工具和使用Drupal作为他们的内容管理系统来达到圣杯状态。由于模式实验室和Drupal都支持流行Twig模板引擎，第2阶段能够很容易地在两个环境之间共享模式，以确保他们客户的模式库和产品构建总是同步。
通过使用相同的模板引擎，在组件库Drupal模块的帮助下，该工具提供了Drupal直接包括、扩展与嵌入Twig模板的能力，该Twig模版可以使得模式实验室使用其成分并没有任何模板重复！——Evan Lovely，第2阶段技术
# 你的圣杯文化兼容性怎样？
你可能已经读到最后一节，心想：“这太不可思议了！我公司现在就需要这个！”虽然圣杯系统的确很伟大，依然有你可能不能够自动将让您的工作环境和模式库同步的原因。也许你的组织使用完全不同的技术在许多不同的平台上创造出许多许多数码产品。也许你是一个巨大的分散在世界各地的跨国公司。也许你的公司有一个非常分散的，独立的文化。或者，也许你是个巨大的联邦政府。
美国网页设计标准草案是美国联邦政府的设计系统。
美国政府的设计系统-被称为美国网络数字标准草案 -是创造出的UI组件与视觉风格的集合，帮助人们使政府网站建立更加一致的用户界面。该设计系统提供了标记和款式供用户下载和加入到他们的应用。看到以这样一个巨大规模实现的圣杯设计系统无疑是件令人惊讶的事儿，但正如你可能想象的，这是一个相当艰巨的任务。该组织的浩瀚和分散性意味着联邦政府网站被建立的过程如果没有制造出一些戏剧性重组，模式库将无法达到同步。
如果现实情况是一个相对分散的，去中心的文化氛围，不要灰心！即使在UI模式，一些有用的文档和指导原则里-用得到某些设计系统-也能够向你的组织展现圣杯的光芒。正如我们在本章讨论的，这些努力应该是持续的，并且在你可以运行之前你必须先学会爬。
# 使其跨学科
风格指南往往直接跳到代码段和使用模式是为了设计系统的用户的利益。当然了，一个模式库需要是个为人们实际利用的模式，而只是把风格指南作为一种开发者资源就限制了它的潜力。
风格指南有机会作为整个组织的一个资源库 ，帮助为公司数码产品的成功而投资的各个专业建立一个共同的词汇。建立这种共同的词汇会使得整个组织学科之间的工作效率更高，沟通更好和合作更多。这就是为什么风格指南应该成为每个人都应知道的好地方，而不仅仅是设计系统的使用者。
请使用图片轮播组件。该组件从组织的角度来看令人惊讶的复杂。在一个电子商务网站的主页图片轮播组件需要整个组织各个专业的输入。企业所有者和编辑人员必须选择在图片轮播组件中展出的产品。文案必须确保在该设计的限制之内拷贝是有效的。艺术总监需要确保做出的美学设计是赏心悦目的，产品摄影可以跨越每一个屏幕尺寸清晰可辨。UX设计师必须确认功能和控制是直观的。前端的人必须确保该组件是响应式的，可访问的和拥有高性能的。后端开发者需要确保该组件被正确连接到后端系统。你明白我的意思。
像沃尔玛网站主页图片轮播组件，需要许多不同的专业和利益相关者的输入。风格指南可以帮助你收集在一个屋檐下的不同观点。
一个精心制作的风格指南可以帮助管理所有这些可移动部件并保证影响相互模式的诸多观点在风格指南中被正确记录。使各个专业接触得到模式库，想想如何使不同专业对文档作出贡献变得轻松和诱人。
# 使其平易近人
它应该对人们都很易懂，因为人们往往倾向有吸引力的东西。使得风格指南成为一个跨专业的资源的一个重要组成部分是确保盛放你的模式库和其他文件的容器好看，吸引人且易于浏览。
Yelp的风格指南有个充满吸引力的，友好的头版，解释了来源是什么，用户是谁，以及如何使用它。
抽时间来细细雕凿风格指南和文档理想可以使得它会使得更多被使用，有利于提高认识，帮助建立组织的投资，并有助于吸引非开发者注意风格指南。有助于重要的共享词汇的所有的这一切都会提供更好的跨专业合作。
但是创造一个很漂亮的，直观的风格指南经验并不会刚好发生，并且当一个风格指南脱离事实时这可能是个问题。如果团队认为做一个有用的风格指南涉及制作某些大的，官方的东西是关于自定义品牌和有效果的网站的，他们可能会从一开始就望而却步。所以请牢记：
- 将它加入日程
- 表明它是有帮助的
- 把它变得正式化
创建一个有用的设计系统应该是团队的首要任务。创建一个快乐的团队来应对未来可能发生的问题，但是一旦设计系统迈入正式化，应该成为一个更优先的事项。制作一个好看的风格指南不仅仅是为了设计而设计; 它反映了组织致力于制定和维护一个体贴、深思熟虑的设计系统的承诺。
# 使其可见
可视性对于设计系统的持续健康至关重要。这样一个重要的努力不应该被放置在公司内部的黑暗角落里。你可以采取哪些步骤来确保设计系统仍然是设计和开发工作流程的基石？
# 设计系统的布道者
您可以创造世界上最好的风格指南，使用最先进的技术，有一个惊人的团队，并有踊跃的用户，但如果不积极推动设计系统和沟通变化，整个工作将受到很大的影响。
努力传播设计系统在设计系统开始前就可以开展起来。在项目开始时，您可以创建位置来记录项目的进度，以帮助提高设计系统的意识和兴奋度。我的一位客户建立了一个内部博客来发布项目的更新，除此之外也可以在Yammer上创建一个设计系统的频道，在这里开发者和其他感兴趣的各方人员可以分享想法，解决问题，提供反馈和提出问题。在此过程中尽早建立沟通文化将增加设计系统深入人心的可能性。
# 沟通的改变
一旦设计系统起步并被用于实际应用中，沟通变化、更新，传递持续前进的愿景给整个组织就势在必行。
这种沟通策略可以从具体的实用程序转变到面向外部的营销工作。这里有一些材料，可以帮助沟通变化：
- 更改日志 ：“这些是本月模式库中的一些变更内容。”
- 路线图 ：“这是未来几个月的规划内容”
- 成功案例 ：“X团队使用设计系统推出了这个特别棒的新应用程序; 阅读更多关于他们是如何做到的内容。”
- 技巧和窍门 ：“以下是在整个应用程序中使用系统按钮的一些最佳实践和注意事项。”
拥有所有这些材料是一个好主意，并将他们放置在风格指南边上或放置在风格指南内也很有意义。
Material Design设计团队在其风格指南中发布了一个方便的更改日志，以便用户可以轻松了解系统的最新更新和改进。
不论你的团队是否在一起工作，设计系统的更改、更新、新需求都应该沟通讨论。 这可能包括Slack，Basecamp，GitHub，wikis，Yammer，电子邮件列表，公司博客，内部网络以及您的团队用于沟通和协作的任何其他内部工具。如果对于你而言，这听起来像一个像一个大工程，但也不要害怕！保持你的团队和用户更新并不一定需要大量的手动工作。由于我们的工具的互联特性，团队可以通过软件自动获取提醒变化，来自Skyp的Micah Sivitz这样解释到：
每当有人提出请求时，它会向我们Slack的设计频道发送一个通知，告知团队有一个提案更改，并且需要提供反馈 -- Micah Sivitz, Shyp
将这种沟通传播到团队的日常工作流程中，使设计系统创造者、用户和利益相关方都参与进来，并帮助用户确保模式库一直处于积极维护和改进中。
# 培训和支持
你不会把一个锤子、锯子和螺丝刀给到别人说：“好吧，你现在有需要的东西; 现在去给我建一个漂亮的新房子。”了解如何正确使用工具通常比获得该工具更重要。风格指南文档无疑很有帮助，但这本身还不够。必须提供足够的培训，并为您设计系统的用户提供持续的支持，以确保他们能成功地开始使用工具包，继续用它来创造非常棒的产品。
培训用户如何使用设计系统可以采取多种形式，包括：
- 对话 ：没有什么可以比拿一把椅子坐在一起完成同一个项目更有效的了。虽然比其他培训方式占用更多时间，但是这是让创造者和用户能相互协作，帮助了解系统是如何运作的，以及发现新机遇和缺点的最佳方式。
- 工作坊 ：从融入式的对话到快速演练，创建包括创造者和用户双方的面对面式的培训工作坊真的非常有帮助。这些会议可以帮助解决对系统的任何误解，帮助用户进行实践指导，建立维护系统的人员和负责人员的健康关系。
- 网络研讨会 ：如果不能进行研讨会或对会，或者您要培训大量的用户，网络研讨会就会变得非常棒。用户可以使用在线会议，以了解如何正确使用该设计系统。在进行网络研讨会时，请务必确保有大量的问答时间，以便支持音频和文字类型的问题、担忧和评论。
- 教程 ：一系列博客文章和截屏可以完整地概述与设计系统相关的核心概念。这不仅有助于作为一种培训工具，而且可以作为一个很好的参考，以便回溯。
- 入职培训 ：将设计系统注入公司文化，一个很好的方法就是将设计系统培训直接纳入新员工的入职流程中。新同事将了解设计系统所带来的模块化、重用、以及其他好处的重要性。
用户一旦开始使用设计系统来开始工作，无疑是会再遇到问题的。他们需要知道有一个强大的支持系统来帮助回答任何问题，听取他们的需求并解决bug。有许多机制，可为用户提供支持，包括：
- 问题跟踪工具 ：像JIRA和GitHub这种问题跟踪工具,对于设计系统的用户和创造者来说，是非常好的报告bug并进行技术交流的工具。用户应该知道提交bug的协议，并能为此贡献价值。
- 办公时间 ：当设计系统团队能够处理问题、解决问题的时候，就要安排固定的一个时间来聊聊设计系统下一步的方向。
- Slack等聊天工具 ：很多实时性的协作工具给我们提供了一个自动聊天模式（聊天机器人）的巨大机会。得益于Slack，Yammer和HipChat等工具，创造者和用户可以随时随地进行互动。
- 论坛 ：像Stack Overflow（一个IT技术问答网站）、Github这样的社区已经验证了在民间和社区驱动支持方面是非常有效的。而不是设计系统创造者成为支撑瓶颈，开放对整个用户群的支持是非常值得的。
- 延伸 ：不是每个人都有时间或都乐于提问、提出改变的。设计系统创造者应该有前瞻性，并主动为使用设计系统的开发者提供帮助，看看他们是否有任何问题或疑虑。这类行为可以帮助创造者和用户建立真诚、积极的关系。
美国网络数字标准系统草案使用GitHub跟踪问题，为用户和创造者提供了一个提交bug和实质性对话的地方。
得益于GitHub这样的工具，设计系统用户不需要被降级为愚蠢的消费者。如果可能的话，每天使用系统的人可能是设计系统的极有价值的贡献者。要接受这样一个事实，即用户渴望作出贡献，并让系统变得更强大。以下是一些鼓励用户贡献的策略：
- 建议和合并请求 ：鼓励任何使用设计系统的人提出建议和新功能特性。更好的是，邀请用户提交更改可以直接以合并请求的方式合并到代码库中。
- 个人访谈和圆桌讨论 ：与用户交谈总是一个好主意，所以定期安排时间与那些经常接触这些模式的人聊天。把所有的事情都考虑进去，听听好的和坏的两，共同决定一个解决问题和采纳建议的计划。
- 要求反馈 ：管理一个可能部署到数百个应用程序的系统可能会很棘手。在决定可能影响很多人的决定之前，请征求意见: “我们考虑放弃我们的轮播模式，并希望听到你的想法。”
- 调研 ：如果面谈不可行，你可以依靠快速调研来了解UI模式和风格指南的有效性。可以放置调研问题，诸如“模式文档多有用，1分~5分，请打分；有什么建议吗?可以帮助识别盲点，让用户推荐一些能让他们的生活更便捷的功能。
- 定期会议 ：安排例会，例会上设计系统团队可以讨论产品路线图，分享落地过程中的经验教训、建议和反馈。鼓励任何人参加会议，并记录和分享这些会议记录，以便每个人都了解整体规划。
# 使其公开
传播变化，建立和传播适当的培训和支持，都是提高系统知名度的重要因素。另外还有另一个重大的机会能让你的沟通策略上升一个档次：将你的风格指南公开可访问。
为什么？风格指南不是仅仅是一个内部资源，以帮助组织中的人们更好地工作吗？它对外界有什么用？发布风格指南是否会泄露你公司的商业秘密吗？
发布您的风格指南，让世界都能看到它以提升它的知名度，提升问责机制，并作为一种惊人的招聘工具。
将您的风格指南放在登录之后或防火墙内会减少可见性，并且为您的团队和合作伙伴增加不必要的负担，这也限制了资源的有效性和潜能。担心泄露商业秘密是完全没有根据的。这些是用户界面模式，而不是核心代码。
网站http://Styleguides.io上提供了来自世界各地组织的150多个面向公众的风格指南。
除了使重要的文档更容易访问外，公共样式指南还有助于建立问责制 。发布你的风格指南展示了你的组织对于设计系统的认同，对保持风格指南长期更新、可用提供了外在压力。
面向公众的风格指南对招募也很有帮助 。设计师、开发人员和在其他领域工作的人员都希望为采用现代化数字办公的组织工作，而设计系统正迅速成为全行业的最佳实践。发布您的风格指南会发出强烈的信号，可以吸引充满激情、关注设计模式的人。例如，风格指南专家 Jina Bolton在看到Salesforce1产品的风格指南之后就跑到Salesforce工作了。
当我看到[Salesforce的风格指南]，我认为它很出色，这是为什么我想加入这个团队的原因。——Jina Bolton
自从加入了Salesforce，她帮助创立了超级成功的Lightning设计系统，并帮助管理他们不断扩大的设计系统团队。几乎每一位客人（例如：Anna Debenham - 《Front-end Style Guides》一书的作者）和我在Styleguide Podcast播客上采访的嘉宾，都讨论了面向公众的设计模式是如何吸引人才的。所有这些都意味着你的公共风格指南会让你的组织更具竞争力。
# 使其更大
一个可见的、跨学科的、亲切的设计模式库是你的团队会反复更新的。利用你的优势。由于团队的注意力都投入在那一个资源上，这是个很好的机会来扩充设计模式库去包含更有用的文档，例如产品品牌、产品基调、代码、设计准则和我们第一章中讨论的设计指南。
Intuit的Harmony设计系统包括设计模式库、设计原则、产品格调、营销准则等等。将这些有用的文档放在同一处有助于提高它的可见性和有效性。
现在，您的组织可能不需要实现每种风格的样式指南，但是重点是创建一个集中的样式指南集可以增强对最佳实践的认识，提高文档的有效性。
扩展模式库的功能的另一种方法是，包括基于web模式的原生平台模式的风格指南。我们可以再看看Intuit的Harmony设计系统，看看iOS和Android的原生移动平台模式是如何与基于网络的同类产品相兼容的。
Intuit的Harmony设计模式库包含了在web、iOS和Android之间切换的按钮。这使得团队能够跨平台维护一个大致一致的设计系统，也能在设计模式差异产生的时候记录下来。
# 使其上下文无关
UI模式的命名方式将毫无疑问地影响它们的使用方式。设计模式的命名越是和内容上下文无关，它们就变得越通用和可重用。
因为我们倾向于根据页面中的上下文内容创建UI模式名称，所以根据他们所处的位置来命名组件是很有诱惑力的。但是，与其命名你的组件叫“轮播主页”(请原谅我对轮播组件的病态迷恋)，你可以简单地称它为轮播组件，这意味着你现在可以在任何地方使用轮播组件！（仅出于对这个控件的喜爱，请别这样做!）
命名显示模式的另一个挑战是，我们往往会组件中的内容样式分散注意力。例如，如果你在一个电子商务网站工作，你可能会想要称呼一个同时包含产品图像和标题的模块叫做产品卡片。但是以这种方式命名的设计模式会立即限制它里面的内容类型。通过将模式简单地命名为"卡片"，您可以将所有类型的内容模式放入其中:如产品、促销、存储位置信息等等。
合理警告： 命名真的很难 。但是有一些策略可以帮助您为模式创建强大的名称。执行一个界面清单(在第4章中已详细阐明)有助于删除设计模式的内容样式，这意味着您的团队可以创建不会被上下文所干扰的命名模式。我已经和团队进行了命名有关的练习，我们已经模糊了模式中的内容，这样每个人都可以专注于设计模式的结构，而不是其中的内容。
命名模式的一个很好的训练就是模糊其中的内容，这样这个命名就能反映出模式的结构，而不是其中的内容了。
虽然命名一直是一个挑战，但与上下文和内容好不相关的模式名称将更加可移植、可重用和通用。
# 使其情境化
在模式库中展示UI模式本身非常好，但是你需要向设计系统用户演示内容示例，以帮助他们了解如何正确地使用它们。大多数的模式库都显示了每个UI模式的demo示例，但是，正如我们所讨论的，这些UI模式并不是空中楼阁。这些UI模式究竟被应用在哪些地方呢？
演示内容关系一种方法可以是包括显示某个组件的屏幕截图或视频。Material Design的说明文档在这方面做得非常出色;每个组件都有配图、视频和使用细节，可以让用户清楚地了解这些模式在应用程序的上下文中是什么样子，并演示了如何使用每种模式。
Material design的组件库不仅包含每个组件的示例，还通过大量的图像和视频对组件的用法进行了详细的文档说明。
像Pattern Lab这样的工具提供了谱系信息，允许团队查看在任何给定组件中包含哪些较小的组件，以及每个模式应该在哪里使用。正如我们在第3章中讨论的，像Pattern Lab这样的工具会自动生成这些信息，除了显示每个组件的使用位置之外，还可以看到哪些模式构成了已给定的组件。这提供了一种模式文档跟踪的手段，它极大地帮助了QA的工作，因为它突出显示了如果对特定模式进行更改，需要对哪些模式和模板进行测试。
像Pattern Lab这样的工具提供了谱系信息，允许团队查看在任何给定组件中包含哪些较小的组件，以及每个模式应该在哪里使用。
# 使其可持续
设计系统是一项非常重要的工作。但是如果没有适当的维护，你的设计系统的价值就会像一辆刚从经销商那里开出来的汽车一样快速贬值。相反，你的设计系统应该像一瓶美酒，随着时间的推移，会增值。
通过适当的维护，你的设计系统就会随着时间的推移而增加价值，就像一瓶好酒，而非像一两二手车一样贬值。图片来源： Sabin Paul Crose on Flickr和Ray Larabie on Flickr
正如我们在这一章中所讨论的，使您的设计系统经得起时间的考验，需要大量的时间和精力。但是，不是万物都这样吗？就像动物需要进食，植物需要水和阳光才能生存一样。创造一个有生命力的设计系统意味着给予它关注和关心，以使它继续茁壮成长。
所有这些努力不仅为你的组织创造了一个更好的礼物，也为你的长期成功奠定了基础。建立一个清晰的管理计划，沟通变更，并落实在本章中的其他建议，帮助设计系统扎根并成为组织工作流程的一个重要组成部分。首先，从无到有是最难得一步，但一旦建立起来，你就有了坚实的基础，在未来的岁月里，它将会继续发展下去。即使你要推翻一切从头开始重建一个新的系统，你仍然会发现你的UI界面依旧需要按钮，表单域，标签和其他现有的组件。你需要一个快乐的团队去展示和维护这个系统。千万不要不分好坏全盘否定！
要创建可维护的设计系统，您应该：
- 使其官方认可 通过分配实时，金钱和资源来设计系统。
- 使其有适应性 通过改变来制定明确的管理计划。
- 使其易于维护 通过寻找圣杯并使其易于部署和传达对设计系统的更改，使其更可维护。
- 使其跨学科 通过使你的模式库成为整个组织可以围观的一个水坑。
- 使其平易近人 通过制作一个有吸引力的、易于使用的风格指南，并提供相应的文档，使它变得更易亲近。
- 使其可见 通过沟通改变，传播设计系统，使之公开，使之可见。
- 使它更大 通过包括品牌、产品格调、代码、设计原则和书写准则，使之变得更大、更完善。
- 使其上下文无关 根据它们的结构而不是上下文或内容来命名模式，从而使其上下文无关。
- 使其情境化 通过演示哪些模式可以组成一个特定的模式，并显示每种模式的使用情况。
- 使其可持续 奠定坚实的基础，未来几年不断优化完善。
# 向前，变得原子化
我们的任务是让大量的产品、网站和应用程序工作，在各种不同的设备、屏幕大小、表单因素和环境中看起来都很棒。我希望本书所涵盖的概念能让你坚定地站在你的立场上，勇敢地面对这个日益多元化的数字世界。通过创建设计系统，如何构建用户界面，建立一个协作和模式驱动的工作流，以及建立一个流程来成功维护您的设计系统，我希望您和您的团队能够一起创造出伟大的东西。向前，变得原子化！
