2025 年竟然还有人在写组件搭建方法论 ！复杂但这次我们有了一些新思考~
前期我们介绍了设计系统的设都能搭建 1.0 "统一化" ，通过提升资产内在一致性来优化消费体验 ，计组件库详见 ：
这次我们将从更实操的掌握角度 ，探讨如何从组件库建设的个万角度入手，提升资产消费效率。复杂
本文将分享我们对于"什么是设都能搭建好的设计组件"的看法 ，并给出一种搭建复杂组件的计组件库实用思路 。我们还会从资产消费的掌握角度 ，提供一些优化建议。个万虽然过程中会涉及不少基于 Figma 软件的复杂操作细节 ，但核心思路就像一把"万能钥匙" ，设都能搭建无论在哪个设计平台都行之有效 ，计组件库希望这些内容能给广大设计师们带来一些新的启发。
从网上搜索设计组件，我们能找到各种对外公开的设计组件库 ，同样还有不少或概括或详细的文章 ，手把手教你"如何搭建一个好的设计组件库" ，但这些方法论很少探讨面对 C 端组件频繁增改 、设计规范动态调整 ，如何高效赋能业务设计交付的相关内容 ，但这恰恰是搜索业务面临的关键问题。
搜索是一个"牵一发而动全身"的业务，每一个微小的设计细节都有可能影响各个业务的数据指标 ，一个"好的设计组件库"需要以一种潜移默化的方式让设计师掌握设计规范 ，完成合规的设计，从这个角度而言它应该比较「好懂」 。
而作为服务于整个设计团队的公用设计组件库 ，面对每月数以万计的调用次数 ，它必须保障最基本的易用性 ，应该非常「好用」 。
同时 ，面对频繁迭代 ，"好的设计组件"还需要保持最快的更新速度 ，为各个横向团队提供正确的样式 ，从这个角度来说它还要「好维护」 。
因此 ，「好懂 、好用 、好维护」是搜索设计语境下 ，对一个"好的设计组件"的定义 。
接下来 ，我们将从这三个「好」入手 ，分享搜索设计组件库在升级过程中的一些思考 ，希望能和大家共同探讨 。
"万丈高楼平地起" ，我们先来说说如何从零开始构建一个既符合设计规范又易于理解的设计组件 。
首先 ，在搭建组件时 ，我们可以考虑采用多层嵌套的方式 ，即组件(Component)内部嵌套变体(Instance) 。这种方式不仅能省去组件搭建和修改过程中的重复操作 ，甚至还能在解绑组件时，通过选中内部的子组件图层进行解绑 ，大大简化了搭建和使用双方的操作流程 。
在多层嵌套的思路下 ，我们可以进一步用"底层灵活 、上层收敛"来指导组件的搭建。这意味着底层变体的形式足够多样，能够支持大部分的状态切换 ，而在上层组件搭建的过程中显性地加强规范的指引(如规范中不允许使用的样式不对外展示) ，以降低超出规范设计的可能。
具体的搭建流程可以大致分为三步 ：场景收集和分析、搭建基本变体组、拓展高阶变体组 。
我们将通过视频组件搭建的生动案例 ，具体介绍如何依据"底层灵活 、上层收敛"原则来搭建组件库，使得组件本身既足够灵活 ，又能起到足够的约束作用 。
在着手搭建某类组件时 ，我们首先通过规范确认和场景遍历 ，广泛收集各类变体 。随后 ，从我们能想到的所有维度出发 ，对这些变体进行细致定义 。这样 ，我们就能得到一张详尽描述组件变体性质的表格 。表格的第一列依次列出变体 1、变体 2 、变体 3 等 ，而第一行则罗列出各种维度 ，如宽度、比例等 。通过这种方法，我们可以将原本零散 、杂乱的组件变体描述 ，系统地归纳整理成一张清晰明了的表格 。
表格通过不同维度来唯一确定一个变体 ，这些维度可大致分为两个特性和一个共性 。共性指的是所有变体在这一维度上均保持一致 ，常见特性则涵盖了最常见的分类性质 ，如宽度 、高度、数量和优先级等 ，而业务特性则与具体业务紧密相关。
在搭建组件时，我们可以遵循「共性-常见特性-业务特性」顺序 ，这样的顺序有助于降低理解成本 ，因为最符合心智的分类被置于外层 ，同时底层的组件又保持了足够的灵活性 ，便于切换各种变量 。对于业务特性 ，我们可以根据实际情况灵活处理 ，既可以将其作为基本组件的延展，也可以不将其纳入组件范畴 。
以视频组件为例 ，我们从表格中获取的信息如下：
据此 ，我们可以轻松梳理出视频组件搭建流程的优先级：
值得注意的是 ，"封面槽位"是"播放状态"中的一个图层 。根据"底层灵活 、上层收敛"的原则 ，我们将其插入到搭建播放状态之前 。因此，视频组件的最终搭建流程为 ：
完成对视频组件搭建的分析，我们就可以有条不紊地开始搭建组件了 。先搭建基本组件视频组件 ，再用基本组件搭建高阶组件 。这一步骤虽然为大家所熟知 ，但仍需格外注意 ，如配置项的设置要力求合理，也可以融入设计规范和使用规范 ，同时还应将一些搭建过程中的零散组件集中收纳避免被调用 。关于这些具体的注意事项 ，我们将在后续部分进行详细阐述 。
至此我们完成了组件搭建的基本流程，一个达到及格线的视频组件就诞生了 。据统计 ，优化后每次调用视频组件将节省至少 10 步的点击操作 ！
完成了一个基本组件的搭建后 ，我们可以转换视角 ，从使用的角度来审视并检查这个组件。
我们期望，从插入组件变体、切换组件配置 ，再到最后的解绑组件 ，整个流程都能纵享丝滑且稳定可靠 ，确保业务设计师在使用过程中获得最佳体验 。
我们可以一步步来审视组件的使用过程。首先是插入组件 ，据观察 ，通常有三种方式 ，①在左侧的资产面板(Assets)中直接找到对应组件并插入；②通过查阅设计规范，锁定所需的变体后复制粘贴；③选中一个不需要的组件 ，通过右侧的"切换变体"面板(Swap instance)切换成所需的变体 。很明显 ，在这个过程中依赖的是组件的精准搜索和快速定位。
为了提升搜索精度 ，我们可以从组件命名入手 ，采用中 、英 、数字结合的方式，实现模糊匹配；也可以在发布时隐藏不希望被调用的组件，以减少无用的搜索结果 。如果组件是采用前文提到的"多层嵌套"方式搭建的 ，我们可以添加"Preferred"子组件 ，这样在切换时会优先展示这些子组件 ，这个功能在切换图标时尤为实用。
对于习惯边查阅设计规范边使用组件的设计师，我们增加了更多实际使用的正误案例 ，这些案例直观展示了组件变体的正确选择和使用方式 ，进一步降低了规范的理解成本，有效辅助设计决策 。同时 ，我们专门维护了一个固定区域 ，用于平铺展示所有组件变体。为了确保能够轻松点选 ，我们将变体放在最外层展示(即不在任何 Frame 、Group 或 Section 中) 。这样能让设计师一目了然地看到所有变体 ，从而快速选择所需的组件 。
在组件配置阶段 ，有三项注意点能让组件更加易用 ，即"重视组件的可视化效果 、设置高效易用的配置项 、贴心地保存修改" 。
考虑到 C 端组件的多样性和用户的使用习惯 ，我们应避免使用过于复杂的分组方式 。相反，应更注重组件的样式展示 ，并尽量简化组件的层级结构 。这样 ，设计师在使用时能够更直观地看到组件的外观 ，而无需深入复杂的层级去查找 。
另外值得注意的是 ，Figma 会默认用组件集合中最左上角的组件生成预览样式 ，因此应当把视觉上最有代表性的变体放在左上角 ，这个效果在切换变体(Swap instance)时很重要 ，因为目前在该面板中没法查看组件细节 ，只能靠缩略图和名称来推测是哪个组件 。
其次对于配置项的设置也大有讲究 ，业界有组件库为了实现 C2D2C ，从源头上将设计组件和前端组件的配置项打平 ，这是不错的思路 ，但有可能会提升设计侧的理解成本 。针对搜索业务的特殊语境，我们还是选择了从「规范理解」角度去设置组件的配置项 ，将所有允许自定义的配置尽可能外露 ，并清晰地说明修改限制 ，如字数限定 、选项个数等 ，这样能够在使用的过程中强化业务设计师对规范的掌握 。
另一个常常被忽视的关键点是选项和配置的排序问题 。为了提高浏览和选择的效率 ，建议对选项和选项之间，以及外层的不同配置项 ，都按照一定的逻辑顺序进行排序。
最后一点 ，我们称之为"贴心地保存修改"机制 ，这个针对的是文字修改的场景 。
在实际操作中 ，使用一个组件可能需要对多个配置项进行修改 。有时在修改完文字内容后再去调整其他配置时 ，已修改的文字会被重置 。这时文本属性(text property)的设置就显得尤为重要，它能够记忆并保存修改过的文字内容 ，从而免于重复输入 。
还有一些情况是 ，某个组件变体实际上并没有与某个值相对应的组件(尽管 Figma 机制允许选择该值)，用户切换后就会发现组件完全变了 ，只能撤回 。为了避免这类情况 ，建议使用另外的标记来表明组件某个设置项是不可切换的 。
完成了组件的搭建和检查 ，接下来让我们聚焦于组件的日常维护 。
这一环节可以从两个维度展开，一是依托中台的日常数据监控进行维护 ，二是通过团队内部的紧密协同机制来保障 。后者更多侧重协作流程和机制上的建设 ，在本文中我们不做更多展开 ，重点讨论前者 。
数据监控的方式主要依托 Figma 中的组件数据看板(查看路径：View libraries-Analytics) ，看板中展示了各个组件的调用数和解绑数数据 ，这些数据不直接反映组件的优劣 ，但如果我们观测到某个组件解绑率偏高 ，我们会考虑直接把它作为模板而不是创建成组件 。
以上是百度搜索设计团队在设计组件库升级过程中的心得分享，包括搜索业务对于"好的设计组件"的诉求，以及一些搭建和优化组件的实用思路 ，核心是探讨如何从组件库建设的角度入手 ，成功助力团队提升设计资产消费效率 。
当前我们已经完成设计资产工程化的前序环节 ，我们对设计资产的升级和探索并没有结束 ，未来我们将持续探索设计系统工具化的形态 、与 AI 大模型结合的机会 ，通过丰富消费途径 ，实现在业务交付的不同阶段下全方位提效 。这部分内容后续有机会也将会和大家见面 ，请大家期待 ！
作者：百度MEUX
关注微信
