惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
GbyAI
GbyAI
G
Google Developers Blog
Engineering at Meta
Engineering at Meta
月光博客
月光博客
腾讯CDC
Recent Announcements
Recent Announcements
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
S
SegmentFault 最新的问题
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
阮一峰的网络日志
阮一峰的网络日志
博客园 - 【当耐特】
The GitHub Blog
The GitHub Blog
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
aimingoo的专栏
aimingoo的专栏
Google DeepMind News
Google DeepMind News
Y
Y Combinator Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Martin Fowler
Martin Fowler
A
About on SuperTechFans
博客园 - 叶小钗

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
关于设计组件库,我们有一些新思考
百度MEUX · 2025-02-20 · via 人人都是产品经理

设计组件库是提升设计效率和一致性的重要工具,但如何在频繁迭代和动态调整中高效赋能业务设计交付,一直是行业面临的挑战。本文作者分享了他们在设计组件库建设中的新思考和实践,供大家参考学习。

2025年竟然还有人在写组件搭建方法论!但这次我们有了一些新思考~

前期我们介绍了设计系统的1.0 “统一化”(详见百度搜索设计系统丨庞杂中建立秩序),通过提升资产内在一致性来优化消费体验。这次我们将从更实操的角度,探讨如何从组件库建设的角度入手,提升资产消费效率。

本文将分享我们对于“什么是好的设计组件”的看法,并给出一种搭建复杂组件的实用思路。我们还会从资产消费的角度,提供一些优化建议。虽然过程中会涉及不少基于Figma软件的操作细节,但核心思路就像一把“万能钥匙”,无论在哪个设计平台都行之有效,希望这些内容能给广大设计师们带来一些新的启发。

01 “好的设计组件”在搜索设计场景中的定义

从网上搜索设计组件,我们能找到各种对外公开的设计组件库,同样还有不少或概括或详细的文章,手把手教你“如何搭建一个好的设计组件库”,但这些方法论很少探讨面对C端组件频繁增改、设计规范动态调整,如何高效赋能业务设计交付的相关内容,但这恰恰是搜索业务面临的关键问题。

搜索是一个“牵一发而动全身”的业务,每一个微小的设计细节都有可能影响各个业务的数据指标,一个“好的设计组件库”需要以一种潜移默化的方式让设计师掌握设计规范,完成合规的设计,从这个角度而言它应该比较「好懂」。

而作为服务于整个设计团队的公用设计组件库,面对每月数以万计的调用次数,它必须保障最基本的易用性,应该非常「好用」。

同时,面对频繁迭代,“好的设计组件”还需要保持最快的更新速度,为各个横向团队提供正确的样式,从这个角度来说它还要「好维护」。

因此,「好懂、好用、好维护」是搜索设计语境下,对一个“好的设计组件”的定义。

接下来,我们将从这三个「好」入手,分享搜索设计组件库在升级过程中的一些思考,希望能和大家共同探讨。

02 好懂:一种耦合设计规范的组件搭建方式

“万丈高楼平地起”,我们先来说说如何从零开始构建一个既符合设计规范又易于理解的设计组件。

首先,在搭建组件时,我们可以考虑采用多层嵌套的方式,即组件(Component)内部嵌套变体(Instance)。这种方式不仅能省去组件搭建和修改过程中的重复操作,甚至还能在解绑组件时,通过选中内部的子组件图层进行解绑,大大简化了搭建和使用双方的操作流程。

在多层嵌套的思路下,我们可以进一步用“底层灵活、上层收敛”来指导组件的搭建。这意味着底层变体的形式足够多样,能够支持大部分的状态切换,而在上层组件搭建的过程中显性地加强规范的指引(如规范中不允许使用的样式不对外展示),以降低超出规范设计的可能。

具体的搭建流程可以大致分为三步:场景收集和分析、搭建基本变体组、拓展高阶变体组。

