All articles
Process

What a Design Audit Is, and How to Run One

MAY 18, 2026 · 6 min read · Subin

A design audit is not an opinion about how the product should look. It is a factual inventory of how it looks right now: every color, spacing, component, and state actually in use, and where they disagree.

Inventory before judgement

The first pass is counting, not fixing. Pull every distinct value the product renders: how many grays, how many button variants, how many modal implementations, how many spacings between 12 and 16 pixels. The raw counts are usually the shock that motivates the work.

Only once you can see the real inventory does it make sense to decide what should be canonical and what is drift.

DriftFour different grays used for the same card surface
A11yPrimary button contrast fails on the muted background
ScaleSpacing of 12px and 16px used interchangeably for the same gap
DupeTwo modal components ship, one of them undocumented
PassFocus ring present and consistent across inputs
A findings list, ranked by harm: accessibility and drift first, cosmetic duplicates after.

Rank by harm, not by ease

Not all inconsistencies are equal. A contrast failure is an accessibility defect that can exclude real users; four grays for one surface is drift that costs maintenance; two near-identical spacings is cosmetic. Rank findings by how much each one hurts, then fix in that order.

This is what keeps an audit from becoming a cosmetic cleanup that misses the defects that actually matter.

An audit without a pipeline just repeatsCleaning up today does nothing about tomorrow. Pair every audit with the architecture and lint that stop the same drift from returning, or you will run the identical audit again in two quarters.

Turn findings into tokens

The output of a good audit is not a slide deck; it is a set of decisions encoded into the system. Each canonical value becomes a token, each canonical pattern becomes a component, and each defect becomes a fix plus the guardrail that prevents its return.

Done that way, an audit is not a recurring chore. It is the moment a product's real state gets folded back into its source of truth.

Automate the parts a person cannot hold

A human auditor is good at judgement and bad at counting. Flip the work to match. Let tooling enumerate the raw inventory, every color, spacing, and shadow the codebase actually renders, and reserve the human for deciding what should be canonical. Counting by hand is where audits get abandoned halfway.

Once the inventory is generated rather than gathered, the audit becomes repeatable. You can run it every release and watch the numbers move, instead of treating it as a heroic one-off that decays the moment it ends.

An audit measures reality. A system is what keeps reality from drifting again.On design audits