一次搭建设计系统的尝试和思考

👇文末可下载组件库资源试用～

第一次接触到“组件库”，设计系统的概念，是在大学实习的时候。当时刚刚开始使用sketch进行界面设计工作，公司的设计师前辈说了一句令我印象深刻的话，“组件功能是sketch的精髓，一定要用好”。从此往后，我就开始不断尝试在工作中使用这一功能，并让它对我的工作发挥正面、积极的作用。

正式步入工作之后，我逐渐有机会设计较大规模的后台网页项目。在这个过程中，由于前端工程师主要使用element UI进行开发，我也开始想要自己搭建一个基于element UI的设计系统，用来加速和规范自己的设计工作。从最开始的草稿，到后面系统化地归纳和整理，时至今日我终于独立完成了这个项目。下面，我会叙述这个过程当中我的感受和收获，做一个阶段性的总结。

需要说明的是，关于搭建设计系统，我仍然是第一次尝试，经验并不丰富。最后的成品，尚未经过大规模，长时间的实际使用检验。所以，以下观点和设计系统文件当中，可能存在很多不成熟，不完善的地方。由于个人精力有限，且制作组件库的初衷为工作实用，所以在规范性、全面性等方面会有所欠缺，也难以撰写并维护全面的使用文档。希望读者可以理解这些因素，批判地看待以下成果。本人也十分欢迎友善的交流和提问，如果您使用了我的组件库，遇到任何问题，可以随时向我留言。

为什么搭建设计系统？

对于很多设计师而言，可能并不理解另一些设计师对于设计系统的执着。毕竟，即使不搭建设计系统，平时的工作也可以很好地完成。而组件库什么，难道不是前端更应该重视的概念吗？这种说法不能说有错。设计系统也不是万能的，但在很多场景中，它确实可以体现出自己的作用。

首要的，就是提高工作的效率和质量。设计系统让我们最大化地重复利用设计好的元件，同时以一种非常准确清晰的方式与开发人员对接。在同一个组件库/设计系统下，设计和开发双方能够以相当简单的语句确认组件的功能和限制，而不需要针对每一个模块都撰写长篇大论的说明。同时，面对长周期、大规模的项目，设计系统也可以帮助我很好地保持一致性，确保设计在风格和质量上的统一。

第二点，搭建设计系统对个人的思维而言是一种变革。在这次尝试之前，面对一个界面，我很容易按照平面设计的思维去看待问题。比如孤立地处理页面上的图片、文字等元素。而在这次尝试之后，界面元素的模块结构在我眼中开始变得越来越清晰，在平面设计的观点之外，程序本身的结构性和存在感会变得越来越强。而在这个过程中同样受到锻炼的归类、抽象等思维能力也是很有帮助的。

第三点，设计系统指向的是一个设计工程化，或者从另一个角度上来说，编程可视化的未来。设计与开发的无缝对接，必然会降低未来软件开发的门槛，但同时这也意味着设计师会承担和考虑更多的东西。我个人非常愿意参与到这个过程当中，如果有可能的话，在未来做出一点自己的贡献。

最后，对于我个人而言，这次尝试是一个重复造轮子的行为。毕竟，市面上的设计系统和组件库资源已经非常丰富了。同时，我所制作的“设计系统”只能供设计师和产品经理使用，我并没有能力完成和调整组件库的程序部分。但旅途的重点不是结果，而是路上的风景。这次尝试过程中的收获非常丰富。

搭建历程

这一次尝试，主要分为三个阶段。第一个阶段在20年年末，主要是我在项目进行过程中随手制作的一些组件。这个时候，我有意识地尽量先准备组件，再进行设计。但是这时的组件并没有经过精心严密地组织，几乎是想到哪里做到哪里。所以，虽然能用，但随着时间推移，组件库越来越乱。

第二阶段，主要在21年年初。当时新的项目即将开始，设计的模式也逐渐稳定了下来。这时我根据第一阶段的积累和经验，自己制作了一个单独的sketch组件库文件。这次组件库的结构有了一定的设计，但过程仍然比较急躁。成果也比较粗糙。其中也并没有包含element UI里的所有组件，而是主要制作了项目中常用的一些。

