Design System

There’s a lot of rumors of a big impending UI redesign from Apple.
Let’s imagine what’s (or what could be) next for the design of iPhones, Macs and iPads.

Timeline

Timeline

2024 - Now

Teammates

Product & Engineering

Contributions

Product Design, Product Management, Strategy

内容概览

02/ Figma 的组件化建设

03/ 数字资产的云端化建设

04/ 设计系统的文档化建设

05/ 设计系统度量体系

06/ 结语与致谢

Section 01

项目背景

我于 2023 年夏天加入百度 MEUX 体验设计中心,主导搭建新一代内容生态设计系统,目标是为百家号生态下的多类产品提供一致性强、可扩展性高的设计支持。

该项目几乎从零开始,旨在构建一套灵活、可定制、具备持续演进能力的系统,能够覆盖从创作者平台 (百家号)、营销平台 (度星选) 及 AIGC 工具 (度加),到多种内部运营与管理工具在内的多样化产品形态与界面需求。

在此之前,团队依赖的是一个基于 Ant Design 代码库逐步演化而来的 React 组件集合。尽管积累深厚,但这一架构已难以支撑日益增长的业务复杂性与产品场景的差异化,亟需一次系统性的重构与升级。

Baidu 内容生态产品业务概览

内容生态产品体系的 UI 场景高度多样,涵盖下图内容:

我联合设计及前端团队,通过对 组件抽象、模块化建设、Token 语义规范、组件工程标准 的系统性构建,确立了一套统一的设计语言与技术方案选型,实现了设计系统的全面重构与落地应用。

内容生态的主要业务产品范围

Section 02

设计变量引入内容生态

在我加入百度时,Design Token 已不再是新兴概念。

早在 2022 年,我在快手中台团队主导并落地了面向 B 端效率工具的 Design Token 体系。相比之下,百度内容生态仍普遍采用十六进制硬编码,缺乏语义统一与系统治理。

因此,在设计系统的初期建设阶段,我将 Design Token 的引入与规范化作为高优任务。从构建基础变量体系着手,逐步推进视觉属性的语义抽象与组件结构的系统重构,并与前端团队协作建立跨平台适配的 Token 管理机制,为后续的主题系统扩展、暗黑模式支持及品牌风格切换打下基础。

Design Token 概览

我主导了从零构建 Design Token 体系,覆盖颜色、排版、尺寸、边框、阴影与动效等多个维度,逐步建立了超过 300 枚语义化 Token,并通过 Figma 与代码双轨驱动,实现高效协同与持续演进的交付机制。

从触发到内容分发,全面提升创作效率与参与意愿。

三层级变量结构

在 Design Token 的体系设计中,我结合过往实践经验与行业成熟范式,构建了一套更契合内容生态的三层级结构:01-基础变量(Base Tokens)、02-场景变量(Contextual Tokens)、03-语义变量(Semantic Tokens)。这一结构并非简单的分组命名,而是自底向上的派生体系,支持变量的递进式抽象与灵活复用。

虽然该划分方式在行业中已有较多共识,并非“差异化创新”,但我更关注其在具体项目中的落地价值与设计师易用性优化。
以下将通过具体实例,进一步说明这一三层变量结构的机制原理与优势。

从触发到内容分发,全面提升创作效率与参与意愿。

语意化的 Design Token 建设

从设计工程化的视角来看,Design Token 的语义化命名与规范构建,本质上是一种 CSS 变量设计实践。

CSS 是一门富有表现力的语言,同一变量概念往往有多种方式表达。在为内容生态构建 Design Token 时,最终选择了 字符分隔式 (Kebab-case) 而非更常见的 驼峰式 (CamelCase)。这主要出于以下几方面考虑:
  1. 提升语义清晰度与可读性:采用字符分隔,可以构建如 [Category]-[Property]-[Variant]-[State] 的层级结构,使 Token 命名本身就成为一种自解释的文档。

  2. 遵循 Web 原生技术规范:该命名方式与原生 CSS 自定义属性 (--kebab-case) 的格式完全一致。这确保了设计系统在 Web 端的实现最为直接、优雅。

/* 尝试对比下字符命名法与驼峰命名法的易读/易理解性 */

/* Token语义:系统默认的一级文本色 */
color-text-primary-default
colorTextPrimaryDefault

