Audit a Design System

Audit the interface users actually experience.

Walk the live product or website and identify where implementation has drifted from the design system it is intended to follow.

A single inconsistency may be cosmetic. Repeated inconsistency across flows, components, states, or breakpoints is often a system problem.

1. Establish the standard and audit scope

Determine what the implemented interface is expected to conform to.

The reference may be:

• a published design system;
• design tokens;
• component library;
• coded component documentation;
• approved reference pages;
• an accepted implementation pattern.

When no documented system exists, establish which live pages or components the user considers correct and use them as the working reference.

Define a bounded audit scope.

Possible scopes include:

• one user flow;
• one product section;
• selected routes;
• one component wherever it appears;
• selected breakpoints;
• one theme;
• all supported themes;
• selected interaction states.

Avoid an undefined whole-product audit unless comprehensive coverage is explicitly required and practical.

Record what is in scope and what is excluded.

2. Walk the real interface

Navigate the live interface as a user would.

Inspect rendered implementation rather than relying solely on design-file specifications.

Where applicable, examine important states:

• default;
• hover;
• focus;
• active/pressed;
• selected;
• disabled;
• loading;
• success;
• warning;
• error;
• empty;
• validation;
• expanded/collapsed.

Pay particular attention to error and empty states because they are often less consistently implemented.

Inspect the breakpoints relevant to the audit.

When the product supports multiple themes, inspect the agreed themes.

Do not claim coverage for states, pages, themes, or breakpoints that were not actually inspected.

3. Identify and document drift

Use consistent categories.

Spacing

Look for:

• padding outside the accepted scale;
• inconsistent gaps;
• alignment drift;
• inconsistent section spacing;
• component spacing that differs across instances.

Typography

Look for:

• sizes outside the accepted type ramp;
• incorrect weights;
• inconsistent line heights;
• inconsistent letter spacing;
• the same semantic role rendered differently;
• inappropriate type styles for component roles.

Color

Look for:

• hard-coded or near-token values instead of accepted tokens;
• inconsistent semantic color usage;
• text or icon contrast failures;
• state colors inconsistent with system meaning;
• theme-specific mismatches.

Components

Look for:

• duplicate implementations of the same component;
• inconsistent component variants;
• variants used outside their intended purpose;
• inconsistent sizing or anatomy;
• one-off implementations that should use a shared component.

Interaction and states

Look for:

• missing focus indication;
• inconsistent hover behavior;
• disabled controls that do not visually communicate disabled state;
• inconsistent validation states;
• loading-state drift;
• state transitions that differ across equivalent components.

Shape and visual treatment

Look for:

• inconsistent border radius;
• border width or style drift;
• shadow inconsistency;
• icon size or weight inconsistency;
• mismatched container shapes.

Accessibility

Where observable and in scope, inspect:

• contrast;
• visible keyboard focus;
• state communication;
• readable disabled treatment;
• interaction affordance;
• accessible visual hierarchy.

Do not claim a complete accessibility audit unless the required accessibility testing has actually been performed.

4. Capture inspectable evidence

For every material finding, record:

• location;
• route or screen;
• component or element;
• relevant state;
• breakpoint or theme where applicable;
• expected system behavior/value;
• observed behavior/value;
• evidence;
• confidence;
• likely systemic cause when supported.

Capture enough evidence that a reviewer can understand the finding without rerunning the entire audit.

Avoid vague findings such as "spacing feels off."

State the specific mismatch.

5. Separate defects from intentional exceptions

Not every inconsistency is accidental.

Possible explanations include:

• deliberate exception;
• legacy surface;
• experiment;
• migration in progress;
• temporary implementation;
• genuine defect;
• undocumented system variant.

Group findings by confidence.

When an inconsistency appears intentional or its status is unclear, flag it for confirmation rather than automatically classifying it as a defect.

Do not overwrite product or design decisions merely because they differ from the dominant pattern.

6. Group findings by root cause

Return findings in a way that supports efficient remediation.

Prefer grouping repeated instances under a shared cause.

For example, twelve screens using the same incorrect token may represent one systemic fix rather than twelve independent defects.

Distinguish:

• systemic token problems;
• shared-component problems;
• variant misuse;
• local one-off implementation drift;
• accessibility failures;
• legacy exceptions.

This makes remediation scope clearer.

7. Prioritize what matters

Order findings by practical impact.

A useful default prioritization is:

1. accessibility failures;
2. issues affecting primary or high-value flows;
3. systemic component or token drift;
4. highly visible inconsistency;
5. isolated cosmetic drift.

Adapt prioritization to the product and user's accepted criteria.

Do not imply that visual inconsistency is more important than a functional or accessibility failure simply because it is easier to see.

8. Deliver an actionable audit

Provide:

• audit scope;
• reference standard;
• pages and flows inspected;
• states inspected;
• breakpoints inspected;
• themes inspected;
• exclusions and coverage limitations;
• prioritized findings;
• evidence for each finding;
• repeated/systemic causes;
• recommended remediation direction;
• questions requiring design or product confirmation.

Say plainly what was not inspected so a bounded audit is not mistaken for comprehensive coverage.

9. Route follow-up appropriately

When the question becomes whether a user flow functions correctly rather than whether its implementation is visually/systemically consistent, route to the appropriate product-flow audit workflow.

When an accepted finding becomes implementation work requiring requirements and acceptance criteria, route to the product-specification workflow.

Do not duplicate those workflows inside the design-system audit.

10. Preserve the audit method

After the audit approach proves useful, preserve:

• accepted design-system source;
• reference pages;
• audit scope;
• components;
• states;
• breakpoints;
• themes;
• evidence format;
• prioritization method;
• report structure.

A recurring audit may re-check agreed surfaces after releases and report new or changed drift once scope, sources, permissions, and review ownership are stable.

It should not silently classify uncertain exceptions as defects or claim coverage beyond the surfaces actually inspected.