设计系统：为何多数失败以及如何构建一个成功的系统

每个达到一定规模的团队最终都会说同样的话：“我们需要一个设计系统。”然后，他们中的大多数会花六个月时间构建一个无人使用的系统，一年后又回到最初的混乱状态。

问题从来不在于组件本身。问题在于将设计系统视为一个项目，而非一个产品。项目有终点，产品则不断演进。一个停止演进的设计系统，从发布之日起就开始走向消亡。

设计系统究竟是什么

设计系统并非一个组件库。组件库是可复用UI元素的文件夹。设计系统是管理产品设计和构建方式的一整套标准、文档和工具。

它包括：

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

剥离其中任何一项，你都将得到一个不完整的系统。不完整的系统导致不完全的采用。不完全的采用又会造成你试图解决的同样的不一致性。

大多数设计系统为何失败

失败1：孤立构建。 一个小团队消失三个月，构建了一个漂亮的系统，然后将其呈现给一个从未参与的组织。该系统反映的是构建者的假设，而非用户的实际情况。采用初期可能出于礼貌，随后便悄然废弃。

失败2：过早僵化。 系统发布时，对所有场景都设定了严格的规则。设计师和工程师遇到系统未预料到的情况时，只有两个选择：对抗系统或绕过它。大多数人会选择绕过。系统最终变成了一个无人参考的参考资料。

失败3：缺乏专属负责人。 系统是在一次冲刺中构建的。没有人被指派维护它。令牌与代码库脱节。组件落后于产品。文档过时。六个月后，系统成了产品去年样子的快照。

失败4：组件优先思维。 团队在定义任何一个令牌或编写任何一条指南之前，就构建了47个组件。这些组件在Figma文件中运行良好，但在生产环境中却出现问题，因为底层值从未系统化。

失败5：完美主义瘫痪。 团队试图在发布任何东西之前解决所有边缘情况。系统从未发布。与此同时，产品每天都在没有它的情况下发布。

幸存系统的共同点

在研究了那些真正持久的系统（Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer）之后，出现了三个共同模式：

它们从小处着手，逐步发展。 没有一个系统是带着200个组件发布的。它们最初发布时只有令牌、少数核心组件和清晰的文档。然后，它们根据实际产品需求进行扩展，而非追求理论上的完整性。

它们拥有专属团队。 不是一个人，而是一个团队。大规模的设计系统至少需要一名设计师、一名工程师、一名文档撰写者和一名产品负责人。Shopify有几十人致力于Polaris。你不需要几十人，但你需要多于零的人。

它们将贡献视为一项功能。 最好的系统让产品团队能够轻松地提出新增内容、标记问题和贡献组件。系统从边缘而非仅仅中心发展。一个只依赖一个团队决策而发展的系统，将永远落后于产品。

设计令牌才是真正的基础

令牌是所有其他元素继承的原始值。更改一个令牌，所有引用它的组件都会自动更新。这正是系统之所以成为系统，而非仅仅一个集合的原因。

令牌层级：

| 层级 | 示例 | 目的 | |---| | 全局 | color-blue-500: #3B82F6 | 原始调色板值 | | 语义 | color-primary: {color-blue-500} | 基于含义的别名 | | 组件 | button-bg: {color-primary} | 组件特定绑定 |

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

首先要定义的令牌类型：

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

如果你不定义其他任何东西，也要定义这些。它们涵盖了你的团队日常90%的视觉决策。

构建持久的组件

基于令牌构建的组件天生比基于硬编码值构建的组件更具弹性。但即使是基于令牌的组件，如果构建不当，也可能失败。

组件生存的规则：

组合优于配置。 一个拥有14个属性的按钮并不灵活，它很脆弱。与其构建一个通过属性处理所有变体的巨型组件，不如构建小的可组合部件，将它们组合成模式。一个卡片不是一个组件。它是一个卡片容器、一个卡片头部、一个卡片主体和一个卡片底部，它们组合在一起。

状态并非可选。 每个交互式组件都需要：默认、悬停、激活、焦点、禁用、加载和错误状态。发布一个没有所有七种状态的组件，意味着有人会临时构建这些状态，而且它们将无法匹配。

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

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

一个下拉组件告诉你下拉菜单的外观。它不会告诉你何时使用下拉菜单、单选组还是分段控件。这个决策是一个模式。

早期应文档化的模式：

• 表单布局。 标签位置、错误显示、必填字段指示、多步流程。
• 导航。 何时使用标签页、侧边栏或面包屑。移动导航的折叠行为。
• 空状态。 没有数据时显示什么。插图？CTA？教育内容？
• 加载状态。 骨架屏、加载指示器还是渐进式加载。何时适用。
• 错误处理。 内联验证、吐司通知还是全页错误状态。

这些模式可以防止没有系统的团队常遇到的“我们用五种不同方式构建了同一个表单”的问题。

治理决定采用的成败

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

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

那些跳过治理的团队最终会得到一个分叉的系统。设计团队使用2.3版本。工程团队使用1.8版本。营销网站使用2.0版本并带有本地覆盖。到那时，你将拥有三个设计系统，但一致性为零。

常见问题

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

初始基础（令牌、10-15个核心组件、基本文档）在专属团队的努力下需要2-4个月。但设计系统永远不会“完成”。请规划持续投入设计工程团队15-25%的精力。

小团队需要设计系统吗？

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

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

组件库是可复用UI元素的集合。设计系统包括组件库，以及设计令牌、使用指南、模式、文档和治理。组件库是系统的一个层面。

从痛点而非雄心开始

不要因为听起来专业而构建设计系统。构建它，是因为你的团队正在反复解决同样的问题而浪费时间。从当前导致最大不一致性的三件事开始。将它们系统化。发布它们。然后根据团队接下来需要什么进行扩展，而不是为了在案例研究中看起来令人印象深刻。