▼  设计狮与程序猿的日常 ▼

以上对话想必很多视觉设计师都不陌生，每每发生时也或许会心存疑虑：

• 为什么看起来很简单的东西一再的实现不理想？

• 为什么那么小的功能研发排期要好几天？

• 难道设计与研发就不能相亲相爱合如一家么？

  
  

带着这痛彻心扉的灵魂三问，我们来看看有没有化解之道。

01

剖析问题本质 探寻解决之道

视觉设计作为产品落地过程中重要的一环，对上游接承产品功能，要深刻理解pm需求；对下游输出设计产出与规范，要明确产品细节的呈现与交互方式；更多的情况下还要同时对接市场、运营、前后端等不同职能部门。设计师在链接多个职能部门的互动中不可避免的会出现大量的沟通协作问题，在这个情况下「效率」就显得尤为重要。

回到最初设计与研发的碰撞场景中，可以梳理总结出如下问题：

从上述问题中可以看出，设计与研发的工作对接中因双方思维角度不一致、信息拉平成本高等原因，导致效率低下，进而产生了日常沟通困难的情况。在某种程度上，[组件化设计体系] 可以帮助我们更好的解决这类问题。

02

[组件化设计体系] 概念

2.1  组件概念

要想明白组件化设计的概念，先要知道什么是组件，我们把「独立的视觉功能单元」称之为组件，简单的比如一个button、一个switch等，稍复杂点的比如一个通知条、一个弹窗等等。

如何判断一个视觉元素是否可以成为组件，是需要同时满足以下三个特性：

• 相对稳定 - 在一定时期内具有相对稳定性，不会受业务功能改变而频繁变动；

• 可被复用 - 可同时被多个页面、模块复用，具有一定的通用性；

• 可形成标准 - 可以以标准的规范文档清晰的定义出属性，成为可交接的标准；

2.2  组件化设计体系概念

了解了什么是组件、以及组件的特性之后，组件化设计的概念就很好理解了。

它是通过对页面视觉元素和功能元素的拆解、归类、重构，基于相对稳定的特性、力求可被复用的目的，最后形成的可被清晰定义属性的规范化组件，通过对组件的多维复合应用来构建设计方案，并输出与研发既成共识的标准对接规范，代码化组件样式，从而降低信息差、提高设计到研发的工作效率。

* 组件化设计体系概念图释

03

组件的内容分类

了解了组件化设计的概念之后，如何着手规划自己负责产品的组件化体系搭建呢？参照组件化的概念定义，我们需要先对当前的产品的视觉和功能元素进行拆解、归类与重构，筛选出来具有「相对稳定、可被复用、可形成标准」的组件内容，对其进行分类，依据不同属性与粒度，可分为三大类：基础组件、业务组件和底层组件：

* 组件内容分类

3.1 基础组件

在页面中具有多模块通用性，受业务变动影响很低的组件内容，具有长期稳定性：

• [原子组件] - 最基础的、不可拆解的组件，比如button、红点提示等，是构成页面的最基础元素；

• [扩展组件] - 由原子组件+其他内容复合构成的组件，如系统弹窗、push推送、toast提示等，是构成页面的一些基础控件；

3.2 业务组件

依托于业务，具有业务定制性的组件类型，更多的存在于单个业务模块中，具有短期稳定性：

• [内容组件] - 与业务信息强关联的，比如价格组合样式、起始点组合样式等；

• [结构组件] - 与页面布局结构相关的，比如列表页瀑布式结构、详情页吸底式卡片结构等；

3.3 底层组件

基于基础组件与业务组件的构成要素几乎都具备色彩与文字要素，统一收敛色彩的应用场景、文字的字号行高关系，有助于对组件的底层属性进行统一管理：

• [色彩组件] - 收敛全部色彩的应用场景，定义主题色规则，便于组件的整体视觉升级与换肤能力的支持；

