B2B：Syndigo 设计系统 - 统一组件库与从设计到代码的流水线

设计流程

我将这次重建分成清晰的几个阶段，每一步都以审计为依据。

审计：我盘点了各产品中的每一个组件，将 Figma 与生产环境逐一对照，并标记出每一处重复和不一致。

整合：我将每一组重复项收敛为一个规范组件，为每个组件记录其结构、变体和版本历史，并引入了一套清晰的工作流程——构思、进行中、已完成——并把工单挂在设计画板上。

Code Connect 与 Storybook：为全部 70 多个组件，我编写了 Code Connect 和组件代码文件，并搭建 Storybook 让设计稿与实时编码形态并排展示。

GitHub 集成：由于仓库里没有 UX 的代表，工程团队给了我访问权限，我便直接把组件文件和 Code Connect 文件提交到 GitHub，闭合了从设计到代码的回路。

AI 驱动的原型：我是公司里第一个用 Figma MCP 把设计变成已编码、可点击的原型、以便在开发前测试的人，随后将 Lovable 和 Claude Design 锁定到系统组件上，让团队只能生成符合系统的产物。

无障碍：我按照 WCAG AAA 标准构建并验证了每一个组件。

无障碍

系统按照 WCAG AAA 标准构建。组件为屏幕阅读器而设计——具有语义化结构、ARIA 角色和清晰的标签——并直接用屏幕阅读软件进行测试。颜色兼顾了多种色盲形式，因此任何信息都不会仅凭颜色传达。合规性通过自动化无障碍工具检查，并写入书面指南，使每个团队都能以无障碍的方式构建并为系统做贡献。

影响指标

70 多个组件整合为一个单一、与代码相连的统一事实来源。

Syndigo 首条从设计到工程的流水线，在构建前用编码原型验证设计。

通过 Lovable 和 Claude Design，在产品与设计团队中全公司范围采用符合系统的原型制作。

通过一致、与代码相连的组件，缩短了从设计到开发的周期。

背景与问题陈述

该设计系统既无结构，也几乎没有治理。同一个组件常常在各产品间以若干个不一致的版本存在，且没有任何东西把设计与已上线的代码相连：没有 Storybook，没有与代码相连的组件，GitHub 里也没有 UX 的身影。

结果就是偏移。设计师、工程师和产品经理各自以不同方式理解系统，拖慢了交付，也迫使工程师从不一致的规格重建 UI。

利益相关者分析

前端工程师：需要与设计意图相符、可直接放进生产环境的组件，而不是从不一致的规格中重建。

产品设计师：我的团队需要一套受治理的组件工具包，好让他们专注于解决问题，而不是重新造 UI。

产品经理：需要快速制作原型并测试想法，而不偏离真实产品。

系统审计

在改动任何东西之前，我先审计了系统实际是如何被使用的，好让这次重建有据可依。

组件盘点：编目了所有在用组件，并找出重复项。

Figma 到生产的映射：将设计库与已上线的 UI 对照，定位偏移。

团队访谈：与设计师和工程师交流，了解系统在哪里帮上了忙、又在哪里被他们绕开。

UI Relay 插件：我构建了一个自定义 Figma 插件来运行这套系统——把组件映射到代码、追踪覆盖率和代码健康度、生成并同步组件代码、管理令牌和模板、标记待修复的缺口——把治理和从设计到代码变成一个持续的工作流程，而非一次性的清理。

挑战与解决方案

核心挑战是设计与代码之间缺失的那条链路。由于仓库里没有 UX 的身影，我争取到 GitHub 访问权限，亲自接手 Code Connect 和组件文件，让设计决策忠实地抵达生产环境，而不是被重新解读。

碎片化是第二个挑战。我没有靠人工去维护一致性，而是把重复项整合为规范组件，并构建了 UI Relay 插件，防止系统再次偏移回去。

采纳是第三个挑战。通过把系统接入团队本就想用的工具——编码原型、Lovable 和 Claude Design——我让“基于系统去构建”成为阻力最小的路径。