Design System Audit: Find the Drift

A design system audit should locate operational drift, not count tidy components

A design system audit should compare what the team intends to ship with what users actually receive. Before buying one, require evidence across the Figma library, production components, live product usage, accessibility behavior, performance, documentation, ownership, and contribution workflow. The useful output is not a maturity score. It is a prioritized map of mismatches, their effect on users and delivery, the likely cause, an owner, and a realistic path to repair.

A polished component catalogue can coexist with duplicated code, inaccessible states, detached designs, and teams that bypass the library to meet deadlines. The audit must therefore inspect the system in use. If a provider only needs a Figma link and a few screenshots, it is reviewing the showroom while the machinery remains behind a locked door.

Scope the design system audit around decisions and representative journeys

Start with the decision the audit must support. A visual refresh needs a different investigation from consolidating three libraries or improving accessibility. Name the products, platforms, frameworks, brands, locales, and journeys in scope. Also name what is excluded. Without that boundary, every inconsistency becomes a finding and the report becomes a guilt spreadsheet.

Provide design libraries, repositories, package history, documentation, issue tracking, relevant field data, and access to the people who build with the system. Sample components by risk and reach: navigation, forms, dialogs, tables, and patterns with brand or compliance consequences. Include real screens so composition problems appear, not just isolated defects.

A short product discovery workshop can clarify the question when stakeholders disagree about whether the problem is visual consistency, engineering duplication, governance, or product usability. That disagreement is useful evidence. It often explains why the system drifted in the first place.

Compare Figma, production code, and actual product usage as separate layers

Build three inventories. The design inventory records components, variants, variables, tokens, states, documentation, and ownership. The code inventory records packages, APIs, props, dependencies, versions, test coverage, and consumers. The product inventory records where components appear, which teams use them, and where local alternatives have emerged. Matching names are not proof of parity. A `Button` can expose different sizes, disabled behavior, icons, and focus treatment in every layer.

The comparison should produce a traceable matrix: design component, code component, product instances, supported states, known exceptions, and current owner. Figma's Code Connect documentation describes explicit mappings between design components and production implementations, including property mappings and code examples. That can make relationships visible, but a connection is not a quality certificate. The mapped component can still be difficult to use, inaccessible, slow, or routinely bypassed.

Ask the auditor to distinguish intentional variation from unmanaged drift. A mobile implementation may need a different interaction model. A regional product may have legal content requirements. Those differences should be documented as supported variants or separate patterns. Accidental copies with no owner, no upgrade path, and subtly different behavior are debt.

Test component quality in real states, not only in the default story

Components fail at their edges: long labels, translated content, validation errors, loading, empty data, permissions, keyboard navigation, zoom, high contrast, reduced motion, and narrow viewports. The audit should exercise those states inside representative flows. A component that looks correct in isolation may create a trap when focus moves through a modal, a filter updates a table, or an error message is announced late.

Combine automated checks with manual evaluation. W3C's evaluation tools guidance says tools save time but cannot perform every accessibility check and can produce inaccurate results. A credible audit uses automation to find repeatable faults, then tests keyboard behavior, names and relationships, screen reader output, focus order, content reflow, contrast states, and recovery by hand.

If the system needs a formal conformance assessment, define that separately. The current WCAG Evaluation Methodology requires a defined scope, exploration, representative samples, evaluation, and reporting. A design system audit can identify systemic accessibility risks, but it cannot declare an entire product conformant from a component sample. Use a dedicated website accessibility audit for that decision.

Measure performance and adoption without inventing a return on investment

Component architecture affects shipped JavaScript, duplicated CSS, rendering, layout stability, and interaction latency. Test the built product, inspect representative routes and bundle contributions, then connect lab findings to field data. web.dev notes that Core Web Vitals are primarily field metrics; Lighthouse cannot directly measure INP because a page load does not reproduce real interaction.

Adoption also needs evidence: package versions, duplicated implementations, support requests, contribution time, exceptions, documentation gaps, and team interviews. These are diagnostic signals, not universal business metrics. A team may bypass a component because a state is missing, releases are slow, or ownership is unclear. Each cause needs a different fix.

Do not accept promised conversion lifts, fixed productivity gains, or one adoption percentage as proof of value. An audit can estimate reach, risk, and repair effort, not causal revenue impact. Link the roadmap to observable outcomes such as fewer divergent implementations, faster supported contributions, fewer recurring accessibility defects, or better field responsiveness.

The deliverable should be a release sequence, not a giant backlog

Use visible checkpoints. Agree on scope, access, samples, and decision criteria. Review the inventory with designers and engineers so naming differences do not become false findings. Validate high-impact issues in real product contexts, then review priorities with the people who own product commitments.

Require an evidence register, parity matrix, component examples, and remediation roadmap. Every priority should name the affected products, consequence, evidence, change, dependencies, owner, and verification. Group work into containment, repair, migration, and governance. Some teams need a token migration first; others need a contribution model.

GOV.UK's design system contribution criteria offer a useful model: additions should be useful, unique, usable, consistent, and versatile, with evidence from representative users, browsers, assistive technologies, and devices. Your criteria will differ, but they should be explicit enough that a component can be accepted, rejected, deprecated, and maintained without a meeting of the design priesthood.

A good audit protects active delivery instead of demanding a freeze

The serious objection is capacity. Teams fear an external audit will deliver hundreds of defects while the product roadmap keeps moving. Address that in the engagement design. Timebox discovery, sample by risk, validate patterns before expanding them, and cap the first remediation horizon. A small number of systemic fixes can remove many local symptoms, while low-risk visual inconsistencies can wait.

Avoid a full rewrite unless the evidence makes incremental repair less safe or more expensive. Existing components carry learned behavior, integration details, and user expectations. Migration needs compatibility decisions, versioning, codemods or documented manual steps, product-team support, and a way to monitor adoption. Coordinate major changes with the broader website redesign strategy rather than quietly rebuilding the foundation under active features.

An external auditor also has limits. They will not understand every historical exception in a week, and repository access does not reveal team incentives. Require interviews, playback sessions, and a challenge period for findings. The goal is a shared model of the system that survives the report, not a consultant's immaculate diagnosis that nobody owns.

Design system audit buying checklist

• Name the business decision, products, platforms, journeys, repositories, libraries, and exclusions in scope.
• Require separate inventories for design, code, and product usage, with explicit mappings and exceptions.
• Include real states, responsive behavior, accessibility, performance, documentation, ownership, and contribution workflow.
• Ask how representative samples are chosen and how systemic findings are confirmed before the audit expands.
• Require evidence, consequence, owner, dependency, repair path, and verification for every priority.
• Plan a playback, challenge period, first remediation horizon, migration support, and focused retest.

Before requesting proposals, prepare a one-page brief with the decision, products, known symptoms, access available, delivery constraints, and the date by which the roadmap must influence planning. If the issue spans interface design and implementation, send it to Seuil Digital and ask for the smallest design system audit that can change a real release decision.