Design System Audit

Design System Audit Skill

This skill produces a structured audit of a design system — covering component coverage, token consistency, documentation quality, accessibility compliance, contribution processes, and adoption health. Output is ready for a design system team, design leadership, or an engineering team evaluating their shared component library.

Required Inputs

Ask the user for these if not provided:

• Design system name and what product(s) it serves
• Audit scope — component library / design tokens / documentation / contribution process / all of the above
• Current tooling — Figma / Storybook / Zeroheight / custom / combination?
• Team using it — how many designers and engineers, how many products?
• Known pain points — what do teams complain about most?
• Governance model — centralised team / federated contributors / no dedicated team?
• Goal of the audit — improve adoption / prepare for a rebrand / onboard new teams / justify investment?

Output Structure

---

Design System Audit: [System Name]

Products served: [List of products / apps] Audit scope: [Full / Components only / Tokens only / Documentation] Auditor: [Name / Team] Date: [Date] Stakeholders: [Design lead, Eng lead, CPO, etc.]

---

Overall Health Score

Summary: [2–3 sentences. What is the overall state of the design system? What are the top 2 issues and what is the biggest strength?]

---

1. Component Coverage Audit

How to assess: Compare components in the design system against the actual UI patterns in the product. Every pattern that exists in production but not in the system is a coverage gap.

Component Inventory

Coverage score: [X% of production UI patterns are covered by the design system]

Most impactful gaps:

1. [Most used pattern not in the system — causing most duplication]
2. [...]
3. [...]

---

2. Component Quality Audit

For each component, assess against these quality criteria:

Legend: ✅ Complete — ⚠️ Partial / inconsistent — ❌ Missing

Components with critical quality issues (fix before anything else):

• [Component name]: [Specific issue and why it's blocking]
• [...]

---

3. Design Token Audit

Token coverage:

Semantic token layer: [Does the system have semantic tokens (e.g. color.action.primary on top of color.blue.500) or only primitive tokens?]

Token drift: [Are code tokens and Figma tokens in sync? Use a tool like Token Studio, Style Dictionary, or manual comparison.]

---

4. Documentation Quality Audit

Assessment per component / pattern:

Documentation score: [X% of components have complete, usable documentation]

Most common designer / engineer complaint about docs: [e.g. "I can't find whether to use Modal or Drawer for this use case — no guidance exists"]

---

5. Accessibility Audit

WCAG 2.2 compliance status:

Critical accessibility blockers (must fix before next release):

1. [Most critical issue — e.g. Keyboard users cannot close Modal — focus trap missing]
2. [...]

---

6. Adoption Audit

Adoption by team / product:

Why teams are not adopting:

---

7. Contribution Process Audit

---

8. Prioritised Remediation Roadmap

---

Quality Checks

• Coverage gaps are identified by comparing the design system to actual production UI, not assumed
• Accessibility issues cite specific WCAG criterion and affected components
• Adoption barriers are backed by evidence (interviews, survey, usage data) — not assumed
• Remediation roadmap has effort estimates and is sequenced by impact
• Both Figma and code (Storybook/implementation) are assessed — not just Figma
• Stakeholders from design, engineering, and product have reviewed the audit

Anti-Patterns

• Do not assess only the Figma library without checking the code implementation — Figma-code drift is one of the most common and costly design system failures
• Do not score adoption without interviewing teams — audit tool metrics miss the human reasons teams build custom components instead of using the system
• Do not treat all component gaps equally — prioritise gaps based on how many production screens rely on custom implementations, not alphabetically
• Do not recommend adding more components without first auditing documentation quality — an undocumented component is often worse than no component
• Do not schedule remediation without a named owner per initiative — design system improvements without ownership consistently stall

Example Trigger Phrases

• "Audit our design system for consistency and coverage"
• "Review our component library and identify gaps"
• "Assess the health of our shared design system"
• "Run a design system audit before we do a rebrand"
• "What's wrong with our design system and what should we fix first?"