Home

1

Work

2

About

3

Component

4

Writing

5

百度内容生态
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

Engineering、PMO

Contributions

Design System、Design Token、Documentation、Component Analytic

内容概览

01/ 设计变量引入内容生态

02/ Figma 的组件化建设

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

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

05/ 设计系统度量体系

06/ 结语与致谢

Section 01

项目背景

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

该项目几乎从零开始，旨在能够覆盖从创作者平台 (百家号)、营销平台 (度星选) 及 AIGC 工具 (度加)，到多种内部运营与管理工具在内的多样化产品形态与界面需求。

在此之前，团队依赖的是一个基于 Ant Design V4.0 代码库。尽管沉淀了一些组件，但这一体系已很难支撑日益增长的业务复杂性与产品场景的差异化，急需一次系统性的重构与升级。

Baidu 内容生态产品业务概览

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

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

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

Section 02

设计变量引入内容生态

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

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

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

Design Token 概览

我从零构建了内容生态的 Design Token 架构，覆盖颜色、排版、尺寸、边框、阴影与动效等多个维度，逐步建立了超过 300 枚语义化 Token，并通过 Figma 与代码的双向绑定机制，实现了 Token 的高效同步与持续演进的交付工作流。

内容生态 Token 体系建设

三层级变量结构

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

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

三层级 Token 结构

语意化的 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

代码实例：Token 命名选型逻辑

  1. 无缝对接自动化工具链：主流的 Design Token 自动化工具在解析和生成多平台代码时，默认将 Token 的层级结构映射为字符分隔式。

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

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

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

代码实例：Token 命名选型逻辑

在进行变量的语义化设计时，我将它们解构为两种核心类型：数值尺度变量 (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-radius-xxs: 0.125rem;
  --border-radius-xs: 0.25rem;
  --border-radius-s: 0.375rem;
  --border-radius: 0.5rem;
  --border-radius-lg: 0.75rem;
  --border-radius-xl: 1rem;
  --border-radius-xxl: 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 2.1 色彩对比规范，聚焦其核心维度：文本与背景之间的亮度对比度，而非放大 200% 等与布局尺寸相关的标准（当前阶段覆盖较浅，暂未纳入）。

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

考虑到视觉设计的灵活性与终端多样性，我们未强行采纳 AAA 级别标准，而是以 AA 等级作为系统色彩设计的目标基线，这也符合 W3C 的建议：不应将 AAA 作为统一的合规门槛。

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

色彩无障碍设计

Section 02

Figma 的组件化建设

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

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

内容生态组件一览

建立 Figma Properties 与代码 Props 的映射

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

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

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

Figma Property 与 代码 Props 映射

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

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

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

基于 Flex 的组件设计

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

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

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

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

基于插槽的 Slot 容器组件

Section 03

数字资产的云端化建设

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

查看我们的 NPM 资产集合

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

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

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

基于 NPM 的数字资产云端化交付

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

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

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

NPM 自动化流程

Section 04

设计系统的文档化建设

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

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

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

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

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

设计系统文档化建设

Section 05

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

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

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

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

通常来说，以 Pinterest 设计系统为例，行业认为4%以下分离率是一个比较健康的组件状态。

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

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

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

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

设计系统度量体系