本篇属于「UI 是道数学题」系列主题下的组件篇，后续会陆续更新其他的篇幅，敬请期待哦...

其实早在两年前就写过组件相关的文章，那会大家还习惯于用 Sketch 做组件， 而现在都改用 Figma 了。也确实因为软件的更新换代，给设计师带来了很大的效率提升，但凡事都有正反面，软件的过于便捷，使得很多本该设计师掌握的能力、该有的思维意识在逐渐衰退

而在我看来，思维意识比软件技巧重要很多，技巧谁都能学会，但意识不一定。所以两年后的今天我又写了同一主题的文章，因为我觉得之前太注重于怎么手把手教做组件，更适合从0到1的新手。

而现在则是进阶版，更侧重于背后的原理，希望能根据自己的所做所思所想，去总结出一套能量化、可实操的方法论，拿来就能用，同时还能举一反三用到其他地方。

本文共分四个部分，预计用时8分钟

一：关于组件的二三事

二：常见的误区以及正确做法

三：案例实操

四：组件化思维在日常工作中的运用

一、关于组件的二三事

在开始做一件事情前，得先弄明白前因后果，为什么做，做好的标准是什么

1.1 为什么要做组件

1）统一样式，在多人协作时，组件的复用能保证各模块样式统一，不至于在拖拽过程中元素出现偏差

2）效率提升，通过把高频复用的内容做成组件，后续直接复用，减少了重复性劳动带来的工作量，同时组件库也方便与开发协作，提高协作效率；

3）便于修改，当发现问题的时候，只需要修改组件，就能一键同步所有，再也不需要一个一个页面单独去调整

其实汇总起来就一句话：磨刀不误砍柴工

但磨刀不误砍柴工有个前提：是会磨刀，不然一把很钝、砍柴很慢的刀，再经过一番瞎操作，直接没法砍柴了，白白耽误了时间。

而会磨刀的前置条件是「学过+用过」没有人一出生就会磨刀，肯定得专门学过或者说研究过才会，同时在学的过程中他也会见到前辈们是怎么磨的，磨的很好的刀长什么样，这样慢慢的自己也知道怎么磨一把好用的刀、怎么快速磨一把好用的刀

做组件也是一样的，也得先学先用先看，在没有研究过以及用过严格执行过其他人做的组件，是很难保证自己做的组件是好用的，能被其他人用，能真正提高团队效率

1.2 什么样的组件是好的呢？

简单来说就六个字，看得懂、能复用，看得懂指的是：其他人在用的时候，不需要解释说明，就能找到要的组件；能复用指的是：拿过来能用，不需要打散才能用

1.3 打组的三个阶段

第一阶段，不知道组件为何物，从不打组；

第二阶段，发现了打组这个神器，疯狂打组，恨不得所有能做的都做成组件；

第三阶段，在经历第二阶段的疯狂打组后，会慢慢发现都做成组件，并不没有提升工作效率，逐渐就会开始细想哪些是真正需要做成组件的，做了之后能提高工作效率的、而哪些做了费力不讨好，开始理智打组

二、常见的误区以及正确做法

2.1 组件命名错乱

命名随意，没有规律，让人看不懂不知道怎么延续规则，以及替换时容易出现问题

建议的方式：基础规则：按功能模块区分；需要替换时规则：先分类别，再区分状态，类别指的是按钮、图标、弹窗这些，而状态指的是按钮的大中小、默认点击置灰态等…

2.2 打组规则不明确

打组过于随意以及颗粒度过大，造成组件冗余，复用困难，比如：为了方便复用把整个页面、整个卡片列表、甚至把纯文本做成组件，这样看似是提高了效率

但其实未必，大家可以代入实际场景想一下，当你做一个新的需求，需要用到这个组件，但由于这个组件颗粒度太大，没法直接用，不得不把它打散，去改动其中的一小部分，下一个人又打散，这样最后就失去了组件的意义了

因为修改原始组件时，其他被打散的组件并不会随之改动，而且尴尬的是，随着时间的推移，没有人知道原始组件被打散重组了多少样式，它的「徒子徒孙」有多少了

2.3 随意更改组件

以标签举例，当需要其他科目标签时，直接拿组件库的标签改颜色，而没有把所有的科目标签做成彼此之间可以替换的组件，这样就导致一旦源文件找不到了，标签改后的颜色就没人知道了…甚至其他人会以为没有这个标签，从而又新增了一堆标签

之前有个需求就是因为这个，找不到是哪次需求加的标签颜色，无奈之下还是找的开发直接看的代码，作图5分钟，找图2小时

所以对于组件的要求就是：要不就不用，要用就别改

