谈到过去的设计系统，我先给大家讲个故事。
也许有人不太熟悉巴别塔，我简单介绍一下，巴别塔是《圣经·旧约·创世记》第11章中的一个故事，故事是这样的起初人类想要建造一座可通天的塔，在建造过程中上帝为了阻止这一计划，破坏了人类的语言，人类因为无法沟通，在建造后期困难重重，最终建造巴别塔的计划不了了之。
早期语言统一前：由于人类语言交流的效率较高，在建造塔基的时候是规则、坚固、统一的。
后期语言混乱后：由于语言交流不畅，在建造塔顶的时候显得杂乱、荒芜、无秩序。
通过巴比塔的例子，我们可以看到，自从人类的语言被打乱后，整个后半部就会变得混乱，即使只看其中一部分保持之前的基本要求，但由于彼此之间不能听懂对方的语言，后期是不可能进行搭建的，更可怕的是后期搭建也没有什么可能修复。
反观我们的产品初期由于产品体积小的原因，很多开发任务和组件都可以掌握，但随着人员规模的不断扩大，业务量的不断增加，产品后期研发人员沟通混乱的情况也越来越多，造成在产品迭代过程中状况百出，如果在错误的产品上进行迭代，很有可能最终导致整个生产线的死亡。
在设计领域我们也一直在寻找更统一的生产和协作语言，来消除我们在协作中面临沟通中的信息损耗。巴比塔就像我们的研发的产品，而设计系统就像研发人员之间沟通协作的语言。
最早的设计系统的概念出现于1919年，在1919-1933年包豪斯运动(TheBauhausMovement)时期，由路易斯沙利文提出的“形式的跟随功能”(FormFollowsFunction)理论，主张设计师应该将“组件”与“模块”的概念应用到工业和建筑设计中。
受其思想的影响，在福特时代，汽车业的“流水线式”思维已经把生产流程模块化，进而提高生产效率，形成了强大的美国汽车工业。
回顾设计本身，从模块化印刷系统开始，再用简单的规则，在大城市里建立庞大的识别系统，如机场指示牌，导航板，这些都能提高效率。
这种“组件”和“模块”的概念，一直影响着数字产业中的UI设计师，从最初的视觉语言发展到现在的设计系统。
至于在互联网领域中是怎么形成的，咱们就来看看设计系统的今生——设计系统在互联网中的进化。
设计系统形成体系是离不开“开发语言的升级和协作模式的进步的”。那开发语言是如何升级，协作模式是如何进步的呢？不着急我们往下看。
设计系统诞生的目的，是为人类更好地沟通我们的语言，就像“巴比塔”的例子一样，都是为了解决我们语言的不通的问题。
在1990年代（90年代中期），越来越多的人使用互联网和个人电脑，随着互联网web（网页）的发展，人们已经不满足枯燥信息传单的网页，在上网过程中追求更高质量的用户体验。
当时的web网页多是由HTML技术实现出来的，在1994年发布了关于CSS技术的第一个提案——为开发人员提供了一套小部件和模式的工具包（基于网页解决方案的前端工具包，供设计师和开发人员使用），去提升用户体验。但是即使使用了CSS技术，在Web网页上还必须是整个页面构建的，在实现上设计还是有局限的。
直到2002年JavaScrpit技术的出现与应用，允许开发者构建组件而不进行页面的构建，大大提高了网页布局的灵活性，使整个网页布局变得更加方便、快捷，极大地提高了网页的美观度和用户体验。正因为开发语言的升级，万维网联盟(W3C)这样的组织也得以建立。
仅仅是开发语言的升级，要解决日益庞大而复杂的产品需求是远远不够的，比如许多想要解决像阿里巴巴、字节跳动、滴滴打车这样的国际化、多平台产品需求的企业，不仅要开发适应多平台的开发语言，还要优化设计师和开发者之间的协作模式。
一开始，传统的软件开发是基于“瀑布协作模式”，从产品需求到产品开发再到产品维护，每一阶段设计者和开发人员都有需要完成的工作任务，就像福特时代的模块化生产线一样。
正是因为“瀑布协作模式”这种协作效率低下的问题出现，全新可以提升协作效率的“敏捷开发协作模式“应运而生。
*软件开发协作模式一共有四种，分别是瀑布式开发、迭代式开发、螺旋开发、敏捷开发，大家了解即可。
我们把目光聚焦在互联网中设计系统概念，设计系统在今天的环境下受到众多企业的青睐，一方面离不开“开发语言与协作模式”的发展，另一方面又解决了员工协作难的难题。实际上设计系统帮助我们解决了以下三个工作中的问题：
前面我讲的“设计系统解决了员工协作困难的难题”，那到底是哪些难题呢？我归纳如下：
·重复工作效率低：当我们在接一个重复工作需求时，我们需要找到以前的设计稿，把以前的结构整合到新的设计稿中，这对设计师来说不亚于再做一个设计稿。
·用户体验不一致：如此多相似却完全相同的功能在生产环节中又会产生第二个问题，用户体验不一致。例如在某些产品上使用粉红色的主题色，查阅设计稿，就会发现很多不同的粉红数值出现在产品上。
·产品难以迭代：当模糊的规范和组件在线上开发的大量环境中出现时，产品的迭代会非常困难。那就是我们的产品经过多次的升级，错误的代码相互依赖，给我们的迭代制造了很大的障碍。
设计系统的意义：是为了在设计我们的产品时消除信息损耗。一方面减少我们出错的机会，另一方面提高开发效率，让这些信息拥有更多的灵活性和扩展性。
在AllaKholmatova撰写的《DesignSystem》一书中，有一段是对设计体系的描述：“设计体系”是指服务于数字化产品设计的一系列具有内在关联性的、组织有序的设计模式与实践方法。这句话中有三个关键词是定义设计系统的。
数字化产品：指信息、计算机软件、视听娱乐产品等可数字化表示并可用计算机网络传输的产品，比如网页、APP、车载产品等。
模式：指产品界面中可重复使用的元素，包括按钮、文本框、图标、配色、字体、功能流程及交互行为等。
简而言之，设计系统是通过一系列有条理的、相互关联的模式和共享的实践来实现数字产品的目标。在数字行业互联网领域中，设计系统就是一系列可用的组件以及他们的使用指南的组合。
国外的“DesignSystem”在中国的互联网中有两种称呼分别是设计系统和设计体系。一开始我也对这两个叫法感到困惑，我参考了国外的资料，现在来谈谈设计体系与设计系统的区别。
体系概念：英文为structure，泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体，是不同系统构成的系统。
系统概念：英文为system，形容若干部分相互联系、相互作用，形成的具有某些功能的整体。
由于这个概念是从国外传到国内的，前端开发则翻译为“体系”，而国外的设计师翻译为“系统”两者在本质上的意义并无差别，只是职位不同叫法不同而已。具体地落实到表现层上的产物就是前端开发人员维护的开发组件库和设计师维护的设计组件库。
无论是设计者所称的系统，还是前端开发所谓的体系，最为重要的是要理解“DesignSystem”的概念不单单是一堆UI组件，更不是UI设计或者前端开发单独完成的事情，而是应该理解为“是一种思维，设计师与前端开发沟通的一种语言，正是因为有这种语言的联系才能促成优秀产品的诞生。
我们总结一下设计系统的概念～
为了给用户带来良好的用户体验，设计系统是其中的一个重要环节，一组基本设计体系大致包括风格、内容、基础、组件、模式5大部分，其中的基础与组件又是我们身为设计师接触最频繁的两个部分。
谈到风格，相信大家都不会陌生，像设计语言一样，设计原理讲的都是风格问题。许多设计系统网站上，都可以看到企业对设计系统风格的标注说明。
风格应用在创建界面或其他设计交付物阶段的时候对视觉参考和设计原则的品牌风格的指导。风格部分主要承担着两个主要的任务：
·对内部：对设计师来说需要自己梳理产品应该具有什么样的风格个性，产品外观为什么要设计成这种风格(风格)。
·对外部：对于外部用户来说，如何将企业品牌形象有效地传递给用户是风格的使命。
一些企业在产品手册中会强调“一致性”的设计原则，比如美团外卖这款产品，不管是线下的物料宣传还是线上产品，都大量采用了“黄色”这个颜色，为团队设计提供清晰的设计指导，让用户的感官标准一致，感受到“一致性”的设计理念。
内容指的是我们在产品界面中使用的文案，也就是人们常说的“微文本”，一些影音产品还会注重其文案的语气、语调，并根据用户的属性为设计成员编写词汇用法表，避免设计文案时给用户带来的焦虑情绪。
许多产品在内容设计上都花了不少心思，比如即刻APP的弹窗设计，新版本的弹窗则用更有趣、更易懂的文案“保存并继续”来取代枯燥乏味“一下步”的文案，并且跟随一小段“请根据提示引导完成后续操作”的提示，清楚地引导用户进行操作。
假如你认为内容的改版仅仅是提升体验，那么你就错了，有这样一个典型的案例会给企业带来巨大的收益，比如在Google酒店搜索中，一开始用“Bookaroom(预定房间)”这个词来吸引用户点击，随后的改版中将“Bookaroom(预定房间)”修改为“CheckAvailability(查看可用房间)”后，成功地将这一功能的交互点击率提升17%。所以说内容（微文案）改版不仅仅提升用户的体验，还可以给产品带来数据的提升，从而带动企业收益的增长。
基础可以理解为是设计表现层当中最小颗粒度的合集，简单地理解就是将一页中的元素不断地拆解，拆解到无法拆解的状态之后，剩下的元素就是“基础”，比如字体、颜色、图标、布局(间距)、声音、动效等等。
组件也称之为组件库，组件库是身为设计师接触最多的事物，也是设计系统的灵魂所在了，主要可以分为设计组件库和代码组件库这两个大部分。
重点推荐Bit.dev，这是一种由第三方组件构建的平台，他有一个叫做组件共享的功能，即当鼠标悬停在一个组件上时，会产生高亮状态，以提示该组件的名称、版本和父区域。
一套完整的设计组件库一般是由公共组件和业务组件构成的，它和设计系统一样，只是作为参考的规范使用，组件库也是要根据业务进行微调整，需要不断地进行优化的，所以并不是一尘不变的。
随着业务和产品的数量增多，公共组件库的数量也一定会增加，因此搭建组件库时候有两个问题特别值得注意：
注意点一：在组件库搭建时候尤其要注意公共组件库的使用效率问题，如果使用率较低的组件总是出现，那么公共组件库就会很臃肿，所以要及时去除不通用的组件保留常用组件。
注意点二：公共和业务组件并不是越多越好，盲目地追求“大而全”一定是不可取的，要时刻提醒自己“合适的组件库要比全面的组件库更为重要”。
模式这个词大家刚一听到可以会有点陌生，其实早期在《1975NASAGraphicsStandardsManual》手册中模式这一概念产生。现在也常被人称呼为感知模式或者是设计规范。
对此大家不必了解得那么深入，一句话就可以概括了“为了避免重复造轮子，就搞了几个通用的流程，以保证产品开发流程的效能问题”这里的模式可以被简单地理解为习惯使用的解决方案，即设计团队给用户在我们的产品中完成一系列操作的使用说明书，它可以是一个模型或者用户的习惯。
当然了模式其实也包括对组件的交互说明，比如我建立一个按钮的组件就会把按钮的尺寸、交互状态等信息编辑成文档用于对设计组件库的说明。
很多新手认为，设计系统像是一个新华字典是万能的，其实不是的。有5点常见的认知误区，我觉得还是有必要聊一聊。
为什么会这样呢？主要的原因就是模式（设计规范）、组件（开发组件库）和设计系统三者的目标是一致的，都是可以解决提高设计产品一致性、提高设计效率、降低与前端开发沟通成本这三个问题，所以容易搞混淆。
如果把三者中从功能的角度对比看，只有设计系统是带有实施的方案的性质，而设计规范具有指导性质，而组件则是构建其规范的元素。
有人会提议设计系统为了提高效率都会做规范性的说明，那是不是设计系统一旦实施就会给抹杀掉产品的创造性呢？这得分两个角度看：
角度一：不好的设计系统只会照猫画虎不会考虑从产品业务和用户体验的角度出发去设计“设计系统”，当然会抹杀掉创造性。
设计系统是一个庞大的关系网络，是需要来自不同角色支持和参与的，这里包括前端、UI设计、品牌设计、动态设计、用户研究等。并不是由一个人或者是几个人独立完成的，设计团队的成员都应积极参与。
大家都参与到设计系统的搭建，最重要的意义就是有助于提高对设计系的认知，从而帮助设计系统执行落地。有一次我就是一个人制定了设计系统中的规范，只是单纯把规范发给其他设计人员，可想而知，其他设计人员自然不会使用规范，对里面的设计元素没有加深理解，最终项目呈现不是很理想，所以设计系统并不是一个人完成，也不能让一个人去完成。
设计系统是需要迭代优化的，这是非常繁琐耗时的项目。设计体系专家NathanCurtis（2015）和Salesforce的JinaAnne（2015）提出了独裁模式、集中化模式与联盟模式三种模式适应不同规模的企业。
所以说，设计系统不是每个企业都需要的，不管是大公司还是小公司搭建设计系统时候，选择自己适合的方式最为重要。
Corinna在2018年发表的“为什么我们的模式库不再使用原子设计”一文中，也提到了原子设计在落地时的局限性，他提到，过度地依赖层层递进的关系，会导致整个系统会变得极其复杂而难以维护，一旦开始使用，后续的迭代和重构成本会非常高。
通过以上两个章节对设计系统的学习，相信大家在脑海中对设计系统应该会有一个全面的认知，其实构建一套设计系统也很简单，就四个字“开眼&借鉴”。
开眼：我们需要将设计系统作为设计师的学习工具，学习如何设计系统，探索最佳实践和原理。
借鉴：世界上最好的公司已经推出了最好的设计系统，聪明的设计师们知道如何利用设计系统(经验)借鉴与自己产品相似的部分来应用于自己的工作流程。
整体来看，在设计体系上，国外在这方面都是先铺开的，但是随着这几年国内互联网的蓬勃发展，很多国内的设计团队也开始构建适合他们自己企业业务的设计系统，下面我们来看看国内国外有哪些值得我们学习的系统。
在国外系统有很多，像苹果HIG设计系统,IBMCarbon设计系统,SalesforceLightning设计系统,spectrum设计系统、AdobeSpectrum设计系统等，这些优秀的设计系统都为企业的各个产品提供了指导，这里我推荐三款比较有代表性的系统：
·Windows：微软设计系统包括人机界面布局、控件、样式及资源下载，最大的特点就是全面，通过开源组件生态系统可以帮助在Web，Windows，iOS和Android平台上创建一致的目标。
比如我们在做文案比较多的设计时候完全就可以参考他们的内容规范，进行有针对性地设计，从而提升用户的使用体验。
目前，国内的互联网企业率先开展了技术上的大量投资和新的资源配置，开始把设计系统作为提升内部效率的重要工具之一，比如鸿蒙设计组件库、有赞设计系统等。
今年是B端市场大火的一年，常规的设计组件库我就不推荐了，我就推荐两个我觉得作为工具使用最好的三款组件库。
举一个例子，即使设计稿全部使用了AntDesign的组件库搭建，在产品上线时候会发现最终的产品的用户体验并不完善，这时候Layui就派上用场，因为Layui当初建立的时候就是在AntDesign基础上根据蚂蚁自己的业务需求提炼、组合、封装的组件库，也就是说LayuI不仅有组件库还有其交互功能的演示功能。
做组件库最重要的就是要针对公司不同的业务类型，沉淀出不同级别的组件，而AntDesign和Layui搭配的使用才能让组件使用起来更加顺手，所以在做组件库时候不能只盯着AntDesign也要学会像Layui一样，理解业务需求搭建符合业务需求的组件库。
·AntDesign：企业级的设计系统，很多公司项目都在使用，适用于所有人，通用的原子级别的组件库（比如一个输入框一个按钮）。
其实前面我讲到了设计系统并不是简单的“开发组件库或者设计规范”，但是大家要知道“开发组件库或者设计规范（以下简称公共组件）”是我们身为设计师接触最多的一个工具，那是因为我们正享受在以构建一个以公共组件为驱动方式的设计系统的潮流中。
像是谷歌的MaterialDesign系统、微软的MicrosoftFluent、华为的鸿蒙设计系统等都是因为这个原因而兴起的。
设计师和前端开发之间的同步，几乎是每个设计系统在实现过程中最为头疼的事情了，虽然设计系统建立了一套标准的沟通语言，但是还缺少一套沟通的方法，而组件库就是这个沟通的方法。
举一个例子，设计师给一个设计稿是由8个元素拼装成的，但是前端开发觉得需要10个元素才能拼装成功。虽然沟通语言是一样，但是沟通方法不一样（也就是设计师和前端的实现方法不一样），但是把已经封装好的组件当作沟通方法的话，设计师和前端开发看到的将不是元素而是一个个的组件，那实现出来的产品在信息框、视觉表达、交互体验都一致，这一点和建立设计系统的初衷是一样的。把封装好的组件当成沟通方法，这种做法的好处主要有两点，第一点就是可以保证用户体验是一致，第二点就是可以提高开发效率。
保证体验一致：可保证开发出来的产品在设计风格和交互体验上都保持一致，对于设计师进行设计效果的还原也方便许多。
提高开发效率：方便设计师和开发人员之间的交接协作效率，从而帮助系统剔除重复不必要的组件提高开发产能效率，使开发更加便捷。
在互联网中经常会听到“前台、中台、后台”的概念，很多人会和设计系统的概念相混淆。
对于设计系统，我们最熟悉和常用的应该就是设计组件了，即UIkits，包括输入框、按钮、文字、链接、下拉菜单等等。作为构成一个界面的最小元素，UIkits可以理解成这些最小元素的常用集合体的称呼。下一步，我将使用figma这个软件，教大家如何使用Component的功能。
在Sketch的时代，团队设计师的协作方式是通过一个本地的Sketch规范文件，以复制粘贴的方式来复用一些元素和控件，但是随着项目的不断发展，设计师之间的协作也越来越多，使用Sketch软件管理组件库的协同不及时的问题就暴露了出来了。
Sketch软件管理组件库的方式很难及时地通知协同的同事，需要口头通知或者在工作群中告知大家更新了新组件库文件，很多手头上多条业务线并行的设计师常常会忽略更新组件库的通知，造成组件库不同步，更有甚者需要在长长的聊天记录中寻找更新的信息，费时又费力。
也许有人会说，Sketch有个自动进行提醒功能，一旦有更新，就会在右上角显示一条提示信息，设计师只需要点击提醒，下载最新组件文件即可完成更新。但是这个功能在强大的figma软件面前还是显得微不足道。
正是因为Sketch的短板，设计师迫切需要一款云协作软件来降低通信和协作成本。多人协作算是figma的特色功能，可以在自己的操作界面实时看到别的角色是在做什么操作。
figma每一次功能更新在社区里面都会有playgroud，相当于将每一次更新的功能变成一个个小案例，经过自己的实际操作后，更新的功能其实也就学会了，可以应用到自己的实际工作之中，非常实用。
figma作为一款划时代的产品，我总结四点优势：
·它以多人协作为核心功能，主打线上多人协作；
·无论你是Mac还是windows系统都可以使用；
·不管是界面设计还是原型制作都可以做到；
·还有强大的社区资源可以借鉴。
一谈到设计组件库，就不得不说“原子设计理论”，这套理论是在2013年，由前端开发工程师BradForst在《AtomicDesign》一书中提及的概念，在化学世界中，所有的物质都是由原子构成，原子组合构成分子，分子组合构成有机物，最终形成宇宙万物。
原子设计理论的出现就是为了帮助我们去搭建设计系统，BradForst从化学学科类吸取知识，认为设计组件应该5个层面内容构成：原子、分子、组织、模版和页面，通过这5个层面构建一张产品界面。
原子：指的是最小的单位，比如颜色、字号、图标等。
分子：指由两个或多个原子组装而成具有功能性的组件，比如搜索框、tab栏等。
组织：指分子和原子组成的更大组装体，比如详情模块、内容信息区域等。
模版：指区域模版构成的页面模版，比如产品的详情页、列表页、异常页等。
页面：指模板在设计师和工程师的协作下，变成实际的页面。
在Sketch中组件的功能是“Symbol”，在figma中则是“Componer”，其功能是一样的只是两款软件的叫法不同。以下是我整理“Componer”四点基础知识。
在figma中创建组件有两种方法；
第一种：鼠标选中将要组件化的元素，这时顶部工具栏由一个功能键变成了两个功能键，点击“GreateComponer”的功能键，元素由灰色边框变成紫色边框，即创建成功。
第二种：鼠标选中将要组件化的元素，按快捷键“command+option+k”，即创建成功。*我比较推荐使用第二种方法，毕竟快捷键可以提高我们做图的效率。
组件有两个级别，我们可以根据图标的样式进行区分，四个实心菱形样式的图标就是父级、一个空心菱形样式的图标就是子级。
将父级组件变成子级的组件有两种方法：
第一种：按住已经组件化的元素，按住“option”鼠标不放，将父级元素拖动到空白处，就会出现子级元素。
第二种：或者是按快捷“command+d”也会在旁边出现一个子级组件。
正是因为父级的组件是可以覆盖子级组件的样式，当我们去更改父级里面一个元素，比如是颜色，那子级里面的元素就会跟着改变。
但是子级组件的更改样式，父级的组件将不会受到影响，比如我更改子级组件的圆角度由0改成100，你可以看到父级组件样式没有受到影响。
除了这个关系，子组件也是可以清除样式的回归到父级组件最原始的样式，比如选中子级组件为他更改颜色和圆角度数，点击“resrtoverrrides”即可去除所有组件样式。
当然，新的样式也是可以同步到之前老样式的组件，只需要选中新样式的组件，点击“pushoverridestomaincomponent”，之前所有的组件将采用新的样式
取消组件状态的快捷键也是有的，只要按住“command+option+b”就可以了。
假设你的老板对弹窗界面的按钮样式不满意，要求由直角改成圆角，这个时候只需要更改父级别组件的圆角，页面中所有子级组件将统一都改成圆角，大大地提高了工作效率。
组件的基础功能都讲清楚了，接下来对组件管理的知识点进行讲解，我个人理解这一部分也是很重要了，因为我以下讲解的四个部分内容是环环相扣的，只有做好前一步下一步才可以顺利进行。
首先就是大家容易忽略的问题，很多人对组件的命名没有规律，以至于在第二步调用组件的时候困难重重。
我建议使用「/」来为组件命名，用于给组件进行分类，这样可以帮助figma判断组件内元素的层级，如图
命名好了之后，可以点击“assts”输入你命名的组件名称就可以找到组件了。比如我搜索“icon”，就可以找到所有命名为icon的组件了。
这里有一个技巧，如果你在创建组件的时候，在“component”这里对这个组件进行了简短的文字描述说明，点击“assts”搜索的时候组件的旁边就会出现气泡弹窗，弹窗的内容可以让你清楚地知道组件是干什么用的，针对于组件数量特别多的系统，很好用。
当我们把元素都制作成组件后，就可以进行组件的嵌套了也就是“巢状元件”，也就是说一个组件可以包含另外一个组件。比如下面这个按钮是icon和文字构成的（紫色是父级、蓝色是子级），在父级中我们可以随意地更改icon的数量，来改变子级的样式。
正是因为有前两步规范的组件命名和组件嵌套，我们在搭建页面时候可以轻松自如地根据组件的命名，随意地替换组件的样式。
或者是在一个按钮组件的基础上，根据icon的命名替换成符合需求功能的不同按钮。
比如下面这个场景中的tab栏，将按钮将由两个替换成一，或者是更改主题颜色等等业务需求都可以通过组件替换功能去实现。
最后，设计系统需要根据团队、项目的实际情况灵活运营，切勿生搬硬套。
[1]《设计体系：数字产品设计的系统化方法》
[2]《AtomicDesign》，BradFrost，2013.
[3]《设计体系指南书》
[4]《B端设计师可能被组件库取代吗？》
[5]《设计要知道-入局车载的最好路径，高质量十问十答！》