• [文字组件] - 定义字号与行高的对应关系，统一两端实现效果，同步设计与研发规则认知，保障文字的视觉还原效果；

在我们实际的设计过程中，组件的分类与产品页面的层级结构具有清晰的对应关系：

* 组件分类与页面层级对应关系示意图

04

组件的命名及配置表规则

4.1  组件的命名规则

为了便于管理，构建良好的组件体系，在组件的命名时，需要遵循以下规则：

• 设计和研发人员对组件命名均可理解与认同；

• 命名需符合开发实现逻辑，统一ios/安卓双端认知；

• 命名不以颜色或视觉属性，需以功能交互的样式特性为维度定义；

  
   

以原子组件中的按钮为例，当产品中存在多种按钮样式时，如何定义命名：

* 按钮的命名

如上图所示，我们将按钮以“Major”、“Minor”和“Filled”、“Linear”这类描述功能特征的词来区分命名，而不是“Blue”、“White”这种视觉属性的名称。这种命名方式的好处在做组件视觉语言升级时将尤为显著，当按钮不再是蓝色，升级为橙色、绿色或者是黄色，便不会对最初的命名产生任何影响，同样的命名规则应当应用于全部的组件命名过程中。

4.2  组件的配置表规则

每一个组件都具有一个完整的配置表信息，详尽的描述该组件所具有的能力与样式，定义其属性边界，这是视觉样式转化为开发数据的关键一步，是组件化中设计与研发对接的具体信息载体，一个完整而有序的配置表需具备以下几点：

• 仅对组件样式属性进行描述，而非设计形态；

• 多种状态表述清晰；

• 可变量与限制条件清晰；

• 符合开发实现逻辑，统一双端认知；

• 互动动效形式明确；

我们以上文中提到的ButtonMinorLinear按钮为例，看下具体的配置表该如何描述：

* ButtonMinorLinear按钮的配置表信息

可以看到，一个简单的线性按钮的配置表内容如此之多，这样详尽的定义组件属性看似麻烦，实则在后期的使用过程中收益很大：

• 开发阶段：研发同学可以通过清晰详尽的配置表内容完整的定义组件能力与样式，提高对接与研发效率；

• 走查阶段：组件样式出现问题时可以很快的通过配置表属性聚焦到问题所在，提高bug修复效率，有助于设计还原；

• 升级阶段：在组件能力升级或者设计语言升级时，通过修改配置表里的参数，比如将圆角改为直角，只需要将CornerRadius参数由8改为0，便可以一键更新全部ButtonMinorLinear按钮样式，极大的提高了迭代效率；

清晰明确的配置表承载了设计与研发的对接与组件能力的定义功能，是组件应用中最重要的一环。

05

组件的应用流程

了解了组件的命名与配置表规则后，以一推十，便可完成全部组件的描述定义，产出完整的组件规范文档。接下来我们看下一套组件规范是如何在具体业务中应用的：

* 组件在业务中的应用流程图

上图清晰的展示了组件应用流程，其实是与我们正常的需求流程是一致的，不同的是在设计阶段，在遇到组件时，设计师可以直接取用定义好的规范样式，进入开发阶段，研发同学也可直接调用已经开发好的组件代码，这一过程极大的节省了设计与研发时间，提高了工作效率。

在组件的应用过程中，组件负责人要在不同的阶段密切关注组件的产出与应用是否符合组件规则，保持组件的实时更新、更好的覆盖业务场景。在组件内容发生修改、新增和迭代时，均需通过设计与研发的组件负责人确认调整，完整流程可参照下图：

* 组件化设计体系的完整应用流程图

组件的应用过程中，看似只需要组件负责人全流程的关注，实则是需要每一个设计与研发人员的全员关注的，了解现有组件能力、及时反馈组件问题，执行组件规范，才能有助于组件化的良好生态维护。

06

组件化设计体系的收益

