背景
在UI设计的工作当中，尤其是面对一些时间长，规模大的项目时，进行组件化的设计和管理对于设计效率、质量与团队协作都有很大益处。而面对日常紧张的工作，往往难以对设计稿进行全面而完善的事后整理。因此，我一直希望能够在项目进行的过程中，随着设计图的不断推进，同时搭建起合理有序的组件库，支持设计方案的有序扩张和后期维护。
此时，便不可避免地遇到组件库的分类问题。在多次实践当中，分类思路、分类标准的模糊总是导致我的设计组件库随着方案规模的扩大而逐渐变得混乱。到后面，虽然这些组件仍然能用，但它具体属于哪个分类，如何快速地找到某个组件，制作的时候的具体思路时怎样的，基本已经不可追溯。这让项目进展后期的效率收到影响，保持设计稿始终清晰有序也成了奢望。
由于是在设计过程中同时建立组件库，所以组件库的分类结构需要十分稳定，又要极具包容性和扩展性。这样才能让设计师能够在项目开始前，就对组件库的整体结构胸有成竹，又能在项目进行的过程中，游刃有余地把每个组件放到它应该在的地方。经过多个项目的实践，我认为我已经找到了一种实用、稳定、简单的分类方式，能够保证即使一年以后，设计师仍然能轻松地重新拿起稿件开始工作。
说明
本文所指的组件库，仅从设计师的视角出发，并不涉及前端。作者日常工作主要使用sketch，但这样一种分类方式，应当不会受软件环境变化的影响。
参考和尝试过的思路
常见开源组件库
我个人在工作中经常参考和使用的组件库主要是Ant Design（以下简称AD）和Element UI（以下简称EU）。这两个开源组件库的一级和二级分类如下：
观察两个组件库的分类模式，我们首先会注意到他们的相似性。这说明至少对于后台系统而言，组件的确存在较为稳定的分类结构。但如果我们仔细观察，就会发现两个分类模式之间仍然存在许多区别。比如AD当中，分页属于导航、卡片属于数据展示；而EU当中，分页属于Data、卡片属于Others。笔者在这里无意争辩哪一种选择更合理，只是想指出一个事实，即这种结合经验和功能目的的分类方式，哪怕在富有经验的团队手中，也可能产生歧义。而其中很多组件，实际上并不一定只能被用作一种目的。如下拉菜单，虽然被归类为导航，实际上也常与输入框搭配出现。这样模棱两可的案例，和潜在的歧义对于我们进行提前分类是非常不利的
另外，可能由于这两个组件库主要服务于前端，其处理的往往都是非常基础、通用的元素。而在我们日常的工作当中，常常需要处理大量打包成组件的页面模块、插画、图片等，而这些模块就很难在如上的分类系统中找到自己的位置。
总的来说，这样的分类方式是值得参考的，但这种以功能类型和经验为基础的分类，更适合事后整理。如果要进行事前分类，其中模棱两可的地方、涵盖不到的地方无疑会导致设计稿在发展过程中越来越乱。
Atomic Design
图片来自 Everything you need to know about atomic design
Atomic Design（以下简称AtD），系统化地拆解了软件的组成部分，也为我们提供了组件分类的一种新的思路。在AtD的体系当中，atoms（原子）指最基础的界面元素，比如按钮、图标；molecules（分子）指由若干“原子”组成的，能够完成一项任务的编组，比如搜索栏。organisms（机体）指更加复杂的“原子”“分子”组合体，能够完成一个或几个任务；而templates（模版）则指页面的模式；最后，pages（页面）就是具体的，填充了内容的某个页面。
AtD的分类逻辑清晰，层级有序。但是它仍然无法完美地解决我们工作中的问题。首先，从“分子”到“机体”的分类有些模糊，在面对一些情况时可能会造成犹豫和纠结。而从“模版”到“页面”的分类在作者的解释下非常合理，对于开发者可能也是有用的思维方式，但对于设计工作并不合适。设计工作中，对于模式重复的页面，我们可能只会制作一份设计稿。如果要求高保真的效果图，则会直接填充内容。设计师不太可能把某个页面整体设置成组件放在组件库当中，再反复地为它填充不同的内容。
iOS Human Interface Guidelines
其实从iOS Human Interface Guidelines（以下简称HIG）中看到的这套分类，很难说和我们想要达成的设计组件分类是一个概念，但这不妨碍我们借鉴它的思路。这套分类方式同样简洁明了，并且在了解AtD之后，我们也能够对它的内在规律进行一些猜测。icon and images，在这里明显成为了独立于其他的图形内容；controls属于基础控件，难以分割；bars主要用于操控软件，由用户向设备传达信息，同时也包含若干更加基础的元素；views则描述了页面整体的模式，和AtD中的templates（模版）如出一辙。
不过HIG仍有其局限性。HIG所描述的内容，主要从iOS的设计实践出发。一方面主要针对移动端，另一方面虽然它对第三方app的开发有指导作用，但毕竟不能涵盖广泛的，多种多样的设计实践。尤其是iOS当中，bars主要针对功能编组，而view又一下跳到了页面整体的层面。设计实践中经常需要的，以内容为主的复用组件，此时便无处可去了。
根据信息流向和信息类型分类
在实践和探索的过程中，我也曾自己提出了一种分类的思路，那就是根据信息的流向和信息的类型。
在这个思路当中，参与者有两个：软件系统和用户。信息流向有三种，由软件到用户、由用户到软件、双向同时进行。从软件到用户的信息中，有直接呈现的信息-内容、有经由操作、或状态变动而产生的反馈信息；从用户到软件的信息中，简单的操作指令由控件传达，相对复杂的数据信息则归类为信息录入；双向同时进行的信息中，一方面告知用户位置信息，又能进行操作的属于导航，同时也存在着更多灵活的组合体。
这种思路我认为也有一定的逻辑，事实上它与前面组件库的分类似乎有一定的对应关系。但是这样的一种分类方式也充满了模糊。比如常见的内容卡片，有一些仅仅呈现内容，有一些则可以进行下探导航，进入其他的页面。这样的分类同样没有对组件的复杂度进行有效的区分，往往导致不同复杂度的组件混杂在一起，增大了组件库的混乱度。
组件分类方法介绍 - BGCBT分类法
在经历了上面的分析、了解与实践，我认为可以这样总结，即一个设计实用的组件分类模式应该有如下特点：
- 主要面向设计师，针对从零开始设计软件，且要在设计过程中同步形成组件库的情况。
- 应当尽可能减少任意一个组件分类归属的歧义，清晰地定义每个分类的内涵。
- 能够较为清楚地区分组件的复杂度，避免大量不同复杂度的组件出现在同一个大分类中。
- 能够全面覆盖设计过程中出现的各种页面元素，特别是能够应对设计过程中大量存在的，将若干内容编组成为复用模块的需要。
综合上面的思路和经验，我逐渐尝试和发现了一种实用方法。这种分类思路主要讲界面元素分为基础（Basics）、图像 & 媒体（Graphics & Media）、控件（Controls）、工具栏&面板（Bars & Panels）、模版（Templates）五种，根据首字母简称为BGCBT。下面我会具体讲解每个分类的定义与适用范围。
基础（Basics）
此分类中的元素，无法作为有意义的内容或功能模块单独出现，它们必须与其他元素一同出现，或将自身性质赋予到其他元素上，才能成为界面的有效组成部分。字体、颜色、图层样式、圆角规范、分割线规范、布局规范等都属于此类。事实上，基础部分的元素在软件操作中，常常设定为可复用的样式，并不会以“组件”的形式出现在设计稿中。不过为了方便整理，有时我也会给基础部分预留一个专门的页面，以便查看和整理。
图像 & 媒体（Graphics & Media）
图像 & 媒体指无任何功能性的，亦非纯文字的图标、图形、视频、音频、插画等元素。这一类元素主要用于传达信息、承载内容。其中一些需要由设计师设计后、导出传输给开发团队，也有一些会在软件环境中根据实际情况替换为不同的成分。将图像 & 媒体统一放置，有助于管理图形和其他类型的媒体素材，在需要批量传输给开发团队时也会方便很多。
控件（Controls）
不能再分割的基础功能性组件。如按钮、输入框、进度条等。此分类的概念显然收到原子设计的影响。各类基础控件也会经常嵌套到更加复杂的模块当中，因此在专属于控件的页面中，充分考虑控件的各种状态、形态变化就尤为重要。控件的二级分类，可以一定程度上参考前端组件库的一些做法。如果项目规模有限，控件类型不多，则也可以在二级分类中直接使用控件名称。在数量有限的情况下扁平化的二级分类有助于提高使用效率。
工具栏 & 面板（Bars & Panels）
由一个或多个控件及其他元素构成，以实现导航，接收用户指令或信息为主要目的组合体。工具栏和面板当中，并非不能向用户提供有用的信息。只是相比显示信息，接受用户的指令与输入信息在这样的模块中更加重要，处于主题的地位。至于属于栏（bars）还是面板（panels），主要是形式上的差别，并不影响其本质。工具栏 & 面板相较于控件而言，在复杂度上较为清晰地区分出了层次。在二级分类上，工具栏 & 面板亦可以参考前文所述的成熟案例，活在数量不多时采用扁平化的层级关系，此处不多赘述。
模版（Templates）
具有规律的、以内容为主，但也可以具有一定导航或其他功能的模版。需要注意的是，模版并不排斥控件、工具栏或导航功能加入其中，但须以展示内容为主要目的，且展示的内容有可能在不同情境下，根据实际情况替换更改。在构建模版时，需要考虑到其对于不同页面位置的尺寸适应性。同时，由于模版形式与页面内容紧密相关，所以在进行二级分类时，可以考虑根据所在页面的位置，或软件中的大功能模块的位置来进行命名，以方便实际应用和查找。
模版这一分类概念的产生，受到原子设计templates与iOS中view板块的启发，但具体概念明显与之不同。这两者概念都十分清晰，但由于其针对的是整页界面，与设计师的工作实际并不能很好的契合。我所定义的templates并非整页模版，而是以内容为主的模块，这在设计实践当中，是经常会被制作成组件的一类元素。
实践与反思
在形成BGCBT之后，我在先后两个项目当中实践了这种方法，到目前为止，它能够很好地支持我的工作，让我的设计稿在不断扩大的过程中保持有序。不过在实践中，我也遇到了一些问题，比如一些元素的分类仍然存在模棱两可的地方，二级分类的标准时有变动等。这样一种分类方法，也仅仅契合了我自己的工作实际，它包括我个人的思维方式、工作偏好、面对项目的类型和规模等。面对更多复杂的情况，我相信这套体系具有一定的应对能力，但也有许多可以继续完善的地方。
我个人会继续实践、优化这样一种方法，同时，我也非常希望阅读到这篇文章的朋友可以尝试它，或分享自己在这方面的经验。为工作建立秩序、提升效率，对于参与它的每一个人我想都是十分有益处的。
参考链接
Ant Design-一套企业级 UI 设计语言和React 组件库
若有收获，就点个赞吧
0 人点赞