从触发到内容分发,全面提升创作效率与参与意愿。

  1. 无缝对接自动化工具链:主流的 Design Token 自动化工具(如 Style Dictionary, Tokens Studio 等)在解析和生成多平台代码时,默认将 Token 的层级结构映射为字符分隔式。

  2. 保障跨平台扩展的一致性:字符分隔式作为一种在 Web, iOS (Swift), Android (XML) 等主流平台中都能被原生、无歧义解析的“最大公约数”。

/* 尝试对比下字符命名法与驼峰命名法的易读/易理解性 */

--color-text-primary-default: #000000;
--color-text-primary-default: #000000;
--error-color-error: #f54242;
--error-color-error-active: #cf2d33;
--error-color-error-bg: #fff2f0;
--error-color-error-bg-hover: #ffebe8;
--error-color-error-border: #ffc6bf;
--error-color-error-border-hover: #ff9d96;
--error-color-error-disable: #ffd8d3;
--error-color-error-hover: #ff736e;
--error-color-error-text: #f54242;
--error-color-error-text-active: #cf2d33;
--error-color-error-text-hover: #ff736e;

从触发到内容分发,全面提升创作效率与参与意愿。

在进行变量的语义化设计时,我将它们解构为两种核心类型:数值尺度 (Value Scale) 变量 与 用途语境 (Contextual Use) 变量。这两者共同构建了一个稳定灵活的 Token 体系。

数值尺度化变量:系统的“度量衡”

这类变量通过量化分级来命名。其核心目的是为基础视觉属性(如字号、间距、层高、动画时长)建立一套有限且有序的选择集。这从源头上约束了设计的随意性,确保了整个产品视觉输出的统一与和谐。

/* 以Space&Size变量为例,看看如何定义数值尺度变量 */

[data-theme="Light Mode"] {
  /* Space&Size */
  --margin-xxs: 0.25rem;
  --margin-xs: 0.5rem;
  --margin-sm: 0.75rem;
  --margin: 1rem;
  --margin-lg: 1.5rem;
  --margin-xl: 2rem;
  --margin-xxl: 3rem;
  --padding-xxs: 0.25rem;
  --padding-xs: 0.5rem;
  --padding-sm: 0.75rem;
  --padding: 1rem;
  --padding-md: 1.25rem;
  --padding-lg: 1.5rem;
  --padding-xl: 2rem;
  --padding-xxl: 3rem;
}

[data-theme="Light Mode"] {
  /* Radius */
  --border-radius1: 0.125rem;
  --border-radius2: 0.25rem;
  --border-radius3: 0.375rem;
  --border-radius4: 0.5rem;
  --border-radius5: 0.75rem;
  --border-radius6: 1rem;
  --border-radius7: 62.5rem;
}

从触发到内容分发,全面提升创作效率与参与意愿。

用途语境化变量:系统的“设计语言”

这类变量通过描述其应用场景和功能来命名,名称可直接体现设计意图。它的价值在于将设计决策与具体的“数值”解耦。

这种变量的抽象层级可高可低:高层级的(如语义变量)应用范围广,而低层级的(如组件变量)则非常具体。通过组合使用,可以极大地提升系统的灵活性和复用性。
/* 以Background&Theme Color变量为例,看看如何定义语境变量 */

[data-theme="Light Mode"] {
  /* Background*/
  --color-bg-container: #ffffff;
  --color-bg-elevated: #ffffff;
  --color-bg-layout: #f7f8f9;
  --color-bg-layout-adm: #f7f9fd;
  --color-bg-mask: #00000073;
  --color-spotlight: #282c33a6;
  --color-tooltips: #000000bf;
}

[data-theme="Light Mode"] {
  /* Theme Color*/
  --color-primary: #3855d5;
  --color-primary-active: #253ab0;
  --color-primary-bg: #f0f5ff;
  --color-primary-bg-hover: #e6eeff;
  --color-primary-border: #bbcdfc;
  --color-primary-border-hover: #8ba4f0;
  --color-primary-disable: #b0c4ff;
  --color-primary-hover: #5f7ce3;
  --color-primary-text: #3855d5;
  --color-primary-text-hover: #5f7ce3;
  --color-primary-text-active: #253ab0;
}

从触发到内容分发,全面提升创作效率与参与意愿。

WCAG 2.1 AA 色彩对比度标准