一套完整的组件化设计体系，构筑了设计与研发的沟通桥梁，达成一定程度的信息思维同步，可以帮助设计师统一把控规范、提升设计和研发工作和对接效率，还有助于不同职能人员跳脱出具体业务，关注到项目的整体全局，更好的维护支持业务。

* 组件化设计体系的收益

6.1 统一规范

在工作中，大多的需求流程是各个设计师独立并行的，同样的功能样式常常有着不一样的设计细节。当进入开发阶段，可能会存在不同研发人员并行开发同一功能需求的情况，同一种视觉样式会因不同人员的开发习惯差异，出现多个代码内容，增加了管理难度。

* 原有的多人独立并行支持业务需求模式

组件化设计可以很好的解决这类问题。组件由组件负责人设计开发完成后，业务设计师与研发人员只需要对应选取相应的样式与代码即可，不需要关心具体的字号、间距、或者文字截断规则等细节。组件具有的这种高复用性，极大的保证了设计图与开发代码的统一性与规范性。

* 应用组件化设计后的业务需求支持模式

6.2提升效率

在业务需求为主的人员分配下，设计与研发人员往往是在一种纵向独立执行、横向缺乏沟通的工作场景，整个团队会产生大量的重复性工作，上文讲到的组件所具有的高度复用性与统一性，就可以很好的实现设计与研发效率的提升。

设计师可以通过对不同组件的搭建迅速得到一个页面中最通用与基础的部分，而研发人员则可方便的直接取用组件代码，极大的节省了时间，提升工作效率。

6.3精准定位

组件化可以精准定位页面中有问题或需优化、迭代的功能控件。

以常见的toast为例，它会出现在多个功能模块、承载多种信息场景，涉及端上固定样式与api实时下发等多样实现形式，在没有组件化的阶段，toast基础样式或规则发生优化迭代时，研发人员需要从后台通过自动+手动的方式找出全集toast场景做修改，不可避免的就会有部分遗漏的场景覆盖不到，而在找出的场景中，也有相当一部分是需要设计师重新给出标注与切图的。

而在应用了组件化的情况下，事情就变得简单的多了，负责组件的设计师给到负责组件的研发人员最新的toast样式规则，新toast开发完成后做组件的走查与测试，确定样式正确、功能全面后，组件的研发负责人做端内的toast组件一键更新，全部的toast样式即可更新完成。

* 以toast为例，组件的精准定位能力应用流程图

另外组件所具有的这种特性，还可以最大限度的保证设计规范及时更新同步，避免出现项目初期规范严谨，后期逐渐淘汰不能收拢业务场景的情况。

6.4系统统筹

完善的组件化设计体系能够帮助设计与研发人员释放出部分维护基础控件的精力与时间，聚焦在更为全面系统的角度思考：

• 平台设计师，也是组件的设计负责人，可以站在更高的角度、更全面的思考组件的能力与属性，从全集的角度去衡量一个好的组件该具备的特征与形态，当组件无法满足业务需求时，可以更好的拓展升级组件能力；

• 业务设计师，也是组件的设计使用者，从基础设计中释放出来的时间与精力，可以更好的关注产品体验的提升，做出更有设计价值的亮点与体验；

• 组件研发负责人与业务研发人员也都可以更专注于专项内容，前者可以更多的考虑组件的通用能力，让组件有更强拓展性和更好的稳定性；后者可以专注新业务实现，推动整体产品能力提升。

除去人员的全局能力得到了提升，在有设计语言升级、产品功能迭代等大的项目变动时，组件化设计的系统能力更为突出，可通过对组件化的重新配置升级，关联关键页面和功能点的人工调配，快速的支持到项目升级。

07

写在最后

本文向大家介绍了组件化设计体系的概念、分类、命名和配置表规则，以及应用流程，是我们团队在提升工作效率、推动设计落地道路上的一次尝试与探索。

在取得阶段性收获的同时，还将继续完善、不断验证，以期可以通过 [组件化设计体系] 解决设计与研发的思维差异，增强设计推动力，以多赢的方式促进业务的更好发展。