第三阶段，从去年年末到现在，我根据element UI的公开文档全面、细致地整理出了其sketch组件库。覆盖全面，结构完善，灵活性较高，比较细致地观察了element UI本身，同时照顾到了我们的使用习惯和使用场景。在测试使用中它显然还不完美，但这的确是我目前能拿出的最好结果。

在搭建的过程中，我尽量提高设计系统的灵活性，保证各层级嵌套和联动清晰可用。同时，关于布局、宽度等，我也尽可能实现了自动化，避免在调整组件覆盖层，或缩放大小的时候，出现意料之外，不合常理的实例。

组件的结构和层级

搭建设计系统的过程中，我很快开始意识到组件具有不同的结构。一些组件较为基础、简单。比如按钮，按钮的主要属性包括文字内容、图标、图层样式、颜色、大小等。这些不同的属性都可以通过软件本身所提供的工具来进行调整。故而这样的控件，其结构没有很深的层级。但由于属性种类也不少，所以数量有可能会很多

但是，对于更复杂的组件而言，情况就有所不同了。一些复杂组件，比如日期选择器，为了比较舒适灵活地使用，就需要由多个层次的控件逐级搭建而成。最底层的是背景与状态，用来区分日期模块的不同状态。第二层是时间单元，结合了背景和数字的日期；第三层由基础的时间单元构成，结合成针对不同情况（如日期、月份、年份）的面板模块。同时，这一层也包含了必要的其他工具栏、快捷方式等。最后，由第三层的各种面板和工具栏，最终构成各种各样的实用模版，可以直接供设计师使用。

当然了，其他的设计系统文件，由于种种原因，可能并不会采用这样的层级结构。比如，他们可能不会把日期和背景状态，做成具有独立调节能力的组件模块。必须承认，对于一般的使用场景而言，仅仅提供“使用模版”这里的组件就够用了。但软件设计的过程是非常具有个性的，有时你必须通过设计图表达一些特定的情况或问题。而且考虑到组件库文件的使用者都是专业程度较高的工作人员，我认为理想情况是，首先提供给用户常用的实用模版，同时也将各级基础组件制作出来。这样在实用模版无法满足需求的时候，用户就可以通过调整、打散实用模版的方式，自行拼接标准统一的，个性化的组件。当然了，如果他愿意的话，也可以使用基础元素自行搭建。

这样的结构模式，我认为是试图在组件库的便利性和灵活性之间，尽可能地实现兼顾。同时，我也看到不少的组件库，设计师为了满足一些复合组件在数量、颜色、状态上的不同情况能够被覆盖，必须绘制几十上百个组件组成组件集。但如果采用上面的思路，就不需要提供这样多的个性化的状态，在模版一层仅仅需要提供若干种典型场景即可，同时又丝毫不影响使用者进行灵活创造的能力。

当然了，这只是我自己的一种探索。由于人力有限，我也没能把这样的原则贯彻到所有的复杂组件当中。我会继续优化，也希望时间和实践能够逐渐给出这一问题的标准答案。

设计师的用户体验

设计从来不是仅仅在于结果，更在于过程。而当我开始设计自己的组件库的时候，我感觉这也是在设计一种工作体验。

我发现，成为设计师最棒的一件事就是，你不仅会为别人着想，希望为客户打造出优秀的工具和体验，也更希望可以把这种思维对准自己，改善自己的工作和生活。设计组件库的过程中也是这样。在制作的过程中我越来越强烈地感觉到，我不仅仅应该关注组件库的功能，也同样应该关注组件库的用户体验。在使用它的设计师看来，一个组件库是否易用、方便、容易理解，易于维持视觉规范和设计标准，都是非常重要的指标。

对于颜色管理的考虑我认为就能非常鲜明地看出用户体验的因素。现在，在很多设计系统中，可以看到类似这样的颜色面板

