进阶篇27. 设计系统简介（上）
来由
随着科技的发展，我们进入了无线互联网时代，一方面一大批的传统网站面临着移动优先的挑战，另一方面，移动应用市场还有着无数的APP等着设计师去设计。于是，一直标榜“量身定制”的设计，遇到了前所未有的危机。在移动互联网时代，项目是不断变化不断迭代的，传统的设计/前端流程已经跟不上项目的需求了，成为了瓶颈。
我在上一本书的末尾《Drupal的前端表现为什么这么差》中，已经提过了，界面设计和前端行业的先锋们为了应对时代的变化，逐渐提出了抛弃Photoshop，直接在浏览器上做设计的主张，在一段时间内，这种新潮的工作流程确实让局面得以缓解，然而好景不长，问题的根源——生产力的发展跟不上需求的增长的问题——并没有得到根本性的改善。
在这样的背景下，为了让设计和前端跟得上项目开发的脚步，靠谱的解决方案只有3个：
- 为同一个项目雇佣更多的设计师和前端工程师
- 抽打他们，让他们加班，缩短设计周期
- 创造一个新的解决方案，使它能用于各种不同的项目
最初的时候，很多公司理所当然的使用了第一个方法，但是，他们发现，即使雇佣更多的帮手，依然解决不了问题，因为更多的人，意味着更多的沟通工作。而且传统的“量身定制”式的客制化设计流程会由于每个项目的特殊性而不可避免的带来一些劣势：速度慢、缺乏统一性，并且随着时间的推移，公司人员的流动，项目越来越难以维护。
当然，他们也可以选择用死猪不怕开水烫的脸和说的比唱的还好听的嘴去说服客户，他们的设计是世界上最好的，但是，这个属于销售技巧，不在本书的讨论范围之中。
出路在哪里？（假设加班不给双倍工资是不合法的）
纵观整个计算机技术的发展历史，你会看到，人们一直致力于改善项目的可持续性，可维护性，代码的可重用性。他们给出的解决方案就是模块化（他们自己称之为对象化）。而现在，是时候让设计也加入这个行列之中了。
我们看到，Iphone和Ipad刚发布的时候，使用的都是精美绝伦的拟物化的界面，但是，到了后期，却被扁平风格的界面所取代，这实际上也从一个侧面印证了时代的发展以及设计方法论变革的必然性。唯一的出路就是尽量减少设计中的个性和艺术性。
在这样的大背景下，“设计系统”作为一个新的解决方案横空出世。它的核心价值就在于能够极大的提高设计效率——当然，也不可避免的失去了“量身定制”的设计所能提供的个性化。
以下是几个最顶级的设计系统：
- ADG by Atlassian
- IBM Design System
- Material Design System（这个不必介绍了吧？）
- Polaris by Shopify
- Airbnb Design System
- Lightning by Salesforce
- Nachos by Trello
- Photon by Firefox
相关概念
这一节，我们将为设计系统下一个模糊的定义，但是在这之前，我们先来看看几个相关的概念。
我们前面提到了很多概念：组件化开发（component driven development），模块/模式库（pattern library），组件库（component library），风格指南（style guide）等。
组件化开发讲的是主题开发的流派、方式，是我们在前几节中介绍的内容，与其相对应的是传统的主题开发方式（也就是第一篇中所介绍的方式）。
组件化开发方式所得到的结果其实是由两个部分组成的：
- 一套组件库/模块库（包括每一个模块的视觉效果、代码、说明文档和名称）
- 一套Drupal网站的主题（info文件、模板等）
并且两者之间共用同一套前端资源。
组件库/模块库指的就是把界面拆分成小的单元之后，将这些小的单元集合起来所形成的库。在传统平面设计师的眼里它就成了风格指南。
当人们谈到活的风格指南（living style guide）时，又是前端设计师们相对于传统平面设计而使用的词汇，因为平面设计中的风格指南都是以印刷品的形式呈现的，这意味着它是无法修改的，不能随着产品或者品牌的成长而改变的。而到了前端设计行业中，风格指南和产品的前端代码完全同步了，修改产品的同时，风格指南也同时被修改了，因此才有了风格指南是“活的、有生命的”一说。
以上的这些概念中，有两个我们一直都没有做明确的区分，一个是pattern一个是component，这里稍微谈一下。
Pattern在这里的翻译应该是：模式、图案、规律。比如，连环杀手的作案手法往往都是有一定的pattern（规律）的；有花纹的布都是有pattern（图案）的，因为印刷机只有那么大，但是一捆布可以有几百米长，那么印刷机就只能把一个图案重复的印刷到布料上从而形成一整张布的花纹。同样的，用户界面和网站页面上，也会有很多重复的元素，他们就可以被叫做Pattern，比较贴切的翻译应该是模式，但是在中文里，模式往往只的是抽象的概念，而不是具体的东西，因此，我还是倾向于将其翻译为模块。
Component在这里的翻译应该是：模块、组件。它指的就是组成界面的元素。同时，也包含着模块化的思想在里面，这个思想在前面几节中讲流水线的时候讲过了，见第二篇第18节，在这一节中我们对组件也做了详细的介绍，因此这里就不在重复了。
因此，我们用Patternlab生成的组件库，可以叫做Pattern library 也可以叫做 Component library，对应的中文就是模块库/组件库；库中的组件，即可以叫做pattern也可以叫做component。在大多数情况下，两者没什么区别，混着叫也无所谓。当我们说pattern的时候，强调的是元素（或者多个元素的组合）的重复性和规律性；说Component的时候强调的是模块化的思路。
关于这里的翻译问题，恕本人才疏学浅、学艺不精，没有找到更好的翻译方法。各位小伙伴如果有任何建议和意见，欢迎在下方留言，谢谢。
各位仔细想一下就会发现上面的这些名词都是相关的，从不同的角度看同一个东西，叫法不同而已。当我们说组件库/模块库的时候，我们更多的是偏向于开发，它的作用更多的是类似于文档的作用，帮助我们更好的维护项目，尽可能的重用代码和组件；当我们说风格指南的时候，我们更多的是偏向于设计，因为它定义了字体、网格、行间距、图标、颜色等设计元素——本书到目前为止，并没有安排专门的一个章节来讲述风格指南，因为它其实就是组件库，只是更加偏重于设计；另一方面，也是因为我们要抛出一个更高级的概念——设计系统。
设计系统的定义
如果我们从一个更高一层的维度去看待组件化开发以及它的结果，我们会得到一个结论：我们其实不是在设计网页，不是在开发网站的前端页面，因为我们的开发过程中，网页已经被拆散了，我们实际上是在开发一套包含了各种前端组建的系统（比如：卡片card，轮播图，下拉菜单等）——当这个系统达到一定规模的时候，我们又可以用它来组合成网页。
和其他所有的系统一样，组成系统的各个要素之间是有着紧密联系的，并且是互相作用的。这里，我们把这个系统叫做“设计系统”。设计系统其实就是组件库/模块库/风格指南，但是当我们叫它设计系统的时候，强调的是组件之间的关系，组件之间如何组合及合作，以及整个团队（开发者、用户体验工程师、设计师、前端工程师等各种角色）如何使用、修改、迭代这些组件。我们并不把它单纯的看成一个用来指导开发的文档，或者指导设计的风格指南，而是把它看成一个集设计标准、代码片段、说明文档、组件及其功能为一体的完整的系统。
特点
设计系统结合了“标准”和“组件”这两个重要而又独立的概念，它们组合到一起之后起到了一加一大于二的作用。
标准
仅仅了解设计系统定义了什么东西是不够的，还应该搞清楚为什么要这么定义，只有这样才能创建卓越的用户体验。
整个产品团队的所有成员都应该具有这种对系统的深入理解。为系统定义并执行一系列的标准使得团队成员们能够深入理解系统。这样做可以避免产品团队在工作中可能会遇到的各种歧义和主观臆断，从而减少摩擦和沟通障碍。
这里说的标准，即包含了设计的标准也包含了开发的标准。将工作标准化，例如统一命名规则、文件结构等有利于团队协作的持续性并能减少错误的产生。设计的标准其实就是我们上面提到的风格指南，包括对字体、网格、行间距、图标、颜色等设计元素的定义。
视觉语言是设计标准的核心部分。定义颜色，形状，字体，图标，间距和动画的风格以及它们的目的、作用，对于品牌视觉形象的强化和用户体验的一致性至关重要。系统中的每个组件都包含这些元素，它们在表达品牌个性方面发挥着不可或缺的作用。
没有标准，设计决策就变得武断，难以判断对错。这样一来设计不但不会飞跃，而且还会导致用户体验的不一致，使得用户感到沮丧。
视觉语言的一致性是可以跨平台的，无论是在网页上，还是iOS，Android和电子邮件中。把包括视觉语言在内的整个设计系统展示出了，并加以文档说明。这样能够帮助系统贡献者(参与者)快速的理解每一个组件的外观和行为。
例如，Google的Material Design就深入探讨了他们的视觉语言的各个方面。
组件
我们之前已经为组件下过定义了。你可以把组件看成系统中的一段可重复使用的代码，或者构成用户界面的基本单位。组件的复杂度有高有低。如果把组件的复杂度降低，变成一个单一功能的组件，比如一个按钮或者一个下拉菜单，组件的灵活性就会提高，可重用性就会增加。（这个很好理解吧，如果你把一个完整的注册表单当成一个组件，那你怎么重用它呢？再不修改的前提下，它除了作为一个注册表单之外，别的啥也干不了。）不要忘记了，你的各个组件的可重用性越高，你需要维护的东西就越少，设计的弹性就越大。
综合以上的两个方面，你会看到，基于组件的开发流程可以（其实也是必须）尽可能的增加代码的可重用性，减少开发和维护的成本；而标准则确保了组件的使用和风格不会与系统相违背。它们结合到一起，就成为产品团队的利器——设计系统，借助它，团队成员可以很好的了解每一个组件是如何定义的，并且为什么要这么定义。