我将无障碍标准(WCAG)纳入 Design Token 体系的构建讨论,主要原因在于其核心要求与颜色值的明度对比紧密相关。不含涉及界面缩放 200% 等与布局尺寸有关的标准 —— 这一部分在当前阶段确实覆盖较浅。

根据 2022 年的埋点数据,百度内容生态的大量用户依旧使用中低端 Windows 显示器和设备,这对文字与背景的可读性提出了更高要求。

考虑到实际视觉设计的灵活性与用户设备的多样性,我们未采用 WCAG 的 AAA 级对比度标准,而是以 AA 级作为系统设计的目标标准。这一选择也符合 W3C 的建议——不应将 AAA 级作为整站强制性标准,因为部分内容在视觉设计与交互上难以全面满足其全部要求。

通过 Figma 插件对所有颜色变量进行系统审查,我们确保其在一级与二级核心页面中的实际对比度均满足 WCAG AA 标准,兼顾了设计表达与可达性要求。

从触发到内容分发,全面提升创作效率与参与意愿。

Section 02

Figma 的组件化建设

Figma 组件化是设计系统的核心产出,其基础搭建方法与实践已非常成熟。因此,这里将不再赘述基础组件的搭建过程,我想深入探讨的是超越“标准答案”的部分。

我将重点阐述,在百度内容生态的特定业务需求驱动下,我所主导的几项关键的、区别于以往实践的 Figma 组件化升级。

从触发到内容分发,全面提升创作效率与参与意愿。

建立 Figma Properties 与代码 Props 的映射

组件工程化的核心,是在设计师与开发者之间建立一套统一的语言,而组件的 属性(Properties / Props) 正是这门语言的核心。

Figma 的组件属性(如 Variants, Boolean)本质上是 视觉/交互配置的集合,而 React 等框架中的 Props 则是 逻辑与功能的接口。这种差异是导致设计与研发无法真正实现对齐的主要原因。

为解决此问题,我制定了一套严格的组件属性命名与结构规范,确保设计与开发两端对组件的配置方式尽可能达成共识。Figma 和代码库之间建立了组件属性的 单一事实来源 (Single Source of Truth),同时设计师的交付物可以直接被开发者精确理解和转译。

从触发到内容分发,全面提升创作效率与参与意愿。

布局的结构化:将前端 Flexbox 思维引入设计过程

组件化建设的另一核心,是将布局从感性的“摆放”转变为理性的“结构化”。Figma 的 Auto Layout 正是实现这一转变的关键工具,它本质上是 CSS Flexbox 布局模型在设计侧的实现。

内容生态组件化将 Auto Layout 的应用提升到了原则高度:所有组件必须基于 Auto Layout 和内容约束进行构建。通过模拟 HTML 中 DOM 树的嵌套结构,将间距、对齐、分布等布局规则 编码(Encode) 到设计稿中。
以如下基础组件为例,其内部图标与文本的间距不再是一个固定的像素值,而是由父容器的 gap 属性定义;按钮的内边距(padding)同样由容器的属性控制。这种方式构建的组件结构,其布局信息是自包含且可被精确解析的,从而极大降低了前端工程师将其转译为代码时的信息损耗和沟通成本。

从触发到内容分发,全面提升创作效率与参与意愿。

组件的组合性:以“插槽”范式平衡规范与灵活

设计系统的一个根本性挑战,是在“一致性规范”与“业务多样性”之间取得平衡。使用组合而非继承的“插槽(Slot)”机制,是应对这一挑战的最佳范式。

Figma中插槽的核心思想源于 Web Components 的 <slot> 元素:即组件不再是一个封闭的整体,而是提供一个带有预设“插槽”的开放式容器。在内容生态组件建设中,允许设计师在不破坏组件原子性的前提下,将任意符合业务需求的子内容“注入”到预留的插槽区域中。

Material Design 3 的设计指南也明确提倡此模式,旨在从根本上消除设计师“分离实例 (Detach Instance)”的动机。因为一旦分离,组件便脱离了设计系统的生命周期管理,成为无法维护的“孤岛”。阅读详情

从触发到内容分发,全面提升创作效率与参与意愿。

建立指导决策的设计模式 (Design Pattern)

如果说组件 (Component) 是我们用来搭建产品的“乐高积木”,那么设计模式 (Pattern) 就是那份指导我们如何搭建出坚固、美观建筑的“设计蓝图”。

