What does OverlayQA check in a design system audit?

Two workflows. Design Tokens flags hard-coded colors, spacing, type and radius that should be design tokens. Components flags instances of the same element that drift apart: the same button or card styled inconsistently across the page. Both also flag interactive elements missing hover, focus, or disabled states.

Do I need a Figma file or a tokens JSON to run the audit?

No. The audit runs on the page's own consistency with nothing else attached. Before scanning you can upload a DTCG tokens JSON or pick a Figma frame, and the audit then compares the live CSS against your real tokens instead of only against itself.

Where does the design system audit run?

In the Chrome extension it runs as two cards on the Workflows tab, Design Tokens and Components, on any page you can open, including localhost and staging. In Team Review, Design Tokens runs with no extension on public URLs; Components still needs the extension.

Can the audit compare against my Figma styles?

Yes, in the Chrome extension. Once Figma is connected and a file is linked, the Design Tokens workflow lists the colour, text, and effect styles applied in that file, and compares the page against the ones you choose. Published library styles are not read yet.

Does an issue name the CSS token behind a value?

Yes, when the page defines one. If the page's own CSS has a token such as --brand and an element's captured value equals it, the issue's Element card shows the token's name under the value, so a developer sees which variable to use.

Product Feature

Design System Audit

Audit design tokens, component usage, and visual consistency across live builds before drift becomes technical debt.

Last updated: November 6, 2026

Audit design tokens, component usage, and visual consistency across live builds before drift becomes technical debt.

In the extension this runs as two workflows: Design Tokens and Components. You will find both on the Workflows tab in the sidebar.

A design system audit checks whether the shipped product still follows the design system. OverlayQA scans the live page for hard-coded colors, spacing, type and radius that should be tokens, and for components that drift apart, then compares the result with your tokens JSON or a Figma frame. Every finding becomes a tracked issue with the selector, the computed CSS and a screenshot attached. For a comparison of audit tools and their pricing, see the design system audit guide.

What's Slowing Your Team Down

Issues that create friction between design and development

Token Overrides

Hard-coded values gradually replace systematic design tokens.

Missing Interactive States

Buttons and links ship without hover, focus, or disabled styling, leaving the interface feeling dead and keyboard users without a visible focus cue.

Spacing Violations

Developers use arbitrary pixel values instead of your spacing scale, creating visual inconsistency.

Color Drift

Hex values get hard-coded or approximated instead of referencing semantic color tokens.

No Audit Process

Manual audits are time-consuming and inconsistent, so they happen rarely or not at all.

Typography Misuse

Font sizes, weights, and line heights diverge from the type scale defined in your design system.

How OverlayQA Solves These Problems

Streamlined solutions that keep teams aligned and moving fast

Systematic Design System Validation

Inspect computed CSS values across live builds to detect token drift, spacing violations, color mismatches, and interactive elements missing hover, focus, or disabled states.

Maintain design system integrity across all touchpoints

Catching token drift and component violations

Design systems degrade over time. Tokens get hardcoded instead of referenced, components get customized outside the system, and spacing values drift from the original scale. A design system audit catches these violations before they compound, but doing it manually means comparing design specs against every page and hoping you don't miss anything.

OverlayQA automates the audit. It inspects the computed CSS values on your live build to detect where tokens have drifted, where interactive elements are missing hover, focus, or disabled states, and where spacing or color values no longer match the source of truth. Each violation becomes a documented issue with the exact CSS deviation, making it straightforward to prioritize and fix the most impactful inconsistencies first.

Most teams run design system audits on a regular cadence, monthly or before major releases, to prevent drift from accumulating into costly refactors. The audit results create a clear backlog of design system violations that can be prioritized by severity and impact, giving your team a structured path back to consistency.

Common design system challenges

Token overrides: Hard-coded values gradually replace systematic design tokens across website design and development, eroding consistency that product designers established.
Missing interactive states: Buttons and links ship without hover, focus, or disabled styling, so the interface feels dead and keyboard users lose their visible focus cue, which fails WCAG 2.4.7.
No audit process: Manual audits are time-consuming and inconsistent, so the QA process happens rarely and design debt builds up until the final product requires a major overhaul.
Typography and color drift: Font sizes, weights, and hex values diverge from the design system spec, undermining user experience and brand consistency across team members' work.

Audit workflow steps

Define audit scope: Select components, pages, or features to audit for design system compliance in your project management tool.
Detect token drift: Inspect computed CSS values across the live build to detect token, spacing, and typography drift, plus interactive elements missing hover, focus, or disabled states.
Document violations: Capture issues for token drift, spacing violations, and color mismatches with full CSS context.
Export to your tracker: Send issues with full context to Jira, Linear, Notion, Asana, Trello, ClickUp, GitHub Issues, Basecamp, or monday.com so development teams can act on violations.

Frequently asked questions

What is a design system audit?: A design system audit checks whether the shipped product still follows the design system. OverlayQA scans the live page for hard-coded colors, spacing, type and radius that should be tokens, and for components that drift apart, then compares the result with your tokens JSON or a Figma frame. Every finding becomes a tracked issue with the selector, the computed CSS and a screenshot attached.
What does OverlayQA check in a design system audit?: Two workflows. Design Tokens flags hard-coded colors, spacing, type and radius that should be design tokens. Components flags instances of the same element that drift apart: the same button or card styled inconsistently across the page. Both also flag interactive elements missing hover, focus, or disabled states.
Do I need a Figma file or a tokens JSON to run the audit?: No. The audit runs on the page's own consistency with nothing else attached. Before scanning you can upload a DTCG tokens JSON or pick a Figma frame, and the audit then compares the live CSS against your real tokens instead of only against itself.
Where does the design system audit run?: In the Chrome extension it runs as two cards on the Workflows tab, Design Tokens and Components, on any page you can open, including localhost and staging. In Team Review, Design Tokens runs with no extension on public URLs; Components still needs the extension.
How often should you audit a design system?: Most teams run design system audits on a regular cadence, monthly or before major releases, to prevent drift from accumulating into costly refactors. Scheduled Scans can run the Design Tokens scan weekly and email you only when something changed.
Can the audit compare against my Figma styles?: Yes, in the Chrome extension. Once Figma is connected and a file is linked, the Design Tokens workflow lists the colour, text, and effect styles applied in that file, and compares the page against the ones you choose. Published library styles are not read yet.
Does an issue name the CSS token behind a value?: Yes, when the page defines one. If the page's own CSS has a token such as --brand and an element's captured value equals it, the issue's Element card shows the token's name under the value, so a developer sees which variable to use.