设计系统实战：从组件库到团队规范

设计系统不是一套 UI Kit，而是一种让团队保持一致、高效协作的工作方式。

什么是设计系统

设计系统（Design System）是一套完整的标准和可复用组件，用于管理大规模的设计工作。它包含三个核心部分：

1. 设计原则：指导设计决策的价值观
2. 组件库：可复用的 UI 元素集合
3. 规范文档：使用规则和最佳实践

设计系统 vs 组件库 vs 样式指南

构建设计系统的步骤

第一步：设计令牌（Design Tokens）

设计令牌是设计系统的原子单位，定义了最基础的视觉属性：

颜色体系：

Primary:    #206BE7 (品牌主色)
Secondary:  #6C757D (辅助色)
Success:    #28A745 (成功)
Warning:    #FFC107 (警告)
Danger:     #DC3545 (错误)

字体系统：

标题 H1:  24px / 1.3 / Bold
标题 H2:  20px / 1.3 / Bold
标题 H3:  18px / 1.4 / SemiBold
正文:     16px / 1.6 / Regular
辅助文字:  14px / 1.5 / Regular
注释:     12px / 1.5 / Regular

间距系统（基于 4px 基数）：

xs:   4px    (紧凑间距)
sm:   8px    (元素内间距)
md:   16px   (元素间距)
lg:   24px   (区块间距)
xl:   32px   (大区块间距)
xxl:  48px   (页面级间距)

第二步：基础组件

从最常用的组件开始，逐步扩展：

按钮（Button）：
- 主按钮（Primary）：页面唯一的主要操作
- 次按钮（Secondary）：辅助操作
- 文字按钮（Text）：最轻量的操作
- 危险按钮（Danger）：不可逆操作

每种按钮需要定义：默认态、悬停态、按下态、禁用态、加载态。

表单组件：
- 输入框（Input）：单行文本、多行文本
- 选择器（Select）：下拉选择、多选
- 开关（Switch）：布尔值切换
- 单选/复选：Radio / Checkbox

反馈组件：
- 提示（Toast / Message）
- 对话框（Dialog / Modal）
- 通知（Notification）
- 加载（Loading / Skeleton）

第三步：复合组件

基于基础组件构建更复杂的 UI 模块：

• 表格（Table）：排序、筛选、分页
• 表单（Form）：验证、布局、联动
• 导航（Navigation）：侧边栏、面包屑、标签页
• 卡片（Card）：不同内容类型的卡片模板

第四步：页面模板

常见页面的布局框架：

• 列表页：搜索 + 筛选 + 列表 + 分页
• 详情页：头部信息 + 内容区 + 操作栏
• 表单页：步骤指示 + 表单内容 + 提交区
• 仪表盘：数据概览 + 图表 + 快捷操作

组件设计原则

原则一：单一职责

每个组件只做一件事，做到最好。不要把多个功能塞进一个组件。

原则二：可组合性

组件应该能自由组合，像乐高积木一样搭建复杂界面。

原则三：可配置性

通过属性（Props）控制组件的变体，而非创建多个相似组件：

Button
├── type: primary | secondary | text | danger
├── size: small | medium | large
├── loading: true | false
├── disabled: true | false
└── icon: 可选图标

原则四：无障碍优先

• 所有交互组件支持键盘操作
• 提供 ARIA 标签
• 颜色对比度符合 WCAG 标准
• 不仅靠颜色传达信息

团队协作规范

命名规范

统一的命名让团队沟通更高效：

• 组件命名：使用 PascalCase，如 SearchBar、UserCard
• 状态命名：使用形容词，如 active、disabled、loading
• 尺寸命名：使用 T 恤尺码，如 sm、md、lg

设计交接清单

设计师交付给开发时应包含：

• [ ] 完整的设计稿（含各状态）
• [ ] 标注文档（间距、颜色、字体）
• [ ] 交互说明（动画、转场、手势）
• [ ] 异常状态（空数据、错误、加载）
• [ ] 响应式适配方案

版本管理

设计系统需要版本管理：

• Major（主版本）：破坏性更新，如组件 API 变更
• Minor（次版本）：新增组件或功能
• Patch（补丁）：修复问题、微调样式

推荐的设计系统参考

写在最后

设计系统是一个持续演进的产品，不是一次性的项目。从小处着手，先解决团队最痛的一致性问题，再逐步扩展。记住：一个被团队使用的简单系统，比一个完美但没人用的复杂系统有价值得多。