积木 (组件) 解决了“有什么可用材料”的问题,强调标准化和可复用。

蓝图 (模式) 则解决了“应该如何用这些材料”的问题,强调最佳实践和通用解决方案。

随着生态组件库的日益完备,仅停留在 UI 原子层面的建设已不足以应对复杂的业务场景。然而,模式的抽象与归纳是一项高成本、高投入的系统工程,它需要对大量线上案例进行复盘,对交互逻辑进行深度思考。

基于百度内容生态的高频业务场景,我们选择性的抽象了一些设计模式,并沉淀了设计文档(没错,设计模式并不适合设计稿类型沉淀,它涉及大量的文本阅读)。它不仅复用了大量的基础组件,更重要的是,它统一了不同业务场景下的数据呈现、页面跳转和信息层级关系。

从触发到内容分发,全面提升创作效率与参与意愿。

Section 03

数字资产的云端化建设

我在百度内容生态的主要贡献之一,是主导构建了数字资产的云端化交付与管理体系。这项工作超越了基础的图标绘制与规范,将其重塑为一个集性能、体验、工程效率于一体的系统性解决方案。我们的 NPM 资产库正是这一体系的最终产出。

查看我们的 NPM 资产集合。

第一阶段:资产的标准化与工程化

首先,我们对存量的视觉资产进行了彻底的治理。通过对线上业务进行全盘遍历,我们完成了对遗留 PNG 图标的归集、去重与全面的 SVG 向量化。

更进一步,为实现图标在不同场景下的动态适配,将尺寸单位从固定的 px 转换为相对单位 em,使其能与父元素的字号动态关联,保证了视觉节奏的一致性。为解决 Figma 导出 px 单位的流程障碍,我开发了一款自动化脚本,批量完成 pxem 的转换。

从触发到内容分发,全面提升创作效率与参与意愿。

第二阶段:建立从 Figma 到 NPM 的自动化管道

自动化的核心是建立了一条从设计源文件到 NPM 包的持续集成与交付 (CI/CD) 管道。这不仅是效率的提升,更是对设计师与开发者体验的一次迭代升级。

我们的自动化工作流如下:

从触发到内容分发,全面提升创作效率与参与意愿。

Section 04

设计系统的文档化建设

设计系统的价值不仅在于其组件库,更在于其承载的知识与规范能否被高效传递和应用。因此,文档化建设是与组件建设同等重要的核心产物。

设计系统文档的失败,往往源于一个错误的假设:我们认为用户会为了查阅规范而主动前往一个独立的“知识库”。然而基于我在快手中台的实践观察,人们只会使用手边最便捷的工具。
基于这一洞察,我摒弃了构建单一文档网站的传统模式。取而代之,我们建立了一套“工作流驱动 (Workflow-Driven)”的文档体系。我们的目标是,让不同角色的用户在他们各自最熟悉的环境中,就能无缝获取所需信息。

设计师在 Figma 复制组件,可以直接点击组件的描述,跳转到详细的设计指南(沉淀于百度企业文档)。

开发者在 IDE 中编码时,可以在 Figma Dev Mode 中通过 Code Connect 直接获取代码,或点击组件的链接,查询其技术 API(由 Dumi 自动生成)。

在这个体系中,Figma 组件扮演了“信息索引 (Information Index)”的角色,它本身不承载所有重度信息,而是作为一个智能的“路由器”,将用户精准地导向他们需要的深度内容。

从触发到内容分发,全面提升创作效率与参与意愿。

Section 05

量化设计系统的价值与健康度

在设计系统建设中,我始终坚持“度量先行”的原则,因为无法被度量的事物便无法被有效管理和优化。为此,借助 Figma Library Analytics,我建立了一套包含质量与效能两大维度的度量体系。

质量维度:衡量系统的健康度与健壮性

变体覆盖率:衡量组件对已知场景的覆盖能力。

组件分离率:核心监控指标,反映了内容生态组件在实际应用中是否满足需求。

低分离率(接近 0%)意味着组件设计合理,契约稳固。

效能维度:量化业务贡献与组件收益

需求吞吐量增幅:对比使用设计系统前后,同级别需求的平均完成工时,来量化协同效率的提升。

你可以延伸阅读我在百度定制的所有详细度量指标。阅读详情

从触发到内容分发,全面提升创作效率与参与意愿。