我们将通过视频组件搭建的生动案例,具体介绍如何依据“底层灵活、上层收敛”原则来搭建组件库,使得组件本身既足够灵活,又能起到足够的约束作用。

在着手搭建某类组件时,我们首先通过规范确认和场景遍历,广泛收集各类变体。

随后,从我们能想到的所有维度出发,对这些变体进行细致定义。

这样,我们就能得到一张详尽描述组件变体性质的表格。表格的第一列依次列出变体1、变体2、变体3等,而第一行则罗列出各种维度,如宽度、比例等。

通过这种方法,我们可以将原本零散、杂乱的组件变体描述,系统地归纳整理成一张清晰明了的表格。

表格通过不同维度来唯一确定一个变体,这些维度可大致分为两个特性和一个共性。共性指的是所有变体在这一维度上均保持一致,常见特性则涵盖了最常见的分类性质,如宽度、高度、数量和优先级等,而业务特性则与具体业务紧密相关。

在搭建组件时,我们可以遵循「共性-常见特性-业务特性」顺序,这样的顺序有助于降低理解成本,因为最符合心智的分类被置于外层,同时底层的组件又保持了足够的灵活性,便于切换各种变量。对于业务特性,我们可以根据实际情况灵活处理,既可以将其作为基本组件的延展,也可以不将其纳入组件范畴。

以视频组件为例,我们从表格中获取的信息如下:

  • 视频尺寸及其组合是最符合用户心智的变体选择;
  • 播放状态是所有变体的共有性质;
  • 自动播放情况与业务相关,但不一定需要在组件库中呈现;
  • 高阶组件仅涉及少部分尺寸的组件,应在完成基本组件搭建后再进行。

据此,我们可以轻松梳理出视频组件搭建流程的优先级:

  1. 播放状态作为共性,应首先搭建;
  2. 基本组件尺寸和组合是最符合用户心智的变体选择,应紧随其后;
  3. 高阶组件在完成基本组件搭建后再进行。

值得注意的是,“封面槽位”是“播放状态”中的一个图层。根据“底层灵活、上层收敛”的原则,我们将其插入到搭建播放状态之前。

因此,视频组件的最终搭建流程为:

  1. 封面槽位;
  2. 播放状态;
  3. 基本组件尺寸和组合;
  4. 高阶组件。

完成对视频组件搭建的分析,我们就可以有条不紊地开始搭建组件了。

先搭建基本组件视频组件,再用基本组件搭建高阶组件。

这一步骤虽然为大家所熟知,但仍需格外注意,如配置项的设置要力求合理,也可以融入设计规范和使用规范,同时还应将一些搭建过程中的零散组件集中收纳避免被调用。

关于这些具体的注意事项,我们将在后续部分进行详细阐述。

至此我们完成了组件搭建的基本流程,一个达到及格线的视频组件就诞生了。

据统计,优化后每次调用视频组件将节省至少10步的点击操作!

03 好用:消费视角下的组件自检

完成了一个基本组件的搭建后,我们可以转换视角,从使用的角度来审视并检查这个组件。

我们期望,从插入组件变体、切换组件配置,再到最后的解绑组件,整个流程都能纵享丝滑且稳定可靠,确保业务设计师在使用过程中获得最佳体验。

我们可以一步步来审视组件的使用过程。

首先是插入组件,据观察,通常有三种方式:

①在左侧的资产面板(Assets)中直接找到对应组件并插入;

②通过查阅设计规范,锁定所需的变体后复制粘贴;

③选中一个不需要的组件,通过右侧的“切换变体”面板(Swap instance)切换成所需的变体。

很明显,在这个过程中依赖的是组件的精准搜索和快速定位。

为了提升搜索精度,我们可以从组件命名入手,采用中、英、数字结合的方式,实现模糊匹配;也可以在发布时隐藏不希望被调用的组件,以减少无用的搜索结果。

如果组件是采用前文提到的“多层嵌套”方式搭建的,我们可以添加“Preferred”子组件,这样在切换时会优先展示这些子组件,这个功能在切换图标时尤为实用。

