# SaaS设计系统怎么搭建？从基础样式到业务组件

原网页：https://www.jvds.cn/share/ui-design/saas-design-system-guide
语言：zh-CN
发布：2026-09-26
作者：界达设计公司

去很多 SaaS 公司做设计咨询时，对方设计主管都会自豪地打开 Figma 给我们看：“你看，我们已经搭好自己的 Design System（设计系统）了！”点进去一看，第一页是品牌色阶（Blue-100 到 Blue-900），第二页是字号表，第三页是几种大小的按钮、单选框和输入框——然后就没有然后了。

等到去他们真实的线上产品里转一圈，问题全暴露出来了：A 业务线的表格筛选栏放在表头上方，B 业务线的筛选栏藏在右侧抽屉里；财务模块的批量删除是弹窗确认，订单模块的批量删除是行内气泡确认；每个业务设计师都在用那套一模一样的蓝色按钮，拼凑出交互逻辑完全割裂的业务页面。

这就是为什么我们常说：**只停留在“颜色、字体和基础按钮”的设计系统，在复杂 SaaS 产品里只能解决 30% 的问题；真正能统一全局体验、帮前端提效的，是往上再走一步——把高频出现的“业务组件（Business Patterns）”固定下来**。

![界面组件](https://www.jvds.cn/upload/2026/0824/1787562639483-421174.webp)

## 第一层（地基）：用语义化 Design Tokens 替代死色值

不要让设计师和前端在代码里直接引用 `#2563EB` 或者 `Blue-600`。一旦以后产品要做深色模式，或者针对大客户做贴牌换肤（White-label），改起来会要命。 正确的做法是建立**语义化变量（Semantic Tokens）**：

- 背景层定义为 `bg-surface-primary`（主画布底色）、`bg-surface-elevated`（悬浮卡片/弹窗底色）；
- 文字层定义为 `text-primary`、`text-secondary`、`text-muted`；
- 边框与状态定义为 `border-subtle`、`status-warning-bg` 等。设计师只管按语义角色贴标签，前端 CSS 变量一键映射。

![代码交付示意](https://www.jvds.cn/upload/2026/0824/1787562639483-457870.webp)

## 第二层（砖瓦）：基础原子组件必须补齐“极端态与脏数据态”

很多团队画基础组件（Button、Input、Select、Table）时，只画了文字长短刚好的“理想状态”。到了真实研发阶段，前端就会不停地来问设计师：

- 下拉多选框如果用户一口气选了 15 个标签，框体是横向滚动、折行撑高，还是显示 `已选 15 项`？
- 表格某一列的客户公司名称长达 40 个字，是省略号截断加 Hover 气泡，还是允许折成两行？ 把这些边界规则直接在 Figma 组件的 Auto Layout 和变体属性（Variants）里定死，前端写一次组件就能全站复用。

![用采用和结果衡量系统](https://www.jvds.cn/upload/2026/0824/1787562639483-233870.webp)

## 第三层（预制房）：沉淀 6～8 个跨模块通用的“业务级复合组件”

在像 [NEXIVA 企业财务协作平台](https://www.jvds.cn/works/website-design) 这样的中大型 SaaS 产品中，真正决定用户操作顺手程度的，是下面这几个高频业务模板：

1. **标准高级筛选与视图保存条（Filter & Saved Views Bar）**：统一规定搜索框、常用高频筛选项、高级条件组合器以及“保存为我的常用视图”的位置与交互。
2. **表格批量操作悬浮栏（Bulk Action Bar）**：当用户在列表勾选 1 条或多条记录时，统一在底部或表头浮现深色操作条（显示已选数量、批量导出、批量改状态、取消选择）。
3. **主从详情抽屉与分步向导模板（Slide-over & Stepper）**：统一规定多大信息量用弹窗（Modal）、多大信息量用右侧抽屉（Drawer）、多大信息量跳独立详情页。

当这三层结构搭齐之后，新业务模块立项时，设计师和前端就像搭乐高一样，80% 的界面直接调用现成的业务级组件拼装，把宝贵的精力真正花在那 20% 核心业务逻辑的创新上。
