如何打造一个优秀的C端组件库？来看贝壳设计的实战案例！

“组件”是渠道级产品十分重要的组成部分，规划组件不仅能够节省规划和开发本钱，更是规划理念的束缚性表现。可是，跟着渠道级产品事务场景的复杂度不断添加，过往沉淀的规划组件的交互方法和视觉方法，却跟不上事务开展的诉求。因而，咱们考虑：怎么树立和迭代一个优异的组件库——不仅能坚持良好的普适性，处理全渠道产品的体会共同性的问题；而且能够坚持各个事务线的特征和定制化需求，即所谓渠道级组件的“和而不同”。

晋级组件库的布景和目标

跟着近两年事务的开展，前期沉淀的组件渐渐无法满意事务诉求，一部分组件的运用率和覆盖率很低。

因而咱们决议对贝壳渠道组件进行一次全新的晋级。咱们的目标不仅是针对“根底组件”进行优化，坚持其良好的通用性，达到“和”的目的；更期望能够承载事务线（二手房、新房和租房）更多体会场景的需求，做到服务于事务的“不同”。

为了更好的完结晋级目标，咱们考虑了以下几个问题：

1. 规划组件库的运用人员有哪些不同的人物？他们的诉求是否有区别？

在咱们眼里，规划组件是对规划工作的一种管理，而规划工作从产出到落地的完好链条上，主要有三种人物的人群：

贝壳渠道规划师和各个事务线规划师：渠道规划师穷举组件运用场景的一起，提炼事务诉求，协助事务线规划师经过组件更省时省力的高效完结规划工作。

开发团队：经过规划师的输出，明晰组件开发的详细结构和自由度（例如按钮色彩是否支持不同事务自界说等）

产品团队：经过规划组件文档明晰规划的规范，在各人物有一起规范的认知下，需求中可运用组件树立的部分无需重复提需求，节省各方本钱。

因而，规划师需求产出的并不是一份简略的组件库源文件，而是一份以不同人物合作伙伴的视角，都能看得懂的规划组件表达文档。

△ 图 1 给规划、产品和开发不同的文件样式

2. 组件真的是越多越好吗？

咱们给出的结论是：八面玲珑反而无从下手。在做规划组件时，大多数同学都会有患得患失的心思，认为组件足够多，就能够应对更多的运用场景，规范也足够细致和共同。

可是这是一个比较抱负的状况，过于低微的颗粒度下，规划反而会失衡。这儿的失衡是指，创新和规范之间的平衡被打破，显然不是咱们想要的。而且渠道级组件库是具备再生和持续开展的生长才干的，因而不必一味追求数量。

3. 采用什么方法能够合理的操控组件的质量和数量，挑选出通费用高的组件呢？

咱们优先梳理了贝壳渠道流量 TOP30 的中心要害页面，依据数据圈定范围，然后进行组件的收拾。如下图，咱们发现运用率最高的前十名组件，按照降序摆放顺次为：tabs 挑选>Navbar>房源卡片（事务通用组件）>经纪人展位（事务通用组件）>按钮>通知与提示>弹层>查找框>操作菜单>规范悬浮球。

△ 图 2 贝壳渠道流量 TOP30 页面组件运用状况

这样，咱们就能够按照以上优先级，优先规划和代码化运用频次较高的组件。

咱们将贝壳原有组件库的悉数组件打散，从头界说后分红三大类别：

渠道根底组件：指不具有事务属性的元件及根底组件，例如：按钮/表单/列表/查找栏/体系反馈弹层/操作栏/Navbar 等。

事务通用组件：指横跨多事务，但在不同的事务场景中略有变化，有公共元件可提炼，例如：经纪人展位/房源卡片。

事务特性组件：指只归于某一事务运用范畴的组件，无公共元件可提炼，可是在单一事务线复用率较高。

组件的明晰分类，能够协助咱们在日后每当有新增组件时，以共同的规范和准则进行概括和收拾。

优化事务通用组件

除了优化渠道根底类型的组件外，咱们还对其间运用频率很高的事务通用组件——房源列表进行了优化。

房源列表是在贝壳渠道通常以线性结构出现的。用户经过纵向扫读来获取房源微观信息，横线阅读来了解单个房源条目的细节信息并进行相关操作。它在二手房、新房、租借、海外等等事务线，都会经常被运用到。贝壳渠道原房源列表样式，由于事务的开展，需求展现的信息逐渐增多，顺次罗列在列表中，导致展现功率变低，无吸引用户的亮点，终究导致用户对房源列表的“决议计划功率降低”。

而想要提高决议计划功率，而且优化后的列表能够在各个事务线运用，咱们先要了解，在不同事务场景中，房源卡片都要展现哪些内容？这儿咱们运用到了从前研究得出的结论——用户阅读房源列表的心智模型。

△ 图 3 用户阅读房源的心智模型

在心智模型的指导下，咱们进行了“元素穷举”。

△ 图 4 元素穷举

得到了详细展现哪些元素后，咱们开始考虑，一个包容性强的列表底层结构应该是什么姿态？经过几次的反复推敲和测验，咱们得出如图所示的三层结构：容器背板层、可交互操作层、内容展现层。

△ 图 5 房源列表的三层结构

容器背板层：它是承载列表内部一切内容的盒子，咱们在这一层，界说了容器的形状，圆角等属性，使它成为一个共同的底层模版。

可交互操作层：这一层放置的是用户关于列表可进行的悉数操作，例如重视，检查 VR 图片等。而且，咱们针对详细每一种操作行为，界说了共同的交互方法。

内容展现层：这一层涵盖一切用户能够检查的详细信息，包括房源标题、楼盘称号、房源详细信息和价格的动态起浮变化信息。

经过三个层次的划分，咱们能够明晰的界说每个层次的详细的职责是什么，这有利于咱们后期面对复杂事务场景和海量信息内容时，能够更好的去概括和安排信息的出现。

在完结了元素穷举和结构分层之后，咱们绘制了一个根底结构模版，如下图：

△ 图 6 房源列表根底结构

然后咱们将不同事务线的详细细节信息，嵌入模版中，规划成各个针对不同事务和不同场景运用的房源列表。带着这样的规划结果，咱们与事务线的产品司理和规划师同学进行了一次深入的讨论，而且确定可推广迭代的节奏。

数据与结果

综合 14 天数据，二手房改版后，CTR 由原来的 44.65%提高到 51.35%。这关于房源列表来说，是十分可贵的。

△ 图 7 改版后的数据结果

总结

以上就是本文的悉数内容，信任咱们已经把握了 C 端组件库树立的根本方法，这儿咱们总结一下组件库的创立流程：

△ 图 8 C 端组件库的创立流程

组件库是每一位用户体会规划师，在日常工作中积累的规划资产。组件要做到“和而不同”，“和”是指用规范化的底层容器，将抽离出复用率高的元素包裹起来，形成体会共同，交互共同的封装模块。“不同”是指，每条事务线能够根据自身详细的运用场景，去界说各自在内容展现层要展现的元素，保证了必定的自由度和各自生长的才干。

房源列表在贝壳渠道主页已经上线有半年左右的时刻了，经过改版，用户运用房源列表时的决议计划功率有必定程度的提高，事务覆盖也逐渐扩大。在研制教师的协同下，完结了 Native 和 Flutter 组件的封装，大大缩短了开发时长，然后提高了产品全体的研制功率。

期望能给相同正在树立组件库的规划师同学们带来一些启发，贝壳用户体会团队也会继续致力于更多事务特性组件的深挖，等待你的重视。

欢迎重视作者微信公众号：「贝壳KEDC」