谁需要一个共享系统
一个简单的变更，比如新的品牌颜色或更好的焦点样式，必须在每个产品中逐个屏幕地进行，因为设计和代码不再共享相同的部件。设计系统为每个团队提供同一套经过维护的部件来进行构建。
- 多个小组同时向同一产品交付 UI 的组织
- 将收购或单独构建的产品整合进一个产品家族的公司
- 被要求将共享 UI 变为一个带版本、经过维护的包的前端平台团队
由你的设计师和开发者共享的一致性
当每个团队都构建自己的按钮、表单和模态框时，产品就会出现偏差：屏幕不一致、重复劳动，以及在一处修复了可访问性问题却没有在另一处修复。我们构建连接设计与代码的设计系统：令牌、Figma 库、编码组件和文档，并配有治理机制，让系统保持最新。它适合成长中的 SaaS 产品、拥有多个产品的公司，以及正在迁移到新前端的团队。我们可以单独交付设计部分，也可以交付完整的从设计到代码的系统。
AI 辅助审计，专家掌控标准
AI 如何协助
- 清点你的屏幕和代码库，列出重复的组件以及硬编码的颜色和间距。
- 起草组件文档、使用指南和代码示例，供设计师和工程师审阅。
- 在工程审查下，根据已批准的设计搭建编码组件、Storybook stories 和测试。
- 在拉取请求中标记不符合系统的颜色、间距和组件，以便在代码审查中发现偏差。
我们的专家负责什么
- 设计师和工程师掌控令牌架构、命名和主题策略。
- 工程师定义每个组件的 API、行为和状态，并审查每一处 AI 辅助的更改。
- 可访问性按组件逐一验证：键盘行为、焦点、ARIA 角色、对比度和屏幕阅读器输出。
- 由人来掌控治理：什么能进入系统、版本控制、弃用和贡献规则。
系统的每一层包含什么
多产品网页系统的典型层级；你的审计决定每一层放入什么。
令牌与主题
- 颜色、字号比例、间距和圆角半径的基础值
- 组件使用的语义别名，例如 surface、border 和 danger
- 通过替换别名值而制作的浅色、深色和品牌主题
- 用于持续时间和缓动的动效令牌，与交互规范共享
- 在需要时导出为 CSS 变量，以及 iOS 和 Android 格式
组件与状态
- 仅由令牌构建的按钮、输入框、选择器、模态框和表格
- 每个组件一份规范：属性、变体、状态和键盘行为
- 与编码组件的属性相匹配的 Figma 变体命名
- 由更小的组件组装而成的复合部件，例如日期选择器和组合框
模式、指南与治理
- 组合各组件的模式：表单布局、筛选、批量操作、引导上手
- 关于何时使用每种模式、以及何时不使用的指南
- 贡献路径：提案、设计与代码审查，然后是带版本的发布
- 组件状态，从草稿到弃用，并为破坏性变更附带迁移说明
我们如何构建设计系统
- 01
审计
我们通过 AI 辅助分析清点你当前的 UI 和代码，然后商定优先级：先标准化什么，以及淘汰什么。
- 02
基础
颜色、字体、间距和动效的令牌，其命名和主题规则由设计师和工程师共同商定。
- 03
组件
在 Figma 中设计、并在范围内时用代码构建的组件，每个组件落地时都会审查其行为和可访问性。
- 04
编写文档并采用
文档、贡献规则以及与你的团队进行的讲解，然后在产品迁移到系统时提供迁移支持。
您将获得什么
一套面向设计与代码的系统
UI 审计与清点
一份你已有的组件、模式和样式目录，并对重复项、不一致之处和可访问性缺口进行优先排序。
设计令牌
颜色、字体、间距、圆角、层级和动效令牌，带有浅色、深色或品牌主题，并根据需要为 web、iOS 和 Android 导出。
Figma 组件库
带有变体、属性和每种交互状态的组件，基于令牌构建，并以与代码匹配的方式命名。
编码组件
用 React 或你的框架编写的组件，带有类型化的 props、测试和可访问的行为，在范围内时作为版本化的包发布。
文档站点
Storybook 或自定义文档站点，为每个组件提供实时示例、使用指南、宜与不宜，以及可访问性说明。
治理与版本控制
贡献规则、审查步骤、发布说明和弃用流程，让系统以可控的方式变更。
典型的设计系统需求
我们所界定范围的典型场景，而非客户案例研究。
跨多个产品的品牌重塑
一家拥有网页应用、移动应用和管理工具的公司正在更改其品牌颜色。我们首先将颜色移入主题化令牌，这样每个产品都从同一个地方采用新的调色板。
Figma 与代码不同步
设计师维护着一个开发者已不再使用的 Figma 库，而 React 组件则带有它们自己的间距和颜色。我们审计两者，约定每个组件的哪个版本成为标准，并对齐命名，使设计和代码相匹配。
面向每个产品的无障碍修复
一次无障碍审查发现多个产品中使用的日期选择器、模态框和下拉菜单存在焦点和键盘问题。我们在共享组件中一次性修复它们，记录预期的键盘行为，并发布一个每个产品都可以采用的版本。
本次合作不涵盖的内容
- 设计你产品的单个屏幕不属于本次工作的范围；逐屏幕的 UI 属于 Figma 与视觉设计，它可以在该系统之上构建。
- 动效令牌包含在内；而设计使用它们的过渡、手势和编排则属于交互设计。
- 将每个产品的现有屏幕迁移到该系统上属于产品开发，需单独界定范围；该系统随附迁移说明以及我们约定的支持。
- 系统在交接后需要你方指定一位负责人，或与我们约定的维护安排；没有负责人，偏差就会回来。
该系统如何支持构建、QA 和发布
工程师基于共享部件进行构建
开发者用经过测试的组件和令牌组合出屏幕，而不是重新构建它们，设计上的更改也直接对应到代码。
组件层面的 QA
组件自带视觉回归和可访问性检查，因此发布测试可以聚焦于旅程和业务规则。
受控的系统发布
版本化的包、变更日志和迁移说明让每个产品都能有意识地采用系统更新，而不是措手不及。
随你的成长而维护
我们可以在发布后维护该系统：添加组件、审查贡献，并让设计与代码保持同步。
常见问题
常见问题解答
我们现在需要设计系统吗？
当有多人参与产品的设计或构建、当相同的组件以不同方式被反复构建，或者当你运营多个产品或平台时，它通常会带来回报。对于早期产品，我们可能会建议一个更轻量的起点：令牌和核心组件，随着产品成长再加以扩展。
你们能在我们现有的组件上构建吗？
可以。我们会审计你已有的内容，保留有效的部分，标准化其余部分并填补缺口。迁移可以是渐进式的，因此在引入系统时产品工作不会停滞。
你们构建编码库，还是只做 Figma 部分？
都可以。纯设计的合作会为你的开发者提供 Figma 库、令牌和实现指南。如果你也想要编码组件，我们的工程师会在你的技术栈中构建并测试它们。文档站点的托管另行商定。
当 AI 协助构建组件时，我们的代码在哪里处理？
这是在工作开始前就达成一致的。在私有 / 本地 AI 工程中，AI 处理运行在约定边界内的私有托管模型上。在 Claude Code / OpenAI Codex 工程中，商业编码代理在约定的账户、数据处理和保留设置下工作。无论哪种方式，工程师都会审查每一处变更。
