设计系统：从组件库到产品语言
当一个产品从 1 个页面增长到 100 个页面，从 1 个设计师增长到 10 个设计师，从 1 个产品线增长到 10 个产品线——你会发现，设计一致性的维持变得越来越难。
按钮有 17 种不同的样式，颜色有 53 种色值，同一个功能在不同页面有 3 种交互方式……用户困惑，设计师重复劳动，工程师抱怨设计稿不统一。
这时候，你需要的不是更多的设计规范文档，而是一个设计系统。
什么是设计系统？
设计系统不是一个新东西。早在 1960 年代，NASA 就有了自己的图形标准手册；1970 年代，纽约地铁的图形系统成为经典；2000 年代，苹果的 Human Interface Guidelines 影响了一代设计师。
但"设计系统"这个词真正火起来，是在 2010 年代中期——随着产品复杂度指数级增长，以及设计开发协作的深化。
设计系统的定义
设计系统 = 可复用的组件库 + 清晰的设计原则 + 完整的设计规范 + 有效的治理机制
它不是一个简单的 UI 组件库，也不是一份厚厚的设计指南 PDF。它是一个活的产品，服务于设计和开发，目标是让产品体验保持一致，同时提升协作效率。
设计系统 vs 组件库 vs 设计指南
很多人会混淆这三个概念，它们的关系是这样的：
| 概念 | 包含内容 | 解决的问题 |
|---|---|---|
| 设计指南（Design Guideline） | 设计原则、色彩、字体、间距规范 | "应该怎么设计？" |
| 组件库（Component Library） | 可复用的 UI 组件及代码实现 | "这个东西怎么做？" |
| 设计系统（Design System） | 设计指南 + 组件库 + 模式库 + 治理机制 | "如何让所有人都按一致的方式做？" |
打个比方：
- 设计指南是菜谱，告诉你应该用什么食材、什么火候
- 组件库是半成品食材，你拿过来稍微加工就能用
- 设计系统是中央厨房 + 食材供应链 + 厨师培训体系，保证每家店做出来的菜味道都一样
原子设计理论
聊设计系统，绕不开 Brad Frost 在 2013 年提出的原子设计（Atomic Design） 方法论。
它借鉴了化学中的概念，把界面分解成五个层级：
页面（Pages）
↑
模板（Templates）
↑
组织（Organisms）
↑
分子（Molecules）
↑
原子（Atoms）
原子（Atoms）
原子是界面的最小构成单元，不能再拆了。
比如：
- 一个按钮
- 一个输入框
- 一个图标
- 一个标签
- 一段文字
它们本身没有独立的功能意义，就像化学中的氢原子、氧原子，单独存在时很简单，但组合在一起就能形成复杂的东西。
分子（Molecules）
分子是由几个原子组合而成的简单 UI 单元。
比如：
- 搜索框 = 输入框 + 搜索按钮 + 搜索图标
- 表单项 = 标签 + 输入框 + 错误提示
- 列表项 = 头像 + 标题 + 描述文字
分子的特点是有明确的功能，可以独立使用。
组织（Organisms）
组织是由分子和原子组合而成的相对复杂的 UI 区域。
比如：
- 导航栏 = Logo + 导航菜单 + 搜索框 + 用户头像
- 卡片列表 = 多个卡片分子的组合
- 表单组 = 多个表单项 + 提交按钮
组织是界面中可识别的独立区块，用户一眼就能看出"这是导航"、"这是卡片列表"。
模板（Templates）
模板是由多个组织组合而成的页面骨架，关注的是布局结构而非具体内容。
比如：
- 文章详情页模板 = 头部导航 + 文章内容区 + 侧边栏 + 底部
- 列表页模板 = 头部导航 + 筛选区 + 列表区 + 分页 + 底部
模板用占位内容代替真实内容，强调的是页面的底层结构。
页面（Pages）
页面是模板的具体实例，把占位内容换成真实内容，就是用户最终看到的页面。
同一个模板可以生成无数个页面，比如文章详情模板可以生成每一篇具体的文章页。
为什么原子设计很重要？
原子设计的价值在于：
- 从抽象到具体：让设计师从最基础的元素开始思考，而不是一上来就画页面
- 可组合性：像搭积木一样，用有限的元素组合出无限的页面
- 一致性：同一个原子在任何地方都是一样的，保证了体验统一
- 效率提升：不用重复造轮子，直接复用已有的组件
当然，原子设计不是教条。在实际工作中，你不需要严格按照五个层级来划分，理解它的核心思想就够了：自下而上地构建界面，用组合代替重复。
设计系统的完整构成
一个完整的设计系统，通常包含以下几个部分：
1. 设计原则（Design Principles）
设计原则是设计系统的"宪法"，是所有设计决策的最高准则。
好的设计原则不是空话，而是能够指导具体决策的。
比如 Material Design 的设计原则：
- Material is the metaphor（材料即隐喻）
- Bold, graphic, intentional（大胆、图形化、有意图）
- Motion provides meaning（动效传递意义）
再比如苹果的 HIG 原则：
- 清晰（Clarity）
- 遵从（Deference）
- 深度（Depth）
设计原则的作用是：当设计师遇到模糊的选择时，可以回到原则上来判断。
2. 设计基础（Foundations）
这是设计系统的"底层变量"，定义了最基础的视觉元素。
包括：
- 色彩系统：主色、辅助色、中性色、功能色、渐变色
- 字体系统：字体家族、字重、字号、行高、字间距
- 间距系统：基础间距单位、间距刻度
- 圆角系统：不同大小的圆角值
- 阴影系统：不同层级的阴影
- 图标系统：图标风格、尺寸、线条粗细
- 栅格系统：栅格列数、间距、断点
这些是构成界面的"原子的原子"——所有组件都是基于这些基础变量构建的。
3. 组件库（Components）
组件库是设计系统中最核心、最常用的部分。
按照原子设计的思想，组件可以分为：
- 基础组件：按钮、输入框、复选框、单选框、开关、标签...
- 复合组件：下拉选择、日期选择、搜索框、分页、表格...
- 业务组件：根据产品特点定制的组件，比如电商的商品卡片、社交的用户卡片...
每个组件都应该包含：
- 组件的用途说明（什么时候用、什么时候不用）
- 组件的各种状态（默认、悬浮、点击、禁用、加载、错误...）
- 组件的各种变体（不同大小、不同风格、不同配置...）
- 组件的交互规范
- 组件的代码实现（开发组件库）
4. 模式库（Pattern Library）
模式库比组件库更高一层，关注的是"如何用组件解决常见的设计问题"。
比如：
- 表单设计模式：单列表单、两列表单、分步表单、内联编辑...
- 导航设计模式：顶部导航、侧边导航、标签页、面包屑...
- 反馈模式：成功提示、错误提示、警告提示、确认弹窗...
- 空状态模式：首次使用、加载中、出错了、无数据...
- 列表模式：普通列表、卡片列表、瀑布流、表格...
模式库回答的不是"这个组件长什么样"，而是"这个场景应该怎么设计"。
5. 设计文档（Documentation）
设计文档是设计系统的"说明书"，告诉大家怎么用。
好的文档应该包含：
- 快速上手指南
- 每个组件的详细说明
- 设计模式的使用场景
- 常见问题解答
- 更新日志
文档不是写完就完了，它需要随着设计系统的演进而持续更新。
6. 治理机制（Governance）
这是很多设计系统被忽略的部分，但恰恰是决定设计系统能否长期活下去的关键。
治理机制回答这些问题：
- 谁来维护设计系统？
- 新组件怎么加进去？
- 现有组件怎么修改？
- 发现 bug 谁来修？
- 版本怎么管理？
- 怎么推动大家使用？
没有治理机制的设计系统，就像没有政府的城市——刚开始可能井井有条，但很快就会陷入混乱。
设计 Token：设计系统的"API"
如果说组件是设计系统的"函数"，那 Design Token 就是设计系统的"变量"。
什么是 Design Token？
Design Token 是设计系统中最小的设计决策单元，用一种与平台无关的方式存储设计值。
说人话就是：把设计中的颜色、字体、间距等值，用有意义的名字定义成变量。
比如不用写 #1677ff，而是写 color-primary。
Token 的三层结构
一个成熟的 Token 系统通常分为三层：
第一层：全局 Token（Global Tokens）
最基础的设计变量，不绑定任何语义。
color-blue-500: #1677ff
spacing-8: 8px
font-size-14: 14px
radius-6: 6px
第二层：语义 Token（Semantic Tokens）
赋予 Token 明确的语义，描述"这个颜色是用来做什么的"。
color-primary: $color-blue-500
color-success: $color-green-500
color-warning: $color-yellow-500
spacing-component: $spacing-8
font-size-body: $font-size-14
第三层：组件 Token（Component Tokens）
针对具体组件的 Token，描述"这个组件的某个属性是什么"。
button-primary-bg: $color-primary
button-height-default: 32px
button-border-radius: $radius-6
为什么需要 Token？
- 一致性：所有地方用同一个变量，改一处全生效
- 灵活性：换主题只需要换 Token 的值，不需要改组件代码
- 跨平台：设计 Token 可以转换成 CSS 变量、JS 变量、iOS 常量、Android 资源
- 设计开发同步：设计师改 Figma 里的 Token，开发那边的代码变量也能同步更新
Token 是设计和开发之间的"通用语言"——设计师在 Figma 里用 Token，工程师在代码里用 Token，大家说的是同一套东西。
从 0 到 1 搭建设计系统
设计系统不是一蹴而就的，它是一个持续演进的过程。下面是一个比较务实的搭建路径：
第一阶段：审计与盘点（1-2 周）
在开始做之前，先搞清楚现状。
- 界面审计：把产品里所有的界面截图下来，贴在一起
- 组件盘点：统计有多少种按钮、多少种输入框、多少种卡片
- 问题收集：设计师和工程师分别吐槽现在的痛点
- 竞品分析：看看同类产品的设计系统是怎么做的
这个阶段的目标是：用数据证明设计系统的必要性。当你把 17 种不同的按钮摆在一起时，没有人会说"我们不需要设计系统"。
第二阶段：设计基础（2-3 周）
从最底层的变量开始搭。
- 色彩系统：确定主色、辅助色、中性色、功能色
- 字体系统：选择字体、定义字号层级
- 间距系统：确定基础单位和间距刻度
- 栅格系统：确定栅格列数和断点
- 圆角、阴影、图标：定义其他基础变量
这个阶段不要着急做组件。基础打牢了，后面做组件才会快。
第三阶段：核心组件（4-6 周）
从最常用的组件开始做。
优先级建议：
- 基础组件：按钮、输入框、复选框、单选框、开关、标签
- 反馈组件：提示、弹窗、通知、加载
- 导航组件：面包屑、标签页、分页
- 数据展示：表格、卡片、列表
- 表单组件：日期选择、下拉选择、文件上传
每个组件都要经历：设计 → 评审 → 开发 → 测试 → 文档 → 发布 的完整流程。
第四阶段：模式库与文档（持续）
组件做得差不多了，开始总结设计模式。
- 梳理常见的业务场景
- 总结每种场景的最佳实践
- 写成文档，配上示例
- 沉淀成可以复用的模板
第五阶段：治理与运营（持续）
设计系统上线只是开始，不是结束。
- 建立反馈渠道，收集大家的问题和建议
- 定期更新版本，修复 bug、增加新组件
- 做内部培训，让大家知道怎么用
- 制定贡献指南，让更多人参与进来
设计系统不是一个项目，而是一个产品。它需要持续投入、持续迭代。
经典案例深度解析
案例一：Material Design（谷歌）
Material Design 是目前最有影响力的设计系统，没有之一。
2014 年谷歌在 I/O 大会上发布 Material Design，目标是统一谷歌旗下所有产品的体验——从安卓手机到网页，从平板到智能手表。
Material Design 的核心创新在于：
- 材料隐喻：把界面想象成一张有厚度的纸，可以折叠、可以投射阴影
- 波纹反馈：点击时的水波纹动效，提供了清晰的触觉反馈
- 规范的完整性：大到页面布局，小到图标笔触粗细，全都有明确规范
从 Material Design 1.0 到 Material Design 3，谷歌一直在演进这套系统。Material You 引入了动态配色，让系统颜色可以根据壁纸自动变化——这是设计系统从"静态规范"走向"动态生成"的重要一步。
案例二：Ant Design（蚂蚁集团）
Ant Design 是国内最成功的开源设计系统。
2015 年，蚂蚁金服的设计团队发现，他们做的每个中后台产品，都在重复做差不多的东西。于是他们把常用的组件和设计规范整理出来，就成了 Ant Design 的雏形。
Ant Design 的成功因素：
- 精准的定位：专注企业级中后台产品，不跟 Material Design 抢 C 端市场
- 设计+开发一体：不仅有设计规范，还有高质量的 React 组件库
- 开源社区：GitHub 上 9 万+ Star，社区贡献了大量的生态
- 中文文档：对国内开发者非常友好
Ant Design 的价值不止于一套组件库，它甚至定义了国内中后台产品的设计语言——你现在看到的大部分 SaaS 产品，都或多或少有 Ant Design 的影子。
案例三：Human Interface Guidelines（苹果）
苹果的 HIG 是设计系统的"祖师爷"级别的存在。
从最早的 Mac OS 到 iOS，再到 watchOS、visionOS，苹果的 HIG 一直在演进，但核心的设计哲学始终没变。
HIG 最值得学习的地方：
- 平台特性：每个平台都有自己的设计语言，但又有共通的原则
- 以用户为中心：所有规范的出发点都是用户体验，而不是设计的自我表达
- 完整性：不仅讲 UI，还讲交互、动效、无障碍、国际化
- 示例丰富：每个规范都配有大量的正反案例对比
苹果的设计系统告诉我们：最好的设计系统，不是让产品都长得一样，而是让每个产品都有一致的"苹果味"。
案例四：Shopify Polaris
Shopify Polaris 是电商领域设计系统的代表。
Polaris 的特点是：
- 业务导向：不是为了做设计系统而做，而是为了提升商家的体验
- 内容优先：不仅关注视觉，还非常重视文案和内容设计
- 包容性：考虑不同国家、不同文化、不同能力的用户
- 数据驱动：每个设计决策都有用户研究数据支撑
Polaris 证明了：设计系统不是大公司的奢侈品，而是产品增长的基础设施。
设计系统的常见误区
误区一：设计系统 = 组件库
很多团队以为，做了一套组件库就是有了设计系统。
不对。组件库只是设计系统的一部分。没有设计原则，组件就没有灵魂；没有模式库，大家还是不知道怎么组合组件；没有治理机制，组件库很快就会过时。
误区二：设计系统是设计团队的事
设计系统不是设计团队单方面的事，它需要设计、开发、产品三方共同参与。
- 设计团队负责设计语言和组件设计
- 开发团队负责组件实现和技术架构
- 产品团队负责业务场景和优先级
设计系统是跨职能的协作产物，不是设计团队的自娱自乐。
误区三：设计系统会限制创造力
很多设计师担心：有了设计系统，我不就成了拼组件的美工了？
恰恰相反。设计系统把你从重复劳动中解放出来，让你有更多时间去思考更有价值的问题——比如用户需求、业务逻辑、产品体验。
就像厨师不需要自己种菜、自己磨面，但这并不影响他成为一名好厨师。他可以把精力放在更重要的事情上：创造美味的菜品。
误区四：设计系统做完就完了
设计系统不是一个有终点的项目，它是一个持续演进的产品。
产品在变，业务在变，用户在变，设计系统当然也要跟着变。一个不更新的设计系统，很快就会被大家抛弃。
误区五：设计系统越大越好
设计系统不是组件越多越好。
每个组件都有维护成本，加进去容易，删掉难。一个好的设计系统，应该是"够用就好"——覆盖 80% 的常见场景，剩下 20% 的特殊场景，交给设计师自由发挥。
工具链推荐
搭建设计系统的过程中，这些工具可以帮上大忙：
设计端
- Figma：目前最主流的设计工具，组件库和变量系统做得很好
- Tokens Studio：Figma 插件，用来管理 Design Token
- Figma Variables：Figma 原生的变量功能
开发端
- Storybook：组件开发和文档的标准工具
- React / Vue / Angular：根据技术栈选择组件库框架
- Style Dictionary：把 Token 转换成各平台可用的格式
- Chromatic：Storybook 的云端服务，做视觉回归测试
协作与文档
- Zeroheight / Notion / Confluence：设计系统文档站
- Linear / Jira：需求和任务管理
- Lingo / Frontify：设计资产库管理
写在最后
设计系统的本质是什么？
我觉得是把设计从"手工艺品"变成"工业化产品"的过程。
在没有设计系统的时候，每个设计师都是手艺人，每个页面都是手工打造的。这样做出来的东西可能很精美，但效率低、一致性差、难以规模化。
有了设计系统之后，设计就有了"标准化零件"和"流水线"——大部分常规需求可以用标准化组件快速搭建，设计师可以把精力集中在真正需要创造力的地方。
这不是设计的降级，而是设计的升级。
就像建筑行业，从每个房子都亲手砌墙，到有了标准化的砖块、钢筋、预制板——建筑设计师并没有因此失业，而是可以去设计更伟大的建筑。
设计系统也是一样。它不是来取代设计师的，而是来解放设计师的。
让设计更有价值，这才是设计系统真正的意义。