设计系统审计技能

该技能可生成一份结构化的设计系统审计报告，涵盖组件覆盖度、设计令牌一致性、文档质量、无障碍合规性、贡献流程以及采用健康度。输出内容可直接交付设计系统团队、设计负责人或正在评估其共享组件库的工程团队使用。

必需输入项

若用户未主动提供，请向其询问以下信息：

• 设计系统名称及其服务的产品（或产品列表）
• 审计范围 — 组件库 / 设计令牌 / 文档 / 贡献流程 / 以上全部
• 当前工具链 — Figma / Storybook / Zeroheight / 自定义工具 / 多工具组合？
• 使用团队 — 设计师与工程师人数、所支撑产品数量？
• 已知痛点 — 团队抱怨最多的问题是什么？
• 治理模式 — 集中式团队维护 / 联邦式贡献者协作 / 无专职团队？
• 本次审计目标 — 提升采用率 / 支持品牌重塑 / 新团队接入 / 论证资源投入合理性？

输出结构

设计系统审计：[系统名称]

服务产品： [产品 / 应用列表] 审计范围： [全量 / 仅组件 / 仅令牌 / 仅文档] 审计方： [姓名 / 团队] 日期： [日期] 相关干系人： [设计负责人、工程负责人、首席产品官等]

整体健康评分

摘要： [2–3 句话。该设计系统当前整体状态如何？最突出的两项问题是什么？最大优势是什么？]

1. 组件覆盖度审计

评估方法： 将设计系统中的组件与产品实际 UI 模式进行比对。所有已在生产环境中存在但未被系统覆盖的 UI 模式，均视为覆盖缺口。

组件清单

覆盖度评分： [X% 的生产环境 UI 模式已被设计系统覆盖]

影响最大的缺口：

1. [系统中缺失、但在产品中高频使用的 UI 模式 — 导致最多重复开发]
2. [...]
3. [...]

2. 组件质量审计

针对每个组件，依据以下质量标准进行评估：

图例： ✅ 完整 — ⚠️ 部分实现 / 不一致 — ❌ 缺失

存在严重质量问题的组件（须优先修复）：

• [组件名称]：[具体问题及为何构成阻塞]
• [...]

3. 设计令牌审计

令牌覆盖情况：

语义令牌层： [系统是否具备语义令牌（例如在 color.blue.500 基础上定义 color.action.primary），还是仅提供基础令牌？]

令牌偏差： [代码令牌与 Figma 令牌是否同步？可借助 Token Studio、Style Dictionary 或人工比对完成验证。]

4. 文档质量审计

按组件 / 模式评估：

文档质量评分： [X% 的组件拥有完整、可用的文档]

设计师 / 工程师对文档最常见的抱怨： [例如：“我无法判断在此场景下应选用 Modal 还是 Drawer — 完全缺乏指导”]

5. 无障碍审计

WCAG 2.2 合规状态：

关键无障碍阻塞项（须在下次发布前修复）：

1. [最高优先级问题 — 例如：键盘用户无法关闭 Modal — 焦点陷阱缺失]
2. [...]

6. 采用率审计

按团队 / 产品统计采用情况：

团队未采用的原因：

7. 贡献流程审计

8. 优先级修复路线图

质量校验项

• 覆盖缺口需通过将设计系统与真实生产 UI 对比识别，而非主观推测
• 无障碍问题须明确引用对应 WCAG 准则及受影响的具体组件
• 采用障碍须有实证支撑（访谈、问卷、使用数据），不可凭空假设
• 修复路线图须包含工作量预估，并按影响程度排序
• 必须同时评估 Figma 与代码（Storybook / 实现层），不可仅检查 Figma
• 设计、工程与产品相关干系人均需审阅本审计报告

反模式警示

• 切勿仅评估 Figma 库而忽略代码实现 — Figma 与代码之间的偏差是设计系统最常见的、代价最高的失败原因之一
• 切勿未经团队访谈即评估采用率 — 审计工具指标无法反映团队选择自建组件背后的真实原因
• 切勿同等对待所有组件缺口 — 应按依赖自定义实现的生产页面数量（而非字母顺序）进行优先级排序
• 切勿在未审计文档质量前盲目建议新增组件 — 一个缺乏文档的组件，往往比没有该组件更糟糕
• 切勿在未为每项举措指定明确负责人的情况下制定修复计划 — 缺乏责任归属的设计系统改进几乎必然停滞

触发示例语句

• “对我们设计系统的一致性与覆盖度开展审计”
• “审查我们的组件库并识别缺口”
• “评估我们共享设计系统的健康状况”
• “在品牌重塑前执行一次设计系统审计”
• “我们的设计系统存在哪些问题？应优先修复什么？”