设计系统：为什么大多数都失败了，以及如何构建一个真正有效的

每个团队发展到一定规模，最终都会说同一句话："我们需要一个设计系统。"然后大多数团队花六个月时间构建一个没人用的系统，一年后又回到了最初的混乱状态。

问题从来不在于组件本身。问题在于把设计系统当作项目而不是产品来对待。项目会结束，产品会持续演进。一个停止演进的设计系统，从发布那天起就开始走向死亡。

设计系统到底是什么

设计系统不是组件库。组件库是一个存放可复用 UI 元素的文件夹。设计系统是一套完整的标准、文档和工具，用于规范产品的设计与构建方式。

它包括：

• 设计令牌。 所有其他元素所引用的原子值（颜色、间距、字体排版、阴影）。
• 组件。 基于令牌构建的可复用 UI 元素。
• 模式。 针对反复出现的设计问题（表单、导航、错误状态）的文档化解决方案。
• 规范。 规定何时以及如何使用每个元素的规则。
• 治理。 谁拥有系统、如何提出变更、如何做出决策。

缺少其中任何一项，你得到的就是一个不完整的系统。不完整的系统导致不完整的采用。不完整的采用又制造出你最初试图解决的那种不一致性。

为什么大多数设计系统会失败

失败原因一：闭门造车。 一个小团队消失三个月，构建出一个精美的系统，然后将其呈现给一个从未参与其中的组织。这个系统反映的是构建者的假设，而非使用者的现实。起初大家礼貌地接受，然后悄然放弃。

失败原因二：过早僵化。 系统发布时对每个场景都有严格的规则。当设计师和工程师遇到系统未曾预料的情况时，他们只有两个选择：与系统抗争，或者绕过它。大多数人选择绕过。系统成了一个没人参考的参考文档。

失败原因三：缺乏专属归属。 系统在某次冲刺中构建完成，却没有人被指定维护它。令牌与代码库逐渐偏离。组件跟不上产品的发展。文档日益陈旧。六个月后，系统成了产品去年样子的一张快照。

失败原因四：以组件为先的思维。 团队在定义任何令牌或编写任何规范之前，先构建了 47 个组件。这些组件在 Figma 文件中运行良好，却在生产环境中崩溃，因为底层的值从未被系统化。

失败原因五：追求完美的瘫痪。 团队试图在发布任何东西之前解决每一个边界情况。系统始终无法发布。与此同时，产品每天都在没有系统的情况下上线。

幸存系统的共同点

在研究了那些真正长期存在的系统（Shopify Polaris、Atlassian Design System、IBM Carbon、GitHub Primer）之后，三个规律浮现出来：

它们从小处起步，逐步成长。 没有一个是带着 200 个组件发布的。它们以令牌、少量核心组件和清晰的文档起步，然后基于实际产品需求而非理论上的完整性来扩展。

它们拥有专属团队。 不是一个人，是一个团队。规模化的设计系统至少需要一名设计师、一名工程师、一名文档撰写者和一名产品负责人。Shopify 有数十人在维护 Polaris。你不需要数十人，但你需要的不止零人。

它们将贡献视为特性。 最好的系统让产品团队能够轻松提出新增内容、标记问题并贡献组件。系统从边缘生长，而不仅仅从中心扩展。一个只从单一团队决策中成长的系统，永远会落后于产品。

设计令牌才是真正的基础

令牌是其他所有内容继承的原始值。更改一个令牌，所有引用它的组件都会自动更新。这正是让系统成为系统而非集合的关键所在。

令牌层级：

全局令牌定义原始值。语义令牌赋予含义（主色、危险色、表面色）。组件令牌将这些含义绑定到具体的 UI 元素。这种三层结构意味着你可以通过更改语义令牌来完成品牌重塑，而无需触碰任何一个组件。

优先定义的令牌类型：

