这是 Scanat 设计系统系列的第一篇。 Part 1 记录最初的 0→1 搭建与后续文件架构调整； Part 2 记录三年维护过程中暴露出的治理问题，同时把Token工程化。
| 角色 | Design System Lead · UI 架构 · DesignOps · 跨职能协作 |
|---|---|
| 项目类型 | 设计系统 0→1 搭建与后续扩展 |
| 平台 | Mobile App · iPad App · Web |
| 使用者 | 内部设计、产品与开发团队 |
| 团队 | 设计系统由我独立负责；在交付和落地过程中持续与 PM、开发协作 |
| 时间跨度 | 2023年9月入职前两周完成第一版基础系统；后续随着产品扩展继续调整文件架构 |
| 我的贡献 | 1. 审核并重建设计基础，包括颜色、字体、间距、圆角与阴影； |
我加入 Scanat 时，现有 Figma 文件可以支持日常设计，但缺少统一样式、组件和文件组织。入职前两周，我先搭建第一版基础设计系统：统一颜色、字体、间距等基础规则，建立两层 Color Token，整理 6 类组件，并补齐常用交互与页面状态。
之后随着 Mobile、Web 和白标项目增加，原来的单文件结构再次变重，我又把设计资源拆成基础资产、平台 Design System 和实际 UI 项目三层。
这一篇主要记录设计系统如何从 0 到 1 建立，以及产品扩展后为什么需要重新调整文件结构。
我入职时接手的设计文件已经可以支持日常功能设计，但没有形成统一的设计系统。主要问题集中在四个方面：
这次重建不能暂停正在进行的产品工作，因此我没有先做一套完整规范再统一切换，而是优先整理最影响设计和交付的基础问题，让新系统尽快进入实际使用，再逐步迁移旧页面。
整个 0→1 搭建分为四个阶段。
先盘点已有页面和 UI 元素，找出重复样式、近似组件和缺失状态，再把散落元素组件化，并合并重复或非常接近的颜色、文字与组件样式。
在整理现状后，我先建立颜色、字体、圆角、阴影和间距等基础规则，再让组件统一引用这些规则。整理颜色时，我没有让组件直接绑定具体色值，而是使用两层 Token：Primitive 保存基础颜色，Semantic 表达品牌、文字和状态等界面角色，组件统一引用 Semantic。
这样后续品牌色或主题变化时，可以调整语义层映射，而不需要逐个修改组件。
旧文件中的 UI 元素更多跟着页面存在，同一个控件可能在多个功能里各有一份。我改成按组件职责组织，业务页面只引用组件，不再维护自己的局部版本。所有 UI 元素按功能分成 6 类：
| 模块 | 主要内容 |
|---|---|
| Basic | Button、Icon 等基础元素 |
| Forms | Input、Select 等表单组件 |
| Data Display | Table、Card 等信息展示组件 |
| Navigation | Tab、Breadcrumb 等导航组件 |
| Feedback | Modal、Toast 等反馈组件 |
| Panels | Scanat 3D 测量与编辑相关的自定义工具面板 |
这一步不只是把旧元素“打包成组件”。同时使用 Figma Variants 和 Properties 把尺寸、样式和交互状态补齐。
例如原来只有 1 种样式、2 个尺寸的按钮，后续扩展为 4 种样式、5 个尺寸，并定义 Default、Active、Disabled、Error等状态。开发在交付时可以直接看到完整状态，不需要再根据单张设计稿猜测。
基础样式和组件稳定后，再回到实际 UI 文件，把页面按功能重新分类，并补齐原有设计稿中缺失的状态，包括：
这些状态之前经常在开发过程中临时确认，因此这一轮把它们一起补回到完整 Flow 中。
第一版设计系统解决了基础统一性问题，但随着 Mobile、Web 和白标项目增加，单文件结构再次变重。因此我把不同职责拆成三层：
| 层级 | 内容 |
|---|---|
| Tier 1 · Foundational Assets | 跨平台共用的 Icon、Illustration 等基础资产 |
| Tier 2 · Platform Design Systems | App UI Kit 与 Web UI Kit，仅保留平台组件和样式 |
| Tier 3 · UI Project Files | 正式产品页面和白标客户项目，引用上两层资源 |
把业务页面从组件库中拆出去后，平台组件可以独立维护，白标项目也可以建立自己的 UI Project File，同时继续引用统一资源。
这套系统之后持续使用和维护了三年，后续出现的命名、文档和治理问题放在 Scanat - Design System 治理与 Design-to-Code 工程化