首页_天运注册_首页最近B端很火，招聘B端设计师的HC也很多，多数招聘JD中（如下图）都要求有“设计规范”、“搭建设计组件”的要求。而设计组件是设计规范中的重要部分，可见它的重要性。

　　笔者从毕业开始，主要在做B端交互，前前后后也有6年经验了。这里谈谈关于搭建B端设计组件库的一些思考，和大家分享，如有不同见解，欢迎讨论。本文主要包含以下4部分内容：①什么是B端设计组件？②为什么要搭建B端组件库？③搭建B端组件库的2种方式；④搭建B端组件库的注意事项。

　　不同人在不同的背景下，对设计组件的定义是不同的。本文所说的设计组件是适用于一般B端系统的、稳定且高复用性的内容，比如单选框、复选框、表单、表格等。

　　多数B端产品是UX（偏交互）直接输出高保真设计稿，设计师要负责架构、流程、页面内交互的所有细节。举个例子来说，搜索框这个组件，如果没有组件库，设计师要说明的内容太多了，比如默认样式、输入内容后是实时查询还是按钮触发查询、是否展示历史搜索记录、搜索内容展示框的大小、无搜索结果怎么展示等等。如果每次遇到搜索框都要定义一遍，设计师简直要累死。有了组件库，定义出搜索框常用的几种类型，设计师只需要在使用时说明是哪种搜索类型即可。

　　还拿上面的搜索框举例，如果系统中的搜索框在样式、使用场景、交互细节方面不一致，用户使用起来也很困难，影响用户的操作效率。

　　现在市场上成熟的设计组件库有很多，比如Element、Ant Design、Zent、Material Design等。根据自己业务系统里的实际情况，选取使用的组件内容，放入组件库，比如按钮、表单、弹窗等。

　　这种方式的优点就是快速、成本低。缺点也很明显，就是“知其然而不知其所以然”。

　　举个例子来说，我们复用Element搭建了自己的B端产品。但是Element都是白底黑字，当业务需要黑底模式时，我们就需要重新定义一套颜色使用规范。但是，Element框架中有几种中性色，这些色值会应用到不同组件（如下拉选择器、列表标头）、在不同状态（如默认态、hover态、选中态）的文字、线、框、背景、阴影颜色中，当设计师根据自己的经验定义一套颜色时，发现在实际的页面中会有各种问题，比如下图中，下拉框选择区域背景色块与周围颜色区分度很低。

　　反思下原因，就是因为我们只知道需要定义几种颜色，但是不知道这些颜色用在什么场景，也不知道Element当初这样使用颜色的逻辑是什么。在黑底模式下，Element原来的逻辑是否适用？浮层与底部背景之间采用什么方式做颜色区分更科学，是透明度叠加还是定义几个颜色等级？

　　所以，这里建议大家在复用别人的组件框架时，尽量多探索背后的逻辑和设计原则是什么。当出现问题时，及时调整方案，不断迭代规范，这样可以沉淀出适合自己业务的组件库。

　　从零搭建组件库，就需要设计师投入极大的精力。思考设计价值观，并以此为标准，从业务中提取高复用的内容，梳理出点（色彩、文字、图标、阴影等）、线和面（按钮、搜索、表单、列表、分页器等）。

　　有时，为了给出更科学的组件方案，可能需要做人因研究（比如表单组件中，Lable与输入框的对齐方式有顶对齐、左对齐、右对齐3种，哪种方案最佳？）、数据验证研究（比如什么特征的文案能够提高转化，是“免费注册”还是“免费试用”？错误提示文案用户更倾向于正向引导还是负向反馈？）

　　实际研究证实的方案让我们“知其然，也知其所以然”。这样，从业务中梳理的点与线、面的逻辑关系是清晰的。

　　个人认为，设计师做事要以能够落地为前提，切勿“闭门造车”。如果前端不认可，设计组件无法落地到实际产品中，那设计组件就没有多少价值。所以，开始做设计组件时，就要和前端协作。

　　组件库搭建完之后，需要持续优化迭代。如果因为业务发展，出现组件无法满足需求时，可能还需要制作新的组件。比如穿梭框是B端常用组件，但是这个组件可选择的内容只有对象的名称，如果业务需要选择的内容包含多个维度，比如对象的名称、属性信息，并且需要支持筛选时，这个组件就无法满足业务需要了。此时，就需要制作业务组件。

　　成熟的设计组件库内容很多，但是有些在自己业务中是用不到的，比如“回到顶部”一般只有在页面很长的情况下才会使用。如果自己的业务中暂时用不到，就不建议设计师花精力放入组件库。因为真正用到的时候，也许会因为某些原因无法直接复用，现在做出来也没有价值。