微信扫码登录 | 方便安全省心
斜杠7湿兄
2021年11月15日 发布 / 619 次阅读
近几年来，许多企业都在关注设计系统，我也有幸参与了公司设计系统的改造升级。一提起设计系统，你会想到什么？是设计组件？设计规范？方法论？还是页面模板？可能有80%的设计师并不一定清楚设计系统的具体含义。
本文就围绕这段时间我对设计系统的认识和体会，谈一谈「设计系统」的话题。
谈到过去的设计系统，我先给大家讲个故事。
也许有人不太熟悉巴别塔，我简单介绍一下，巴别塔是《圣经·旧约·创世记》第11章中的一个故事，故事是这样的起初人类想要建造一座可通天的塔，在建造过程中上帝为了阻止这一计划，破坏了人类的语言，人类因为无法沟通，在建造后期困难重重，最终建造巴别塔的计划不了了之。
早期语言统一前：由于人类语言交流的效率较高，在建造塔基的时候是规则、坚固、统一的。
后期语言混乱后：由于语言交流不畅，在建造塔顶的时候显得杂乱、荒芜、无秩序。
通过巴比塔的例子，我们可以看到，自从人类的语言被打乱后，整个后半部就会变得混乱，即使只看其中一部分保持之前的基本要求，但由于彼此之间不能听懂对方的语言，后期是不可能进行搭建的，更可怕的是后期搭建也没有什么可能修复。
反观我们的产品初期由于产品体积小的原因，很多开发任务和组件都可以掌握，但随着人员规模的不断扩大，业务量的不断增加，产品后期研发人员沟通混乱的情况也越来越多，造成在产品迭代过程中状况百出，如果在错误的产品上进行迭代，很有可能最终导致整个生产线的死亡。
在设计领域我们也一直在寻找更统一的生产和协作语言，来消除我们在协作中面临沟通中的信息损耗。巴比塔就像我们的研发的产品，而设计系统就像研发人员之间沟通协作的语言。
最早的设计系统的概念出现于1919年，在1919-1933年包豪斯运动(The Bauhaus Movement)时期，由路易斯沙利文提出的“形式的跟随功能”(Form Follows Function)理论，主张设计师应该将“组件”与“模块”的概念应用到工业和建筑设计中。
受其思想的影响，在福特时代，汽车业的“流水线式”思维已经把生产流程模块化，进而提高生产效率，形成了强大的美国汽车工业。
回顾设计本身，从模块化印刷系统开始，再用简单的规则，在大城市里建立庞大的识别系统，如机场指示牌，导航板，这些都能提高效率。
这种“组件”和“模块”的概念，一直影响着数字产业中的UI设计师，从最初的视觉语言发展到现在的设计系统。
至于在互联网领域中是怎么形成的，咱们就来看看设计系统的今生——设计系统在互联网中的进化。
设计系统形成体系是离不开“开发语言的升级和协作模式的进步的”。那开发语言是如何升级，协作模式是如何进步的呢？不着急我们往下看。
设计系统诞生的目的，是为人类更好地沟通我们的语言，就像“巴比塔”的例子一样，都是为了解决我们语言的不通的问题。
在1990年代（90年代中期），越来越多的人使用互联网和个人电脑，随着互联网web（网页）的发展，人们已经不满足枯燥信息传单的网页，在上网过程中追求更高质量的用户体验。
当时的web网页多是由HTML 技术实现出来的，在1994年发布了关于CSS技术的第一个提案——为开发人员提供了一套小部件和模式的工具包（基于网页解决方案的前端工具包，供设计师和开发人员使用），去提升用户体验。但是即使使用了CSS技术，在Web网页上还必须是整个页面构建的，在实现上设计还是有局限的。
直到2002年JavaScrpit技术的出现与应用，允许开发者构建组件而不进行页面的构建，大大提高了网页布局的灵活性，使整个网页布局变得更加方便、快捷，极大地提高了网页的美观度和用户体验。正因为开发语言的升级，万维网联盟(W3C)这样的组织也得以建立。
仅仅是开发语言的升级，要解决日益庞大而复杂的产品需求是远远不够的，比如许多想要解决像阿里巴巴、字节跳动、滴滴打车这样的国际化、多平台产品需求的企业，不仅要开发适应多平台的开发语言，还要优化设计师和开发者之间的协作模式。
一开始，传统的软件开发是基于“瀑布协作模式”，从产品需求到产品开发再到产品维护，每一阶段设计者和开发人员都有需要完成的工作任务，就像福特时代的模块化生产线一样。
这种协作模式虽然提高了开发效率，但也存在着缺点，因为是流水线的协作模式，一旦流程中出现问题，就要进行“返回操作”，回到上一段去做修改，如90年代的微软开发系统就是这样，要纠正产品中的问题，流水线的步骤就要从头走一遍，将系统刻入光盘，再通过电脑读写升级系统，从需求到任务分发最长可能要一年多的时间，再通过电脑读写升级系统，又需要一年多的时间，所以两者之间产生难以逾越的沟通协作效率低下的问题。
正是因为“瀑布协作模式”这种协作效率低下的问题出现，全新可以提升协作效率的“敏捷开发协作模式“应运而生。
敏捷开发的宗旨是提高团队成员的协作效率，消除设计师和开发成员之间的沟通障碍，让设计师和开发成员有更多的时间去做自己领域的事情，即使是出现了问题在各自领域进行修改，比如现如今的苹果系统的升级只需要通过云端进行系统的升级。
*软件开发协作模式一共有四种，分别是瀑布式开发、迭代式开发、螺旋开发、敏捷开发，大家了解即可。
我们把目光聚焦在互联网中设计系统概念，设计系统在今天的环境下受到众多企业的青睐，一方面离不开“开发语言与协作模式”的发展，另一方面又解决了员工协作难的难题。实际上设计系统帮助我们解决了以下三个工作中的问题：
前面我讲的“设计系统解决了员工协作困难的难题”，那到底是哪些难题呢？我归纳如下：
·重复工作效率低：当我们在接一个重复工作需求时，我们需要找到以前的设计稿，把以前的结构整合到新的设计稿中，这对设计师来说不亚于再做一个设计稿。
·用户体验不一致：如此多相似却完全相同的功能在生产环节中又会产生第二个问题，用户体验不一致。例如在某些产品上使用粉红色的主题色，查阅设计稿，就会发现很多不同的粉红数值出现在产品上。
·产品难以迭代：当模糊的规范和组件在线上开发的大量环境中出现时，产品的迭代会非常困难。那就是我们的产品经过多次的升级，错误的代码相互依赖，给我们的迭代制造了很大的障碍。
设计系统的意义：是为了在设计我们的产品时消除信息损耗。一方面减少我们出错的机会，另一方面提高开发效率，让这些信息拥有更多的灵活性和扩展性。
在Alla Kholmatova撰写的《Design System》一书中，有一段是对设计体系的描述：“设计体系”是指服务于数字化产品设计的一系列具有内在关联性的、组织有序的设计模式与实践方法。这句话中有三个关键词是定义设计系统的。
数字化产品：指信息、计算机软件、视听娱乐产品等可数字化表示并可用计算机网络传输的产品，比如网页、APP、车载产品等。
模式：指产品界面中可重复使用的元素，包括按钮、文本框、图标、配色、字体、功能流程及交互行为等。
实践：指关于如何在团队中创造、完善、使用和分享研究的设计准则。
简而言之，设计系统是通过一系列有条理的、相互关联的模式和共享的实践来实现数字产品的目标。在数字行业互联网领域中，设计系统就是一系列可用的组件以及他们的使用指南的组合。
国外的“Design System”在中国的互联网中有两种称呼分别是设计系统和设计体系。一开始我也对这两个叫法感到困惑，我参考了国外的资料，现在来谈谈设计体系与设计系统的区别。
体系概念：英文为structure，泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体，是不同系统构成的系统。
系统概念：英文为system，形容若干部分相互联系、相互作用，形成的具有某些功能的整体。
由于这个概念是从国外传到国内的，前端开发则翻译为“体系”，而国外的设计师翻译为“系统”两者在本质上的意义并无差别，只是职位不同叫法不同而已。具体地落实到表现层上的产物就是前端开发人员维护的开发组件库和设计师维护的设计组件库。
无论是设计者所称的系统，还是前端开发所谓的体系，最为重要的是要理解“Design System”的概念不单单是一堆UI组件，更不是UI设计或者前端开发单独完成的事情，而是应该理解为“是一种思维，设计师与前端开发沟通的一种语言，正是因为有这种语言的联系才能促成优秀产品的诞生。
我们总结一下设计系统的概念～
为了给用户带来良好的用户体验，设计系统是其中的一个重要环节，一组基本设计体系大致包括风格、内容、基础、组件、模式5大部分，其中的基础与组件又是我们身为设计师接触最频繁的两个部分。
谈到风格，相信大家都不会陌生，像设计语言一样，设计原理讲的都是风格问题。许多设计系统网站上，都可以看到企业对设计系统风格的标注说明。
风格应用在创建界面或其他设计交付物阶段的时候对视觉参考和设计原则的品牌风格的指导。风格部分主要承担着两个主要的任务：
·对内部：对设计师来说需要自己梳理产品应该具有什么样的风格个性，产品外观为什么要设计成这种风格(风格)。
·对外部：对于外部用户来说，如何将企业品牌形象有效地传递给用户是风格的使命。
总之，好的品牌风格能够对内辐射产品定位，对外辐射企业的宣传推广。很多设计系统中都会有对风格的定义，像国外的苹果设计系统的风格语言定义为“完整，一致，简约”，国内的贝壳设计系统风格语言定义为“生长、触摸、关联”。
一些企业在产品手册中会强调“一致性”的设计原则，比如美团外卖这款产品，不管是线下的物料宣传还是线上产品，都大量采用了“黄色”这个颜色，为团队设计提供清晰的设计指导，让用户的感官标准一致，感受到“一致性”的设计理念。
内容指的是我们在产品界面中使用的文案，也就是人们常说的“微文本”，一些影音产品还会注重其文案的语气、语调，并根据用户的属性为设计成员编写词汇用法表，避免设计文案时给用户带来的焦虑情绪。
许多产品在内容设计上都花了不少心思，比如即刻APP的弹窗设计，新版本的弹窗则用更有趣、更易懂的文案“保存并继续”来取代枯燥乏味“一下步”的文案，并且跟随一小段“请根据提示引导完成后续操作”的提示，清楚地引导用户进行操作。
再比如哔哩哔哩这款产品，在输入密码的场景中，根据用户输入密码的场景选择了合适的表达方式，当用户输入登录密码时，产品的吉祥物就会将眼睛捂住，这样的设计不仅能很好地表达产品的个性，也能传达产品的温度。
假如你认为内容的改版仅仅是提升体验，那么你就错了，有这样一个典型的案例会给企业带来巨大的收益，比如在 Google酒店搜索中，一开始用“Book a room (预定房间)”这个词来吸引用户点击，随后的改版中将“Book a room (预定房间)”修改为“Check Availability (查看可用房间)”后，成功地将这一功能的交互点击率提升17%。所以说内容（微文案）改版不仅仅提升用户的体验，还可以给产品带来数据的提升，从而带动企业收益的增长。
基础可以理解为是设计表现层当中最小颗粒度的合集，简单地理解就是将一页中的元素不断地拆解，拆解到无法拆解的状态之后，剩下的元素就是“基础”，比如字体、颜色、图标、布局(间距)、声音、动效等等。
“基础”的搭建马虎不得，因为他是最小的构件，应该用最科学的方法来设计。例如在搭配颜色这个元素时，我们可以采用拓展公式计算方法、手工叠加、公式计算、色彩曲线工具等方法来设定精确的色值。
组件也称之为组件库，组件库是身为设计师接触最多的事物，也是设计系统的灵魂所在了，主要可以分为设计组件库和代码组件库这两个大部分。
设计组件库相信大家都不会陌生，这里我推荐两个工具网站semantic-ui.和tetrisly，尤其是tetrisly它包含Sketch与Figma的组件使用很方便。
代码组件库主要是前端开发人员使用，会有一些代码规范的说明。这里我推荐QMUI工具和Bit.dev两款工具。
重点推荐Bit.dev，这是一种由第三方组件构建的平台，他有一个叫做组件共享的功能，即当鼠标悬停在一个组件上时，会产生高亮状态，以提示该组件的名称、版本和父区域。
假设鼠标点击按钮此组件时，还将跳转到相关联页中显示这些按钮组件的范围，有兴趣的同学可以体验一下。
一套完整的设计组件库一般是由公共组件和业务组件构成的，它和设计系统一样，只是作为参考的规范使用，组件库也是要根据业务进行微调整，需要不断地进行优化的，所以并不是一尘不变的。
随着业务和产品的数量增多，公共组件库的数量也一定会增加，因此搭建组件库时候有两个问题特别值得注意：
注意点一：在组件库搭建时候尤其要注意公共组件库的使用效率问题，如果使用率较低的组件总是出现，那么公共组件库就会很臃肿，所以要及时去除不通用的组件保留常用组件。
注意点二：公共和业务组件并不是越多越好，盲目地追求“大而全”一定是不可取的，要时刻提醒自己“合适的组件库要比全面的组件库更为重要”。
模式这个词大家刚一听到可以会有点陌生，其实早期在《1975 NASA Graphics Standards Manual》 手册中模式这一概念产生。现在也常被人称呼为感知模式或者是设计规范。
对此大家不必了解得那么深入，一句话就可以概括了“为了避免重复造轮子，就搞了几个通用的流程，以保证产品开发流程的效能问题”这里的模式可以被简单地理解为习惯使用的解决方案，即设计团队给用户在我们的产品中完成一系列操作的使用说明书，它可以是一个模型或者用户的习惯。
比方说，发送语音时我们都要按住按钮，进行语音记录，如果我们对产品有类似的语音对话功能，可以直接使用微信的交互逻辑，不用自己发明新的交互逻辑，这样做的好处就是降低用户的学习成本。看一下华为鸿蒙设计系统，就会有关于交互手势规范说明的注释。
当然了模式其实也包括对组件的交互说明，比如我建立一个按钮的组件就会把按钮的尺寸、交互状态等信息编辑成文档用于对设计组件库的说明。
很多新手认为，设计系统像是一个新华字典是万能的，其实不是的。有5点常见的认知误区，我觉得还是有必要聊一聊。
那些说自己完成了设计系统的开发的人员都是把设计规范或者开发组件库理解成设计系统的人。80%的人都会将设计系统简单地理解为模式（设计规范）或者组件（开发组件库），这种理解是片面的，设计系统并不是单纯的指某一类内容，准确的来说他并不是只包含设计规范和开发组件库。比如像Bootstrao这样的开发组件库开源网站就不是设计系统，因为他缺少对产品风格、内容、模式的定义。准确地来说，设计系统是包含模式（设计规范）、组件（开发组件库），如图
为什么会这样呢？主要的原因就是模式（设计规范）、组件（开发组件库）和设计系统三者的目标是一致的，都是可以解决提高设计产品一致性、提高设计效率、降低与前端开发沟通成本这三个问题，所以容易搞混淆。
如果把三者中从功能的角度对比看，只有设计系统是带有实施的方案的性质，而设计规范具有指导性质，而组件则是构建其规范的元素。
有人会提议设计系统为了提高效率都会做规范性的说明，那是不是设计系统一旦实施就会给抹杀掉产品的创造性呢？这得分两个角度看：
角度一：不好的设计系统只会照猫画虎不会考虑从产品业务和用户体验的角度出发去设计“设计系统”，当然会抹杀掉创造性。
角度二：但是好的设计系统往往会促进产品的创造性，因为好的设计系统都是围绕解决问题而出发，产品的问题根据时间的推移会层出不穷，那能解决产品问题的设计系统又怎么会缺少创造性呢？所以说要严格执行设计系统的内容这样企业搭建的设计系统才不会缺乏创造性。
设计系统是一个庞大的关系网络，是需要来自不同角色支持和参与的，这里包括前端、UI设计、品牌设计、动态设计、 用户研究等。并不是由一个人或者是几个人独立完成的，设计团队的成员都应积极参与。
大家都参与到设计系统的搭建，最重要的意义就是有助于提高对设计系的认知，从而帮助设计系统执行落地。有一次我就是一个人制定了设计系统中的规范，只是单纯把规范发给其他设计人员，可想而知，其他设计人员自然不会使用规范，对里面的设计元素没有加深理解，最终项目呈现不是很理想，所以设计系统并不是一个人完成，也不能让一个人去完成。
设计系统是需要迭代优化的，这是非常繁琐耗时的项目。设计体系专家Nathan Curtis（2015）和Salesforce的Jina Anne（2015）提出了独裁模式、集中化模式与联盟模式三种模式适应不同规模的企业。
对小规模的公司：比如只有几个人公司，团队可能根本就不需要设计系统。如果强行使用设计系统的话只会让开发模式变得不够敏捷，影响产品上线时间。
对成规模的公司：起初，设计系统只需要几个人抽出部分时间兼职维护（独裁模式）；后来需要指派专门的人来全职维护（集中化模式），直到最后会组建出一支由设计师，工程师和产品经理组成的大团队来不断改进和维护（联盟模式）。
所以说，设计系统不是每个企业都需要的，不管是大公司还是小公司搭建设计系统时候，选择自己适合的方式最为重要。
Corinna在2018年发表的“为什么我们的模式库不再使用原子设计”一文中，也提到了原子设计在落地时的局限性，他提到，过度地依赖层层递进的关系，会导致整个系统会变得极其复杂而难以维护，一旦开始使用，后续的迭代和重构成本会非常高。
设计系统是随着团队和用户的需求不断变化的，所以说设计系统是动态地不断需要不断更新升级，为解决更多产品问题而存在的，我们需要花时间去维护更新，使之越来越完善，越来越高效。比如大型的设计系统都有更新日志，记录那个阶段做了哪些更新。
@斜杠7湿兄 授权黑马家族发布，同步更新51学设计网
