“组件”是平台级产品非常重要的组成部分。设计组件不仅可以节省设计和开发成本，而且是设计理念的绑定体现。但随着平台级产品业务场景的复杂度不断增加，以往积累的设计组件的交互方式和可视化形式已经跟不上业务发展的需求。因此，我们思考：如何构建和迭代一个优秀的组件库——既要保持良好的普适性，又要解决跨平台的产品体验一致性问题；还要保持各业务线的特性和定制需求，即平台级组件所谓的“和而不同”。组件库升级的背景和目标随着近两年业务的发展，前期沉淀的组件逐渐不能满足业务需求，部分组件的使用率和覆盖率很低。所以我们决定对shell平台组件进行全新的升级。我们的目标不仅是优化“基础组件”，保持其良好的通用性，达到“和谐”的目的；我们也希望能够在业务线（二手房、新房、租赁房）容纳更多体验场景的需求，实现服务业务的“不同”。为了更好的实现升级目标，我们考虑了以下几个问题：1、设计构件库的使用者有哪些不同的角色？他们的要求有什么不同吗？在我们看来，设计组件是设计工作的一部分。从输出到实现的完整设计工作链条中，主要有三类人：Shell平台设计师和各业务线设计师：平台设计师提炼业务需求的同时，详尽列举组件使用场景，帮助业务线设计师使用元器件，省时省力，高效完成设计工作。开发组：通过设计师的输出，明确了组件开发的具体框架和自由度（比如按钮颜色是否支持不同的业务定制等）知道了，可以用组件构建的那部分需求确实无需重复提及，为各方节省成本。因此，设计师需要制作的不是简单的元件库源文件，而是能够站在不同角色的合作伙伴的角度理解的设计元件表达文档。△图1设计、产品、开发的不同文件样式2.组件越多越好吗？我们的结论是，不可能从所有事情开始。大部分同学在设计组件的时候都会有一种患得患失的心理，认为如果组件足够多，就可以处理更多的使用场景，规范也细化统一。但这是理想状态。如果粒度太低，设计将失去平衡。这里的不平衡意味着创新和规范之间的平衡被打破，这显然不是我们想要的。而且平台级的组件库是可以再生和可持续发展的，不需要一味追求数量。3、用什么方法可以合理控制元器件的质量和数量，选择通用性高的元器件？我们先梳理出客客平台TOP30流量的核心关键页面，根据数据划定范围，然后梳理出组成部分。如下图，我们发现使用率最高的前十个组件从高到低依次为：tabs选择>Navbar>HousingCard（常用业务组件）>BrokerBooth（常用业务组件）>Button>Notification和Prompt>BounceLayer>SearchBox>ActionsMenu>StandardFloatingBall。△图2壳牌平台流量TOP30页面组件应用这样我们就可以按照上面的优先级对使用频率高的组件进行设计和编码。我们将Keike原有组件库的所有组件打散，重新定义为三类：平台基础组件：指组件和不具备业务属性的基础组件，如按钮/表单/列表/搜索栏/系统反馈弹幕Layers/ActionBar/Navbar等。通用业务组件：指跨多个业务，但在不同的业务场景中略有变化，有通用组件可以抽取，如：经纪人展台/房卡。业务特征组件：指只属于某一业务应用类别的组件。没有公共组件可抽取，但在单一业务线复用率高。清晰的组件分类可以帮助我们在以后添加新的组件时，以统一的标准和原则进行归纳和组织。优化常用业务组件除了优化平台基础类组件外，我们还优化了常用的常用业务组件——listing列表。在壳牌平台上，列表通常以线性结构呈现。用户纵向扫描获取listing的宏观信息，横向浏览了解单个listing条目的详细信息并进行相关操作。常用于二手房、新房、租赁、出国等业务线。由于业务的发展，贝壳平台原有的房源列表样式，逐渐增加了需要展示的信息，一一列在列表中，导致展示效率低下，没有吸引用户的亮点，最终导致用户对于房源清单的“决策效率”下降。”。为了提高决策效率，让优化后的列表在各个业务线都可用，首先要了解在不同的业务场景下，列表卡片应该展示哪些内容？这里套用之前研究得出的结论——用户浏览列表的心智模型。△图3用户浏览房源心智模型在心智模型的指导下，我们进行了“元素穷举”。△图4详尽的元素列表在获取到具体要展示的元素后，我们开始思考一个高度包容的列表的底层结构应该是什么样的。经过几次反复的推敲和尝试，我们得出了如图所示的三层结构：容器背板层、互操作层、内容展示层。△图5列表列表三层结构容器背板层：是承载列表内部所有内容的盒子。在这一层中，我们定义了容器的形状、圆角等属性，使其成为一个统一的底层模板。互操作层：这一层是针对用户可以对列表进行的所有操作，比如关注、查看VR图片等，并且我们为每个具体的操作行为定义了统一的交互方式。内容展示层：该层涵盖了所有用户可以查看的具体信息，包括房屋产权、房产名称、房屋详情和价格动态波动信息。通过三个层级的划分，我们可以明确各个层级的具体职责，有助于我们在后期面对复杂的业务场景和海量的信息内容时，更好的归纳和组织信息的呈现。完成元素穷尽和结构分层后，我们绘制了一个基本框架模板，如下图所示：△图6listing列表的基本框架然后我们将不同业务线的具体细节嵌入到模板中，进行设计对于不同业务和场景使用的每个列表列表。有了这样的设计成果，我们与业务线的产品经理和设计师进行了深入的讨论，确定了迭代的节奏。从14天的数据和结果来看，二手房改造后的点击率从44.65%上升到51.35%。这对于列表来说是非常罕见的。△图7修改后数据结果汇总以上为本文全部内容。相信你已经掌握了构建C端组件库的基本方法。这里我们总结一下组件库的创建过程：△图8C端组件库的创建过程组件库是每一位用户体验设计师在日常工作中积累的设计资产。组件应该“和而不同”。“和谐”是指使用标准化的底层容器，将提取出来的复用率高的元素进行包装，形成体验一致、交互一致的封装模块。“不同”是指各业务线可以根据自己特定的使用场景，定义内容展示层展示的元素，保证一定的自由度和自主成长的能力。物业列表在贝壳平台首页已经有半年左右的时间了。通过改版，一定程度上提高了用户使用房产清单的决策效率，业务覆盖面逐步扩大。在研发老师的配合下，实现了Native和Flutter组件的封装，大大缩短了开发时间，提升了产品整体研发效率。希望能给同样在构建组件库的设计师和同学们带来一些启发。壳牌用户体验团队将继续致力于挖掘更多业务特性组件，期待您的关注。