2.4.分类不清晰

以 Button 举例，把所有的 Button都罗列出来，整体打了个「变体」导致替换时需要筛选的变量太多了

从理想层面上来说，拖一个 Button 能替换成其他二三十个 Button 的样式，很方便，但实际操作起来，给的选择太多了反而不知道怎么选，建议先分类别，比如 button 的大中小，然后再区分状态，最后把这些都打成一个大的变体

2.5 组件、规范概念混淆

规范是明文规定或约定俗成的标准，以一个产品为例，需要把一些通用规则整理成规范，保证产品的统一性，所以需要它好理解，能知其所以然并且能举一反三。而组件是把规范里频繁出现的、有复用价值的部分打成了组。

两者是一个包含的关系，同时规范给了变动的空间，比如重要信息用 22号字，那什么样的信息算是重要信息，这个就需要设计师根据规范自我判断，举一反三，但组件就没有变动空间，绑了组件就不允许大改，要改就别绑

三、案例实操

3.1 组件的3种类型

直接复用型组件

顾名思义直接复用型组件指的是 A 页面的内容可直接复用到 B 页面，复用后内容不需要修改 or 简单修改，类似于图层组的作用。最常见的莫过于时间栏、上下导航栏了

自适应型组件
自适应型组件指的是元素内容不固定，会根据具体情况发生变化，俗称撑开现象，比如常见的标签、文字、Button 等，会根据文字的多少，自动撑开

替换型组件

替换型组件指的是，组件内部有元素可以相互替换，比如插图，相互替换的内容可以做成小组件，大小完全保持一致，同时注意命名前缀一样，方便直接替换

在实际工作中，这 3 种类型通常会组合出现

3.2 打组三步曲

第一步：判断需不需要做

判断的依据就两个：是否需要复用、是否频次高，同时满足两个条件才有必要做成组件

第二步：明确打组规则

比如卡片做成组件的话带不带边距、cell 是按距形框来做还是整体打组，得有一个统一的规则，才能保证大家打的组件间距大小统一

推荐使用右侧的打组方式，卡片不带边距、cell 按矩形框做

第三步：统一打组方式

堆积木式打组，把页面当成一个一个小的积木，小积木拼成中积木，中积木再拼成大积木。相同大小的积木可以相互替换

举个例子，把页面拆分到最小颗粒度，然后用这些小积木去拼，这样能够减少组件重复，使得组件曾经更清晰，方便团队的其他人使用

四、组件化思维在日常工作中的运用

4.1 设计稿管理

设计稿的排版也是需要特别注意的，不要在里面放一堆不相干的文件，很影响其他人查看文件。同时我也不建议放交互流程图，原因有二个，其一把做好的页面按照点击跳转做流程图，太费时间影响工作效率；其二流程图可以用其他方式代替，也就是我下面要讲的

用组件化思维整理设计稿，先把需求分为类别，再细分页面、页面再细分状态。以上图右为例：默认状态、发言&发表情相关、出镜&举手就是这个需求的不同类别（流程），不同类别的图放一排，每个类别又有很多页面，页面再细分不同状态

这样一目了然，方便自己已经其他合作方快速查看文件，从而提高大家的工作效率

4.2 切图

我一直觉得切图是一件前面偷懒后面走查就会双倍奉还的事情，后面的工作量远比前期多做一点的工作量大。

以下图为例：24点小游戏里的数字的默认态和点击态的切图大小不一样（投影大小导致的）如果设计师不切图 or 按照常规方式切图，那切换的时候页面会发生跳动，同时开发没法对卡片内的文字进行布局

而按照右边的切图方式，把两个卡片当成「替换型组件」两个可以相互替换的组件需要保持大小一样，当把两个卡片切成一样大的时候，问题就解决了。后期走查也不需要再对这一块进行验收了


5.画重点

1）做组件的目的是为了提高效率，只有真的研究过，才能做出好用的组件，真正做到磨刀不误砍柴工；

2）组件化的思维意识远比「做」组件重要的多，只有知道原理后才能举一反三，把组件化思维应用到工作、生活的方方面面；

3）规范是明文规定或者约定俗成的规则，组件是把规范里频繁出现的、有复用价值的部分打成了组，二者是一个包含与被包含的关系；

4）打组三步曲：判断需不需要做，哪些是规范能搞定的；明确打组规则，这样才能保证大家打组的间距、大小一致；统一打组方式，用堆积木的方式进行打组，小积木拼成中积木、中积木拼成大积木，相同大小、属性的积木可以相互替换

本文原创，未经作者允许不可转载！
更多内容，欢迎关注作者微信公众号：海盐社！