Design System Audit with AI

The challenge

The product I work on has evolved for over a decade. A large legacy ASP.NET WebForms application runs in production alongside a modern React and TypeScript monorepo.

Designers and engineers building new features had no clear picture of what components existed in each system, how they differed, or how either should be used. Every design decision was being made without shared evidence, so components were reinvented and applied inconsistently across a product used daily by hundreds of businesses.

My role

This was a two person effort. I worked alongside a senior designer, and between us we shared the work. I designed and drove the audit process, and we both reviewed the documentation that came out of it, signing off on each audit together before anything was published.

Research and approach

Manual research across two codebases is slow and error prone for one designer working alone, so I set up an AI pipeline as a research instrument. It searches both codebases, extracts usage patterns, counts occurrences and surfaces variants, which shifted my time from finding evidence to interpreting it.

I documented the whole thing as a reusable six subtask workflow so any designer on the team can run it.

“The AI does the grep work. The thinking is ours.”

Define: the process

I built a three phase process with three checkpoints, and nothing publishes without a human decision.

• Scope: confirm exactly what the component is and resolve any ambiguity before research starts.
• Legacy audit: count screens, identify variants and map each to a screen name a designer would recognise.
• Modern comparison: a gap table giving every legacy variant a verdict of Exists, Partial or Missing, backed by file and line evidence.
• Usage rules with an adversarial review, where two AI agents attack the draft from opposite lenses, human centred design and UX best practice, to find everything that could be wrong.

Design: the work

Pagination appeared in 209 screen contexts across four legacy implementations, which made it the right place to start. The adversarial review caught a real accessibility gap, a missing aria label on the container and aria current on the active page, both required for screen reader users, and it became a hard requirement in the usage rules.

Global Search was the most interesting audit. The legacy product had no platform wide search at all, only separate module level searches, while the modern product introduced a new Ctrl+K command palette. With no legacy counterpart, I documented the new pattern from scratch. Nine of the ten usage rules were strengthened by the adversarial review, and four open questions were surfaced for engineering rather than guessed.

Outcome

Every audit produces two outputs: evidence heavy documentation for the team, and a branded, shareable HTML artifact stakeholders can view without needing internal access.

A shared progress hub tracks all 20 audits automatically, and the workflow is documented and transferable, so the remaining audits all follow the same structure.

Reflection

• Scope definition is the highest leverage step.
• Adversarial review beats self review, because asking someone to find what is wrong surfaces far more than asking whether something looks good.
• Open questions are a deliverable, not a failure.
• AI accelerates research but does not replace judgement: it searched hundreds of screens in seconds, but the reasoning about what counts as a variant, what is a compliance risk and what is a dead end was ours.