在一个设计系统中，品牌色、警告色等若干种颜色，变化明度和纯度衍生出不同的颜色是一种非常常规的操作。TDsign采用的设计思路是，提前预制好不同的色彩梯度，再将这些颜色和具体的应用相关联。这是一种非常明智的方式，在和开发对接的时候非常便利。

然而，问题在于，在设计师使用的组件库文档中，我们也要诚实地反映这一点吗？像这样排列如此多的梯度，固然全面、准确，然而在设计师进行设计或修改的过程当中，恐怕会增加不少选择和鉴别的时间。同时，如果我们希望对某些颜色的基础色相进行修改，比如更换不同的品牌色，那么就必须在设计系统中逐个修改每一个颜色，然后才能在界面中看到效果。这显然是相当耗时的。

对于规模比较大的项目和团队而言，这点时间几乎是可以忽略的。但是对于单个的设计师、产品经理，或者想要快速修改设计图，观察视觉效果的应用场景而言，这么多不同梯度的颜色准备起来还是相当费劲的。所以，在我的设计稿里，我直接根据颜色的语意进行区分。而针对不同地方不同的衍生色应用场景，我采用黑色/白色遮罩的方式来进行变换。这样，如果用户决定修改主题色，他只需要修改主色的色值，其他一切都会自动随之变化。

当然了，这样的做法也是有很大缺点的。经过遮罩后呈现出来的衍生色，实际上很难和element UI原生提供的衍生色一一对应。如果直接使用不对遮罩进行调整的话，不同颜色下视觉效果也可能差强人意。但使用中的极大方便，对记忆负担的减轻，让我还是选择了现在的方法。或许也有这样一种折衷的办法，即设计师可以将不同的衍生色，与不同的遮罩效果对应起来。这样虽然视觉效果上会有所区别，但只要前端开发使用的是精细调教过的衍生色，就可以保证最终呈现没有问题。与此同时，设计师也可以享受使用透明度遮罩带来的颜色管理上的极大便利。

颜色的问题是一个案例，我认为这个案例很好地体现出了开发协作，设计现实，和设计师用户体验之间的矛盾。其中设计师用户体验的重要性在于，只有设计师能够舒适、方便地使用设计系统，才能最大限度地减小设计师犯错的可能性，保证设计系统的规范能够得到遵守。具体到颜色这一个问题上，我认为未来通过软件功能的进一步进化，是可以完美地兼顾设计师用户体验，和开发协作的准确性的。我相信上面所探讨的，只是一个暂时性的问题。

命名、图层整理与工作习惯

这一点在日常的设计工作中是非常容易被忽略的，但在组件库的搭建过程中却异常重要。

在一般的设计工作当中，我们最在乎的往往是最终的成品效果。至于图层命名怎么样，好像不是很重要。但是在组件库当中，每一个图层的命名和排序，最中都会反映在使用者的控制面板当中，这个时候混乱的排序、命名就非常致命了。

以上呈现的例子，实际上还相对简单。如果遇到复杂的复合组件，控制面板的数目可以达到几十项，那就更让人崩溃了。不过，在现在这个时代，这可能也算是sketch的“特色”之一。如果使用figma等软件等组件集功能，右侧的控制面板会更为简洁。但无论如何，保证组件库易于阅读和理解，在哪个平台上都是非常重要的。

除了图层顺序和命名以外，对于组件布局等的调整，也必须关注。组件库不像一般设计稿，组件库需要面对的使用场景往往要丰富得多，所以应该在设计之初就尽可能考虑到用户可能对它做怎样的调整。如果没有考虑到这一层，在使用的时候才发现其在自动布局等方面存在逻辑上的漏洞，再翻回头来改可以说是相当痛苦的。

最后，考虑到一个类型的组件实际上要绘制的对象很多（比如按钮，我大概画了几十个按钮组件来覆盖所有的情况），非常有必要在设计第一个组件的时候就检查好命名、图层、布局等各种因素。在确认无误后，再进行复制和修改。否则在数量增多以后，如果再发现有什么共有的错误，从头修改的感觉真是令人崩溃。采用多层级组件互相嵌套，也可以一定程度上减小失误的代价。

