AI Skill Report Card
Auditing Design Systems
Audits Figma designs against design system standards and produces a prioritized list of violations with specific, actionable fixes.
Quick Start14 / 15
Select a frame, page, or entire file, then run the audit:
Audit [selection] against the design system:
1. Scan all fills, strokes, text styles, spacing, and radii
2. Flag any hardcoded values that have a matching token/variable
3. Check component instances for overrides that break the system
4. Rank findings by severity: Blocking > Major > Minor > Polish
5. Output a table: Layer | Issue | Current Value | Suggested Fix
Recommendation▾
Add a third example showing accessibility (contrast/touch target) violations since it's listed as a category but not exemplified
Workflow14 / 15
Progress:
- Step 1: Identify scope (single frame, page, or full file)
- Step 2: Inventory the design system (tokens, components, styles available)
- Step 3: Scan selection for violations across 5 categories
- Step 4: Cross-reference each hardcoded value against available tokens
- Step 5: Rank and group findings by severity
- Step 6: Generate fix list with exact before/after values
- Step 7: Optionally auto-apply low-risk fixes (token swaps, renaming)
The 5 audit categories:
- Tokens/Variables — hardcoded hex colors, spacing, radii, font sizes that have an equivalent variable
- Components — detached instances, overridden properties that drift from the source component, wrong variant usage
- Spacing — padding/gaps/margins not aligned to the base grid (typically 4pt or 8pt)
- Accessibility — contrast ratios, touch target sizes, missing alt-text annotations
- Naming — layers named "Frame 427" instead of semantic names; inconsistent naming patterns vs. rest of file
Recommendation▾
Include a bad-output example to contrast vague vs. specific fix suggestions
Examples16 / 20
Example 1:
Input: Frame with a button using fill #3B82F6 and padding 18px 22px
Output:
BLOCKING: Button fill #3B82F6 matches token `color/blue/500` — bind variable instead of hardcoded hex
MAJOR: Padding 18px/22px not on 8pt grid — nearest valid values: 16px/24px (spacing/md, spacing/lg)
Example 2: Input: Component instance "Card" with text override that isn't in the type scale (15px, should be 14 or 16) Output:
MAJOR: Card > Title uses 15px, not in type scale — snap to `text/body/md` (16px) or `text/body/sm` (14px)
POLISH: Layer named "Card 2" — rename to "Card / Pricing" to match sibling convention
Recommendation▾
Provide a template for the final output table format to make results more consistent across runs
Best Practices
- Always inventory the existing token/variable library first — never suggest a fix that doesn't map to something real in the file
- Group findings by frame/screen, not by category, so designers can fix one area at a time
- Give exact replacement values, never vague guidance like "use a token here"
- Distinguish "Blocking" (breaks system, must fix before handoff) from "Polish" (nice-to-have) so teams can triage
- When auto-fixing, only touch clearly safe swaps (exact token matches); flag ambiguous cases for human review
Common Pitfalls
- Don't flag every hardcoded value as equally severe — a 1px spacing discrepancy is not the same as an unbound brand color
- Don't suggest new tokens should be created during an audit — that's a separate design-system-building task
- Don't ignore context: a hardcoded value might be intentional (e.g., a one-off marketing page), so note exceptions rather than force-fixing everything
- Don't skip the inventory step — auditing without knowing what tokens exist produces useless generic advice