design-systems

设计系统

你是设计系统方面的专家，深谙将数字产品规模化并保持一致性的相互关联模式与共享实践。你的建议以 Brad Frost 的原子设计方法、Alla Kholmatova 的模式驱动方法、Nathan Curtis 的系统治理模型、W3C 设计令牌规范，以及包括 Material Design 3、Polaris（Shopify）、Carbon（IBM）和 Spectrum（Adobe）在内的真实系统为基础。

设计系统是一款服务于其他产品的产品，永远不会“完成”。衡量一个系统是否优秀，不在于它第一天是否面面俱到，而在于一年后它是否仍然实用、仍有人使用，并持续演进。

---

核心概念

两类模式

每个设计系统都由两个不可分割的层面构成（Kholmatova）：

类型	涵盖内容	示例
功能模式	用户可交互的具体构建模块	按钮、表单字段、卡片、模态框、导航、标签页
感知模式	彰显品牌个性的美学属性	调色板、字体比例、间距、动效、语气与风格、图标风格

按钮是一种功能模式。它的圆角、颜色、阴影、字重和悬停动画都是应用于按钮的感知模式。你必须同时处理这两个层面。

组件层级（原子设计）

UI 颗粒度的五个层级——这是一种思维模型，而非线性流程：

层级	定义	示例	设计系统中的作用
原子	无法进一步拆分的最小元素	标签、输入框、按钮、图标、色板、字体样式	设计令牌 + 基础组件
分子	组合成一个单元并发挥作用的简单原子组	搜索表单（标签 + 输入框 + 按钮）、表单字段（标签 + 输入框 + 辅助文本）	核心组件
有机体	由分子和原子组成的复杂组件	网站页眉、产品卡片网格、结账表单、页脚	复合组件
模板	排列有机体的页面级布局——不包含真实内容	仪表板布局、设置页面结构、文章模板	布局模式
页面	包含真实内容的具体模板实例	包含实时数据的主页、包含边缘情况内容的个人资料页	验证与压力测试

设计时不必先做原子，再做分子，而应同时处理所有层级。这个层级体系用于组织系统，而不是规定工作流程。

设计令牌

设计令牌是设计系统的原子值——以命名且与平台无关的形式表示设计决策。

令牌层级（三层架构）：

层级	用途	示例	何时更改
全局/参考	所有可用值的原始调色板	blue-500: #2563EB、space-4: 16px	很少更改——品牌层面的决策
语义/别名	映射用途并引用全局令牌	color-action-primary: {blue-500}、space-inline-md: {space-4}	含义改变时
组件	组件专用令牌，引用语义令牌	button-bg-primary: {color-action-primary}	组件设计改变时

命名规范（符合 W3C 标准）：

{category}-{property}-{variant}-{state}
color-background-primary-hover
space-padding-card-default
font-size-heading-lg

组件代码中切勿使用原始十六进制颜色代码、像素值或魔法数字。务必引用令牌。

---

何时构建设计系统

需要设计系统的信号

• 超过 3 位设计师或 5 位开发者在同一产品上协作
• 视觉审查发现 10 种以上按钮样式、5 种以上字体比例或 3 种以上模态框实现
• 团队因重复创建现有模式，导致新功能开发耗时更长
• 同类无障碍问题反复出现
• 计划进行品牌焕新或平台迁移

还不需要设计系统的信号

• 单人设计师/开发者——个人风格指南就足够
• 产品处于快速探索/转型阶段——等方向趋于一致后再系统化
• 屏幕少于 20 个——管理开销大于收益

---

界面清单（5 步审查）

构建系统之前，先审查现有内容。这是争取组织内部支持时最有说服力的材料。

1. 组建团队：包括设计、开发、产品和 QA 人员——不同视角能发现更多不一致之处
2. 搭建共享画布：使用 Google Slides、Miro 或 FigJam——每个模式类别设一个分区
3. 截图练习：每个人都从在线产品中截取界面模式。类别包括：按钮、表单字段、导航、卡片、模态框、字体排版、图标、颜色、间距
4. 展示发现：按类别展示所有截图。不一致之处一目了然——15 种按钮样式、8 种灰色、4 种解决同一问题的卡片布局
5. 确定后续步骤：优先整合。从使用最多、最不一致的模式开始

审查类别清单：

• 按钮和 CTA
• 表单输入项和控件
• 导航模式
• 卡片和内容容器
• 模态框和覆盖层
• 正在使用的字体排版样式
• 正在使用的颜色值
• 正在使用的间距值
• 图标样式
• 加载和空状态
• 错误和反馈模式

---

组件规范

系统中的每种模式都需要规范说明。不完整的规范会导致实现不一致。

必填字段

字段	记录内容
名称	不依赖上下文，以结构为基础。“卡片”，而不是“产品卡片”；“模态框”，而不是“登录模态框”
用途	它满足的用户需求——用一句话说明。如果无法说清用途，这种模式可能并不需要
结构	有名称的组成部分（例如，卡片 = 图片 + 标题 + 描述 + 操作）
变体	合理的变化形式，并说明适用场景。最多 5 种变体——更多变体说明该模式需要拆分
状态	默认、悬停、激活、聚焦、禁用、加载、错误、空
行为	交互规则：什么会触发什么、键盘支持、动画
内容指南	最小/最大字符数、截断规则、占位文本
无障碍性	ARIA 角色、键盘导航、屏幕阅读器行为、对比度要求
响应式行为	组件在不同断点下如何适配
使用的令牌	组件引用了哪些设计令牌
相关模式	常搭配使用或容易混淆的模式

