Design System / B端基础设施
B端产品设计系统
搭建实践
从零搭建面向B端产品的设计系统，涵盖设计资产体系、组件库建设、规范文档三大模块。不是UI Kit的堆砌，而是可复用、可传承的设计工程化实践。
01
为什么要建设计系统
在服务多条产品线的过程中，反复遇到三个问题：
- 一致性失控 — 不同产品线相同功能用不同交互模式，开发用不同组件库，品牌感知割裂
- 重复造轮子 — 同类型需求每次从零出图，设计师大量时间花在"画已有组件"而非思考方案
- 设计资产散落 — Figma文件、规范文档、开发组件三者脱离，改了设计忘了同步文档，文档写了没人更新
目标不是建一个"大而全"的设计系统，而是建一个能真正用起来的基础设施：设计师能用它提效，开发能直接对应代码，规范能持续迭代。
02
设计资产体系
从最底层的设计变量（Design Tokens）开始，建立三层资产结构，确保修改一次、全局生效。
Figma Variables 变量层级
Primitives（基础层）原始值
Colors
Spacing（4px 基础单位）
Font Size
Border Radius
Semantic（语义层）语义映射
Component（组件层）直接引用
9 色阶定义法
采用业界标准「标准色 + 黑白透明法」生成色板，Ant Design和Arco Design均采用此思路：
| 色阶 | 生成方式 | 用途 |
|---|---|---|
| 标准 + 80% #FFF | 叠加 80% 白色 | 浅色背景悬停 |
| 标准 + 60% #FFF | 叠加 60% 白色 | 禁用态、失效态 |
| 标准 + 40% #FFF | 叠加 40% 白色 | 浅色强调背景 |
| 标准 + 20% #FFF | 叠加 20% 白色 | 悬停态（Hover） |
| 标准色 | — | 常规态（Normal） |
| 标准 + 20% #000 | 叠加 20% 黑色 | 点击态（Active） |
| 标准 + 40% #000 | 叠加 40% 黑色 | 深色强调 |
| 标准 + 60% #000 | 叠加 60% 黑色 | 深色背景 |
| 标准 + 80% #000 | 叠加 80% 黑色 | 极深背景/文字 |
进阶建议：对于品牌色彩系统建设，推荐使用 HSL 或 Lab 色彩空间生成色板（而非简单叠加黑白），以获得更均匀的视觉梯度。
功能色体系
字体家族体系
B端产品需覆盖多平台，确保在任何系统下都有良好的中文显示：
| 平台 | 中文 | 英文 / 数字 |
|---|---|---|
| macOS | PingFang SC | San Francisco |
| Windows | Microsoft YaHei | Arial |
| Android | 思源黑体 | Roboto |
| 数字专用 | — | DIN（等宽数字，适合表格） |
Font Stack 最佳实践：
font-family: -apple-system, "PingFang SC", "Microsoft YaHei", "Helvetica Neue", Arial, sans-serif;
字重不超过 3 种（Regular 400 / Medium 500 / Semibold 600），B端Web产品基准字号为 14px。
03
组件库建设
不做"所有组件一把梭"，按高频 → 中频 → 低频分批次建设。先建立清晰的基础组件分类体系。
基础组件分类
全局组件 全产品通用的基础元素
导航组件 页面间/页面内跳转与层级
数据录入 表单与信息采集
数据展示 结构化数据可视化呈现
信息反馈 操作结果与系统状态传递
核心组件设计过程
Button 按钮
Table 表格
Input 输入框
Modal 弹窗
04
业务组件沉淀
业务组件与基础组件的区别在于：它与特定业务逻辑强绑定，是多个基础组件的复合体。以下是通过7步法完成的业务组件沉淀过程：
业务组件设计七步法
1. 选取重点功能
梳理业务流程，识别核心任务节点，筛选出覆盖 80% 用户操作的 20% 关键功能。
2. 梳理重点页面
根据用户行为数据（访问量、操作频率），优先选择高频页面类型：数据仪表盘、列表管理页、表单页、详情页。
3. 拆解典型页面
基于原子设计理论（原子→分子→有机体→模板→页面），将页面层级拆解至最小可复用单元。
4. 拆分组件
将拆解后的元素按功能内聚原则归类：全局组件（全产品通用）→ 业务组件（特定模块使用）→ 复合组件（含复杂逻辑）。
5. 组件规范化定义
为每个组件定义五维规范：命名（PascalCase）、视觉（Token驱动，尺寸为8px倍数）、交互（六态模型）、响应式（断点适配）、无障碍（WCAG 2.1 AA）。
6. 页面重组
基于24栅格系统，将规范化组件按业务逻辑「模块化装配」——筛选区+表格+分页器 → 列表页模板。
7. 流程重构与持续迭代
用户测试验证 → 问题优先级排序（P0阻断/P1效率/P2细节）→ 灰度发布 → 数据验证 → 持续优化。
业务组件 vs 基础组件
| 类型 | 定义 | 典型示例 | 设计要点 |
|---|---|---|---|
| 基础组件 | 全产品通用、样式与交互统一 | 按钮、输入框、表格、弹窗 | 视觉风格一致、支持主题切换 |
| 业务组件 | 特定业务场景的复合组件 | 订单状态标签、流程进度条、权限树 | 与业务逻辑强绑定、预留扩展字段 |
05
规范文档体系
规范文档是设计系统的「说明书」。基于TDesign、Arco Design、Element三套系统的分析，总结出标准化的十大模块框架——每个模块解决一个层面的标准化问题。
定位、适用范围、核心目标
指导所有决策的底层准则
品牌色、功能色、中性色 + 色阶
字体族、字号层级、行高、字重
8px网格、24栅格、响应式断点
圆角层级、三层投影体系
按钮、输入框、选择器等使用规范
表格、表单、弹窗等场景组件
图表配色、数据展示规范
对比度、键盘操作、多语言
文档与组件的关系：每个组件条目同时包含设计规范（Design Spec）和使用指南（Usage Guide），设计师看前者、开发看后者，同一份文档双向覆盖。文档通过 Git 管理版本，每次组件变更同步更新。
06
落地与迭代
从设计到开发的协作流程：
Figma 变量库
设计侧管理Token
DESIGN.md
规范文档同步
开发组件库
代码侧实现
走查 & 迭代
还原度检查闭环
经验教训
- 先有规范再有组件 — Token 层级不先定好，后面组件反复推倒
- 规范文档不是一次性的 — 用 Git 管理版本，每次组件变更同步更新，否则半年后文档就是废纸
- 优先覆盖高频组件 — 20% 组件解决 80% 场景，剩下的边做边补
- Figma 组件名 = 前端组件名 — 一对一对应，减少沟通翻译成本
- 版本采用语义化命名（SemVer） — 主版本.次版本.修订号，重大更新先灰度发布