• 颜色（背景色、文字色、边框色、交互状态色）
• 间距（4px 网格：4、8、12、16、24、32、48、64）
• 字体排版（字族、字号比例、字重、行高）
• 圆角（无、小、中、大、全圆）
• 阴影（层级高度）
• 动效（持续时间、缓动曲线）

如果你只能定义一件事，就定义这些。它们覆盖了团队每天做出的 90% 的视觉决策。

构建经得住时间考验的组件

基于令牌构建的组件本质上比使用硬编码值的组件更具弹性。但即便是基于令牌的组件，如果构建方式有误，也会失败。

让组件经久耐用的规则：

组合优于配置。 拥有 14 个 props 的按钮并不灵活，而是脆弱。与其构建一个通过 props 处理所有变体的超级组件，不如构建可以组合成模式的小型可组合单元。一个卡片不是一个组件，而是由卡片容器、卡片头部、卡片主体和卡片尾部组合而成。

状态不可或缺。 每个交互式组件都需要：默认、悬停、激活、聚焦、禁用、加载中和错误状态。发布一个缺少这七种状态的组件，意味着某人会临时构建这些状态，而它们将无法保持一致。

记录"何时"，而不仅仅是"是什么"。 你的按钮文档不应只是展示它长什么样，还应说明何时使用主要按钮、次要按钮或幽灵按钮。决策框架比视觉参考更重要。

模式解决组件无法解决的问题

下拉组件告诉你下拉框长什么样，却不告诉你何时应该使用下拉框而不是单选组或分段控件。那个决策就是模式。

优先记录的模式：

• 表单布局。 标签位置、错误显示、必填字段标注、多步骤流程。
• 导航。 何时使用选项卡、侧边栏或面包屑导航。移动端导航折叠行为。
• 空状态。 没有数据时显示什么。插图？CTA？引导内容？
• 加载状态。 骨架屏、加载动画还是渐进式加载。每种方式适用的场景。
• 错误处理。 内联校验、toast 通知还是全页错误状态。

这些模式能防止"我们用五种不同方式构建了同一个表单"的问题，这是没有系统的团队的常见困境。

治理决定采用的成败

没有治理的设计系统只是一个建议。治理回答三个问题：

1. 谁来决策？ 是否有评审委员会？单一负责人？民主投票？无论你选择什么，都要明确说明。
2. 变更如何发生？ RFC 流程？GitHub issue？Slack 讨论？定义从"我认为我们需要一个新组件"到"它已纳入系统"的完整路径。
3. 版本策略是什么？ 令牌包使用语义版本控制？每次发布都有变更日志？破坏性变更策略？

跳过治理的团队最终会遭遇系统分叉。设计团队使用 2.3 版本，工程团队使用 1.8 版本，营销网站使用带有本地覆盖的 2.0 版本。走到那一步，你拥有的是三个设计系统，以及零一致性。

常见问题

构建一个设计系统需要多长时间？

初始基础（令牌、10-15 个核心组件、基础文档）需要一个专属团队花费 2-4 个月。但设计系统永远不会"完成"。计划持续投入设计工程团队 15-25% 的产能。

小团队需要设计系统吗？

需要，但要与规模相称。一个 3 人团队不需要 Polaris 那样的系统。他们需要一个包含令牌、8-10 个核心组件以及一页决策指南的共享 Figma 库。从最痛的地方开始（通常是不一致的间距和颜色使用），然后逐步扩展。

设计系统和组件库有什么区别？

组件库是可复用 UI 元素的集合。设计系统包含组件库，加上设计令牌、使用规范、模式、文档和治理。组件库只是系统的其中一层。

从痛点出发，而非野心

不要因为听起来专业而构建设计系统。要因为你的团队在反复解决同样的问题而浪费时间，才去构建它。从当下造成最多不一致的三件事入手，将它们系统化，发布出去。然后基于团队接下来的需求来扩展，而非基于案例研究中看起来令人印象深刻的东西。