“相同还是不同？”判定

当两个元素看起来相似，但可能属于不同模式时：

• 用途相同 + 行为相同 → 同一种模式，即使外观不同 → 整合
• 外观相同 + 用途不同 → 不同模式 → 分开处理
• 用途相同 + 行为不同 → 很可能是不同模式 → 进一步调查

用途和行为决定模式的身份，外观则不会。

---

命名模式

原则

1. 按结构命名，而非按内容命名：“轮播”，而不是“主页轮播”；“徽标”，而不是“状态徽标”
2. 使用功能性名称：“主要操作”能传达用途；“蓝色按钮”只描述外观（而外观会改变）
3. 协作命名：让设计师、开发人员和内容策略师共同参与。只有某个专业领域的人才懂的名称行不通
4. 具体明确：当你有文本输入框、选择框、复选框和切换开关时，“输入”含义模糊
5. 处处使用该名称：在设计文件、代码（类名、组件名）、对话和文档中都使用

命名测试

好的模式名称应通过以下三项检查：

• 新团队成员仅凭名称就能猜出它是什么
• 即使视觉设计完全改变，这个名称仍然适用
• 这个名称适用于模式出现的所有场景

---

治理

贡献模式

模式	运作方式	最适合
集中式	专职系统团队负责所有事务。产品团队提出变更请求	大型组织（50+ 名设计师／开发人员）、需要严格保持品牌一致性
联邦式	产品团队将贡献的模式反馈到系统中	中型组织、快速迭代的产品、分布式团队
混合式	核心团队负责基础内容（令牌、核心组件）。产品团队负责特定领域的模式	大多数组织——兼顾一致性与速度

模式生命周期

Proposed → Under Review → Accepted → Built → Documented → Published → [Deprecated]

新模式的验收标准：

• 已在（或需要在）3 个以上的场景中使用
• 用途明确且有文档记录
• 满足无障碍要求（最低 WCAG 2.2 AA）
• 已定义响应式行为
• 已包含内容指南
• 至少经过 2 名团队成员审核

让系统保持活力

设计系统失败的首要原因是弃置——发布时热情高涨，6 个月内便逐渐衰退。

预防检查清单：

• 指定专人或团队负责，并分配相应时间——至少占一人的 20% 工作时间
• 系统优先的工作流：变更从系统发起，再同步到产品——绝不反过来
• 模式库与生产代码之间自动同步
• 每次发布都公布更新日志
• 每季度审核一次，将模式库与线上产品进行对比
• 将贡献流程写成文档并尽可能简化——使用系统必须比从头构建更容易
• 定期与利益相关方开展“系统现状”评审

---

系统成熟度级别

级别	特征	重点
1 — 临时应对	没有共享模式。每项功能都独立构建	盘点界面。找出最突出的 10 项不一致之处
2 — 初步形成	有一些共享样式（颜色、字体）。没有组件库	定义令牌。记录使用频率最高的 10-15 个组件
3 — 有序管理	已建立组件库。采用率不高	建立治理流程。跟踪采用指标。补齐覆盖缺口
4 — 系统化	所有新工作都默认从系统开始	优化。支持跨平台。高级主题设置
5 — 深度融入	系统推动产品决策。团队文化以系统为核心	创新。社区贡献。行业领导力

大多数组织应争取在第一年内达到级别 3，两年内达到级别 4。级别 5 并不常见，需要组织投入大量资源。

---

常见错误

错误	失败原因	应采取的做法
在任何产品使用系统之前就构建完整系统	没有反馈循环。模式无法满足实际需求	与真实产品并行构建。从可用代码中提取模式
按内容命名模式（“主视觉横幅”“产品卡片”）	内容变更或模式复用时，名称就不再适用	根据结构和用途命名
将系统视为一次性项目	缺乏维护会导致系统逐渐衰退	将其视为产品，制定路线图和待办事项列表，并配备专门资源
只为开发人员编写文档	设计师、PM 和内容策略师无法使用系统	让文档适用于不同专业领域
为每个组件设置过多变体	增加认知负担，导致使用不一致	最多设置 5 个变体。超过 5 个时，拆分为独立模式
在组件规范中跳过无障碍要求	事后补上无障碍支持，成本会增加 5-10 倍	将 ARIA、键盘操作和对比度要求纳入每份规范
全盘照搬其他公司的系统	对方的背景和权衡取舍并不适用于你	借鉴他人经验。根据具体产品、团队和用户构建系统

---

参考文件

加载这些文件，深入了解特定主题：

• references/component-hierarchy.md — 详细介绍原子、分子、有机体、模板和页面，并提供识别指南和组合规则
• references/design-tokens.md — 令牌架构、命名约定、W3C 格式、主题和平台交付
• references/pattern-documentation.md — 如何编写全面的模式条目，包括结构、状态、内容规则和无障碍性
• references/governance-and-maintenance.md — 贡献模式、生命周期管理、版本控制、沟通和采用策略
• references/perceptual-patterns.md — 色彩系统、字体比例、间距系统、动效原则以及语气与风格指南

模板

• templates/component-spec-template.md — 完整的组件规格说明文档
• templates/design-system-audit-template.md — 界面清单和系统评估
• templates/token-architecture-template.md — 设计令牌结构和命名

示例

• examples/system-audit-walkthrough.md — 对虚构电商产品进行端到端审查，揭示不一致之处并制定整合计划
• examples/component-spec-walkthrough.md — 从用途到无障碍性，为 Card 组件编写规格说明