对于习惯边查阅设计规范边使用组件的设计师,我们增加了更多实际使用的正误案例,这些案例直观展示了组件变体的正确选择和使用方式,进一步降低了规范的理解成本,有效辅助设计决策。同时,我们专门维护了一个固定区域,用于平铺展示所有组件变体。

为了确保能够轻松点选,我们将变体放在最外层展示(即不在任何Frame、Group或Section中)。这样能让设计师一目了然地看到所有变体,从而快速选择所需的组件。

在组件配置阶段,有三项注意点能让组件更加易用,即“重视组件的可视化效果、设置高效易用的配置项、贴心地保存修改”。

考虑到C端组件的多样性和用户的使用习惯,我们应避免使用过于复杂的分组方式。相反,应更注重组件的样式展示,并尽量简化组件的层级结构。这样,设计师在使用时能够更直观地看到组件的外观,而无需深入复杂的层级去查找。

另外值得注意的是,Figma会默认用组件集合中最左上角的组件生成预览样式,因此应当把视觉上最有代表性的变体放在左上角,这个效果在切换变体(Swap instance)时很重要,因为目前在该面板中没法查看组件细节,只能靠缩略图和名称来推测是哪个组件。

其次对于配置项的设置也大有讲究,业界有组件库为了实现C2D2C,从源头上将设计组件和前端组件的配置项打平,这是不错的思路,但有可能会提升设计侧的理解成本。

针对搜索业务的特殊语境,我们还是选择了从「规范理解」角度去设置组件的配置项,将所有允许自定义的配置尽可能外露,并清晰地说明修改限制,如字数限定、选项个数等,这样能够在使用的过程中强化业务设计师对规范的掌握。

另一个常常被忽视的关键点是选项和配置的排序问题。为了提高浏览和选择的效率,建议对选项和选项之间,以及外层的不同配置项,都按照一定的逻辑顺序进行排序。

最后一点,我们称之为“贴心地保存修改”机制,这个针对的是文字修改的场景。

在实际操作中,使用一个组件可能需要对多个配置项进行修改。有时在修改完文字内容后再去调整其他配置时,已修改的文字会被重置。这时文本属性(text property)的设置就显得尤为重要,它能够记忆并保存修改过的文字内容,从而免于重复输入。

还有一些情况是,某个组件变体实际上并没有与某个值相对应的组件(尽管Figma机制允许选择该值),用户切换后就会发现组件完全变了,只能撤回。

为了避免这类情况,建议使用另外的标记来表明组件某个设置项是不可切换的。

04 好维护:持续监测,不断迭代

完成了组件的搭建和检查,接下来让我们聚焦于组件的日常维护。

这一环节可以从两个维度展开,一是依托中台的日常数据监控进行维护,二是通过团队内部的紧密协同机制来保障。后者更多侧重协作流程和机制上的建设,在本文中我们不做更多展开,重点讨论前者。

数据监控的方式主要依托Figma中的组件数据看板(查看路径:View libraries-Analytics),看板中展示了各个组件的调用数和解绑数数据,这些数据不直接反映组件的优劣,但如果我们观测到某个组件解绑率偏高,我们会考虑直接把它作为模板而不是创建成组件。

总结

以上是百度搜索设计团队在设计组件库升级过程中的心得分享,包括搜索业务对于“好的设计组件”的诉求,以及一些搭建和优化组件的实用思路,核心是探讨如何从组件库建设的角度入手,成功助力团队提升设计资产消费效率。

当前我们已经完成设计资产工程化的前序环节,我们对设计资产的升级和探索并没有结束,未来我们将持续探索设计系统工具化的形态、与AI大模型结合的机会,通过丰富消费途径,实现在业务交付的不同阶段下全方位提效。

这部分内容后续有机会也将会和大家见面,请大家期待!

本文由人人都是产品经理作者【百度MEUX】,微信公众号:【百度MEUX】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。