设计系统,抛开营销话术
两年来,LinkedIn 上的帖子已经把“设计系统”这个词说烂了。所以我们先重新定义一下。
设计系统是关于产品外观和行为的可执行、有版本管理的唯一真相来源。“可执行”是因为设计师使用的组件和工程师交付的组件是同一套。“有版本管理”是因为系统会随时间演进,而旧版本仍需保持可用。“唯一真相来源”是因为——如果还存在歧义,说明这套系统没有发挥作用。
一个装了几个按钮的 Figma 文件不是设计系统。一个有 40 个组件却没有设计令牌(design tokens)的 Storybook 也不是设计系统。真正的系统,是连接两者的桥梁。
拥有设计系统后,会发生什么变化
有三 件事会发生可衡量的变化:
新功能开发速度。 在项目进行中引入真正设计系统的案例里,功能交付速度会在两个冲刺(sprint)内提升 30–50%。设计师不再重复发明表单模式,工程师不再重复实现按钮组件,PR 的体积也随之缩小。
跨界面的一致性。 多产品公司是最明显的受益者,但单一产品团队同样能获益。营销官网、App、管理后台、邮件模板——只要共享同一套设计令牌,看起来就会像出自同一家公司之手。没有共享令牌,风格迟早会跑偏。
上手成本。 新来的设计师或工程师能在入职第一周就交付第一个 PR,而不是拖到第一个月。绝大多数“这个功能该怎么做”的问题,系统早就替他们回答好了。
系统里应该包含什么
一套能真正运作的设计系统大致包含四个层次。少了任何一层,系统都会变得脆弱。
1. 令牌(Tokens)。 颜色、字体排印、间距、圆角、阴影、动效时长、缓动曲线。这些是 JSON 数据,不是图片。它们同时输入 Figma(通过 Tokens Studio 之类的工具)和代码(通过 Style Dictionary 之类的工具)。令牌层是最重要、也是最常被跳过的一层。
2. 基础组件(Primitives)。 按钮、输入框、下拉选择、复选框、单选框、开关、徽标、提示框、弹窗。这些是几乎出现在每个页面上的原子级 UI 元素,应该只实现一次,并配备完善的无障碍支持(焦点环、ARIA、键盘操作),再用属性表(prop tables)记录清楚。
3. 模式(Patterns)。 表单、导航、空状态、加载状态、错误状态、数据表格。这些是基础组件的组合,体现的是明确的设计判断:“我们的多步表单就是这么处理的”,而不是“这是一个表单库,自己拼”。
4. 规范指南(Guidelines)。 语气与调 性、无障碍标准、文案规则(比如“按钮文字使用句首字母大写”)、动效原则。这些是不属于组件本身、却能让整体工作保持连贯一致的部分。
一种常见的失败模式:交付了系统,却又弃用了它
我们在客户代码库里看到的设计系统,有一半是两年前搭建的,用了六个月就被悄悄绕过了。典型症状:没人更新的 Storybook、代码库里出现和设计系统组件功能重叠的“影子组件”、颜色十六进制值在 30 个地方被硬编码。
这种情况通常是因为系统被当成了一次性交付物,而不是一个持续维护的产品。要解决它,得从结构上着手:
- 指定一位负责人,哪怕是兼职的。没有负责人,就没人决定一个新组件何时该“转正”进入系统。
- 让使用系统比绕开系统更省事。如果往系统里添加一个新组件,比直接复制粘贴一个还要费时间,那就已经输了。
- 每季度做一次审查。逐页检查,统计偏离程度,然后修正。我们用一个简单的指标:“仅使用系统组件的页面占比”。低于 80% 就说明有问题。
从小处起步(并且不要停下)
你不需要一个 200 个组件的库才能称之为设计系统。一个能用的 v1 版本,一个 Figma 库加一个 npm 包就够了,大致包含:
- 8 个颜色令牌
- 4 套字号体系
- 一套间距体系(4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 个组件:按钮、输入框、下拉选择、弹窗、卡片、表格
- 3 种模式:表单布局、页面头部、空状态
这就是一套真正的设计系统。周五交付,周一投入使用,接下来的一年里持续壮大它。
什么时候你不需要它
一个两人团队,花六个月做一款产品,不背上正式系统的开销反而能交付得更快。大致的临界点是:三名及以上设计师/工程师、多个界面、或产品预期存活超过 18 个月。 低于这个门槛,把约定俗成的规则写下来就足够了,不必多想。
超过这个门槛后,问题就不再是“我们该不该建设计系统”,而是“不建系统我们已经付出了多少代价”。如果你想为团队现有系统的状态找个第三方评估,我们的UI/UX 设计团队会先从一次轻量审查开始。