除了上面的命名和图层规划问题，针对图标命名，我也做了一定的改进。在梳理element UI的过程中，我发现他们的命名也不是很完善。

比如在这几个图标中，放大镜和减号命名为“zoom-out”，但圆圈加减号就变成了“remove-outline”，单纯的减号则是“minus”。这样的命名方式，在使用和检索的时候，对设计师的记忆里提出了很高的要求。设计师想到的可能只是“减号和圆圈”所组成的图标，但如果他搜索“minus”，或者搜索“circle”，都不会找到右上角的“remove”图标。

所以，在我制作的设计系统文件中，对图标命名进行了修改。

如图所示的图标，被命名为“symbol-circle-minus > remove-outline”。这个图标很鲜明地被“>”分割为两个段落。后面是图标在element UI中的原名，方便前端查看和查找；前面的若干单词则起到了分类和标签的作用。我将相关联的词汇和分类信息都书写到这里，在查找的时候就可以很方便地搜索并查看了。针对element UI中没有，后面补充的图标，我标记了[original]，可以方便地查看和查找。

组件分类

组件库的分类，就目前观察而言，还是形成了比较稳定的模式。举例而言，大家常用的 element UI 和 Ant Design 的分类模式是这样的：

这两个分类模式，具有很强的相似性，但在细节上仍然有一些不同。比如在ant design中，走马灯、折叠面板都属于“数据展示”，但在element UI里，这些却属于“其他”。总体而言，我认为ant design的分类模式是更加合理的，分类标准整体而言清晰很多。

也正因此，实际上在我的组件库当中，其分类模式与element UI文档本身的分类模式有较大的不同。我的分类模式具体是这样的：

我认为，对于组件库而言，丰富多样的组件应用场景导致我们很难给出一个逻辑非常严密的分类模式。总会有一些组件游离在不同分类的边缘。在这种情况下，我觉得让使用者容易记忆和理解，才是更重要的。而要做到这一点，就需要每一组组件都具有容易理解，令人印象深刻的共同点。

在我的分类中：

• control-控件，代表功能结构简单，用于向程序传达指令和信息的组件；
• content-内容，代表界面向用户传递信息的模块，相比于feedback，content可以稳定地、静态地存在；
• feedback-反馈，通常出现在操作、状态变更之后，用于呈现操作结果或状态信息；
• navigation-导航，告知用户当前所处的流程和空间位置，并允许用户在软件的不同时空位置间移动；
• pop up-弹窗，各种模态或非模态的，高于正常界面层级的临时性的模块和窗口；
• graphics-图形，包括图标和插画，常常嵌套在其他组件中共同使用；
• others-其他，难以归类，或并非由组件库提供的控件。如系统提供的鼠标指针、滚动条等。

我认为这样的分类方式，对于用户而言是相对容易理解和记忆的。当然实际效果还需要工作中的测试。细心的朋友可能会发现，除了分类本身的改变，在我的新分类中，除了最后的graphics和others两个比较特殊的项，其他的分类里控件数目都差不多。这也是我想要实现的目标之一，尽量让一级分类和二级分类的数目既不多也不少，几乎平均地区分开数十个控件，提高设计师的寻找、选择和使用效率。

同时，针对一些具有极大相似性的控件，我也进行了合并。比如在element UI的文档当中，选择、输入、日期时间选择器等控件在没有展开面板等时候，都呈现为输入框/选择框等变体。这种情况下，我将它们全部合并为“input”项。这样的合并方式，在我自己的使用过程中，是比较高效的。尤其是在表单设计的过程当中，可以非常灵活地在不同的输入形式之间进行切换。

将信息存储在设计系统当中

《设计心理学》一书中，有一章的内容叫“头脑中的知识与外界知识”，论述了人记忆的特征，以及外界知识如何能够帮助我们更加轻松地完成各种各样的工作。对于设计系统这样的复杂工具而言，外界知识的引导我觉得非常重要。

