更高效的沟通、更迅速的开发、更一致的体验……诸多优点让组件库的搭建在近几年流行起来。甚至一些大厂的组件体系已非常成熟，如Ant Design，WeUI等等。成熟的组件库对产品体验确实有肉眼可见的提升。如果你也想为团队搭建一个组件库，希望以下内容能帮到你。Enjoy~
组件库简单来说就是一些积木，而产品相当于成品模型。我们可以根据业务需求，以“搭积木”的方式，让“模型”快速落地。而“搭积木”过程中并不是随心所欲，至少需要看一看“使用说明”，而这“使用说明”就是设计规范。产品、组件和规范差不多就是这样的关系。
至于为什么要搭建组件库，怎么去搭建组件库，网上已有很多相关文章，也有非常系统的方法，在此给大家推荐一本书《设计体系》。国内也有大神翻译过此书，翻译得很棒，推荐给大家：链接。
而近段时间，正参与一个体量较大的B端项目，负责其中财务模块的交互设计以及产品的组件库搭建。目前组件库已经基本搭建完成，能覆盖70%+的业务场景，团队效率大大提升的同时保障了产品体验的一致性。藉此机会，我想分享一下在搭建组件库这个项目中的一些心得。
1 绝不是设计师就能搞定的事
其实在这个项目之前，我也尝试过梳理出一些所负责的产品的组件和规范，以便日后有新需求时可以参考复用，不必重复造轮子。但设计规范基本很少人看，然后就一直静静地躺在文件夹里。我也曾经在Sketch上做了很多Symbol，推广团队内部用起来，从而提高画稿的效率和一致性。但交付开发同学后，不同的开发依然会对每个组件都要重新写一遍。
现在回头一想，出现这种情况，原因也很简单：以前梳理的组件没有开发落地，只是一张图纸，并不是实打实的组件。
所以搭建组件绝不是设计师就能搞定的事情。而且开发应作为核心的主力之一，我们的输出物应该是开发的代码，真正地在代码层实现拖拽组件就能搭建界面原型，而不是Sketch上的Symbol。只停留在纸面上的组件和规范，其实意义不大。
或许搭建组件库这事情会让人兴奋不已，巴不得马上撸起袖子开干。但在此之前，是否有开发的支持、设计与开发是否达成共识、大家是否愿意并肩作战，是我们首要解决的难题。
2 要搞明白面向的对象是谁
以我的项目为例，面向的是设计师、前端开发和产品经理这三个群体，而这三个群体对组件库的需求是截然不同的。设计师希望能了解到组件库的使用规范、适用场景、拓展方案等等；产品经理希望知道新的业务需求可以拿什么组件完成，组件是否能满足业务场景等等 ；开发更关心的是组件的接口、方法、属性等等。这样一梳理下来，就可明确输出物应该包含什么内容、如何呈现、需协调哪些资源来完成。
3 不要套用模板、每个细节都值得思考
在设计之前我们会参考一下竞品如：Material Design、Ant Design、WeUI……，看看他们如何分类、如何命名、如何定义等等。为了赶进度，我们也曾套用了一些模板，为自己埋下了不少坑。比如组件的分类，一个搜索组件，有的会将其归为操作类，有的将其归为导航类、基础类、输入类等等。为了方便我们直接参考了竞品的分类方法，简单粗暴地将其归为输入类。一开始并不觉得有什么不妥，但后来发现难以应对的各种挑战也随之而来。
比如，在之后的动效库项目中，我们希望输入类组件应减少动效，避免过多的动效打扰用户。但同时又觉得搜索组件应该加上动效，能给予用户更清晰的引导。这时我们陷入了问题的漩涡中：如何解释同类的组件为什么会有截然不同的动效属性？动效的规范又如何定义？为什么搜索会被归为输入类组件？……一系列问题被引发出来。这就是我们在分类组件时思考不到位所带来的结果。
总之，今天不假思索套用的模板，会成为日后需要不断填的坑。越基础的东西越影响全局，牵一发而动全身。
4 事先应了解技术限制
开发在实现组件时都会基于一些现有框架，不会去重复造轮子。例如，蚂蚁的Ant Design 基于 React 框架，有赞的 Zant 基于 VUE 框架。技术选型看似对设计影响不大。但到了要落地的时候，开发同学的一句“框架不支持”，能直接将你的设计打回原形。框架不支持就需要改框架，不是开发同学不做到，是真的需要很长时间。在设计的时候提前了解到开发的限制，会让我们少走弯路。
5 沟通、沟通、沟通
我认为，沟通协调是搭建组件库中最大的挑战之一：收集各个模块的产品经理、前端开发、后端开发、视觉设计的意见和建议，建立评审机制，传达设计思路，统一设计方案……
每个角色都会在各自立场对组件提出不同意见。例如，针对筛选组件：
视觉设计师希望：“样式布局应该是清晰有规律的，否则用户难以寻找信息。”
交互设计师希望：“在用户感知层面应尽快地让用户辨认出所需的筛选项，而不是每次都需要花时间寻找。”
负责财务模块的产品经理希望：“时间的筛选对于财务人员来说几乎每天都需要用到，这个应该强调。”
负责业务模块的产品经理希望：“业务的筛选场景非常个性化，一个固定的模式必然遭用户吐槽，最好有用户自定义的功能。”
开发希望：“维护的成本太高，无论在什么场景下都应该是统一的组件，统一的逻辑。”
……
涉及这么多利益相关方的讨论，不可能一次两次就可以解决。必须反复沟通，甚至能在沟通7次之后达成共识已经是不错的结果。有时候我们设计师会觉得，好不容易想出一个方案，被如此评头品足，还要推到重来，非常不爽。
仔细想想，自己的眼界往往是局限的，不可能完全了解用户在各个模块下，各个状态下的使用场景。其他角色的输出其实非常有价值。不抵触意见，接纳各种思想，抽象提炼关键设计点，才能推导出大家认可的解决方案。
6 艰难的抉择：业务独特性与组件一致性的冲突
当组件和规范已有雏形，投入使用的时候，新的问题又来了：我们应该在什么时候放弃规范，什么时候坚持规范？
除了负责组件库项目，我还是其他产品模块的设计师。这让我陷入了两难：一方面我想保证整体产品的一致性，尽量不打破原有的规则去设计，尽量使用组件覆盖业务需求；但另一方面，在一些特殊的业务场景下，不使用组件的设计方案会有更好的体验。这样的两难困境会经常遇到，业务的特殊性和组件的一致性很难共存。
以下总结了几点小建议可以分享给大家：
第一，影响全局的组件调整，建议遵循规范。比如，不可能因为一个特殊的业务去改变 导航结构，一旦改变，其他业务都会受到牵连，得不偿失。除非在一个大版本迭代中，全局考虑一并调整。
第二，用户感知弱的优化，建议遵循规范。比如，为了让用户能在一个页面内阅读更多信息，想去改变表格的行高 ，但调整后也就省了一行的高度。这种改变，用户的感知是很弱的，反而会增大开发维护的工作量。
第三，符合规范不是思考的起点。如果组件体系运行地还顺畅，我们就有可能产生依赖，一上来就规规矩矩地依照规范设计页面。而这往往是设计的禁区，组件和规范是效率工具，不应该成为我们创新的枷锁。我们思考的起点永远是用户、场景和目标。设计规范只是在最后帮我们扶正一下，哪些可以复用组件，哪些可以跟规范走。
第四，不认死理，规范就应该不断迭代。如果发现我们的组件和规范能覆盖的场景非常有限，就应该去迭代它们，而不是强行地套规范来设计。
7 走查：将理念传达出去
保证产品体验的一致性是我们的目标之一，但只完成组件库无法完全保证产品的一致性。因为相同的功能可以由不同的组件满足，相同的组件在页面上也可以有不同的布局。所以，将组件库搭建出来后还远未结束，我们需要一致性走查。
一致性走查，能规范现有页面的同时，也能在上下游对接中传达一致性的理念。比如，在开发修改的时候，我们可向他们传达：主要按钮次要按钮的用法是怎样的、什么时候应该用复选框、什么时候应该用开关等等。因为他们未必有时间去查看设计规范，面对面的传达更加有效。
另外，B端产品体量太大，不可能每个页面都有设计资源支持。不少页面并没有经过设计就直接开发。所以走查的目的不仅是把问题改好，而是将一致性的理念和设计规范传达出去。如此一来，在面对新的业务需求时，大家才会更快得把事情做好。
8 验证与迭代
对组件所做的每一个优化，都是基于用户和场景的假设，可能正中用户下怀，也有可能是一厢情愿。我们的优化需要经得起用户和市场的验证，于是对组件库进行了多次可用性测试。而每一次测试都会有意外发现。比如一些我们理所应当的操作，用户根本理解不了。又或是我们精心打磨的细节，用户其实毫不在意。所以验证-迭代是组件库不可或缺的环节，同时也是一个反复而漫长的过程。
9 创新总在矛盾中产生
组件库的难点在于需要解决各种矛盾：业务特殊性与组件通用性的矛盾、易用性与复杂度的矛盾、设计设想与开发实现的矛盾、各产品线间的需求矛盾等等。有时会陷入这些矛盾中无法绕出来，甚至矛盾是无解的，只能折中方案。
但机会与困境总是并存的，在我们的项目中，几乎所有的创新点都在矛盾中产生，有的还申请了专利。所以，拥抱矛盾，机会一直在我们眼前。
10 要为产品负责
组件库虽然是从出业务层抽离出来的东西，但其宗旨依然是服务业务。我们很容易迷失在一个个组件中，忘记业务的真实场景是什么、真实用户是谁，很容易一味地追求组件和规范本身的逻辑自洽，却忽略用户的实际感知。比如，我们严格区分了按钮和链接的区别，按钮适用于某个功能的触发，而链接隐喻着页面跳转。但用户是否会这样理解？有这样的感知？还是对于他们来说都是可点击的东西而已？组件和规范不应限死所有逻辑，我们的目的不是自圆其说，而是真切地对产品有帮助，对用户有帮助。
写在最后
通篇看下来之后，你可能会觉得，这不就跟平时的产品设计思路差不多嘛。是的，组件库就是一个产品。每个产品都值得我们细心经营、用心打磨。Thanks~