对于我而言，在设计系统中储存信息，最典型的莫过于间距。间距作为一种无形的东西，非常容易遗忘。所以在这次设计系统的制作过程中，针对经常组合出现，或位置关系相对稳定的一些组件，我直接将间距和位置信息“制作”到了组件当中。这样在设计时使用的时候，直接将其拼接或对齐即可，并不需要再担心间距的问题。以下是几个例子：

通过这些设计，可以大幅度地减小设计师的记忆负担，让视觉样式以一种自然、简单的方式保持统一。设计师从而可以把注意力放到更重要的事情上，比如整体布局，交互逻辑，还有业余生活。

设计系统的灵活性和限制

在我看来，设计系统作为一种强大的工具，具有两个关键的特征。一个是其灵活性，即能够按照使用者的意愿，灵活地制作各种各样的设计图，同时在需要的时候进行联动的，全局性的修改；第二则是其限制作用，通过局限设计的可能性，实现对于界面风格和设计质量的一致性的把控。

这两个特点，似乎具有一定的矛盾。那么对于设计系统的制作者而言，如何实现兼顾和平衡，可能就是一个非常重要的课题了。我们希望的最优解当然是“既要，也要”，即破坏设计规范、设计风格的改动全部禁止，但在规则内的改动全部允许。但在现有的工具条件下，要做到这一点还存在不小的难度。在很多情况下，我们仍然需要权衡。

在这里，我想要提到的一个具体案例是sketch在最近的版本中，新增的对于覆盖层的管控。

这是一个控件的覆盖层管理面板。对于一个组件，其中嵌套的组件、图层样式、文字样式、文字内容等等都可以成为覆盖层。在以前的版本当中，这些覆盖层会一股脑地全部生效。某个控件，你可能不希望它的文字颜色发生变化，但这个控制器依然会出现。对于某个图标，可能会有两个着色覆盖层，而其中一个会覆盖另一个，但这种情况下，你依然会看到全部两个控制器。

这个管理覆盖层的功能，解决的就是这样的问题。它可以帮助你把组件中不希望改变的覆盖层关闭掉，只留下那些你允许修改的。这样一来，就让设计师在灵活的同时，具有了对实例进行限制的能力。某些不需要更改的属性，直接禁用，就可以保证其在设计稿中的稳定和安全。

这一功能目前而言还存在一些bug，也有不令人如意的地方。同时，针对具体的组件，哪些覆盖层应该被禁用，还需要实践中的不断观察。不过，我觉得这是个很好的开始，也算是给设计师提了个醒。设计系统的灵活性与限制性，可以说是一体两面的。其中任何一个方面如果存在缺憾，这个设计系统都很难良好地运作。

评价我使用的工具

由于日常工作的环境要求，在这次构建的过程中，我使用了一个相对“落伍”的工具：sketch。

对于不少设计师而言，相对于figma这样的新生力量，sketch可能已经该淘汰了。对于我个人而言，sketch更多也的确是一种比较无奈的选择，毕竟平时的工作还需要使用这款软件，制造一个figma组件库对于我而言没有什么帮助。相对于figma中的功能，比如组件集、字体样式管理、自动布局等等，sketch已经落后了许多，而且不知道为什么，虽然更新频繁，但似乎并没有跟进的意思。不过，这一趟实践下来，我觉得sketch也没有那么不堪。甚至有些时候，使用sketch实现的一些效果，在figma中反而难以做到。

万变不离其宗，无论使用怎样的工具，对于设计系统本身的理解是有一致性的。软件的结构和体系自身与开发程序的关系最为接近，要在sketch或figma中制作设计系统，都需要对这个思维和体系进行一定程度的转化。所以我觉得，了解设计系统本身，了解工具本身，最终就可以获得比较优秀的成果。当然了，由于一些限制，现在很多程序上能实现的效果在设计软件中实际上是不可能的。所以我也非常期待看到设计软件在未来的更多改进。现在的设计软件距离完美都还有很长的距离。

组件库资源下载

欢迎试用！
版本：Element Local 2.2，2022年3月18日 18:44上传

Element Local_2.2.sketch

联系作者

邮箱：1419955392@qq.com
WeChat：why13031131699

欢迎建议、交流与提问～