Design System Audits
Count what is actually in production before deciding what the system should contain.
Definition
An audit inventories the interface as built: every button style, every grey, every spacing value, every near-duplicate component. It replaces opinion about drift with a list, and it is the standard first step in both starting and repairing a system.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Before starting a design system.
- Adoption has stalled and nobody agrees on why.
- After a merger or a rebrand, when two systems now coexist.
Common mistakes
- Auditing everything at once.
- Evaluating while collecting.
- An inventory with no migration plan attached.
Running one
- 1
Choose the scope
One product area or one element type across the whole product. Both work; trying to do both at once does not.
- 2
Collect, do not judge
Screenshot or extract every instance first. Evaluating while collecting biases towards what you expected to find.
- 3
Group into apparent intent
Six greys that were meant to be one. Four card layouts that differ only by padding.
- 4
Count and rank
Frequency plus visibility. A rare inconsistency on the checkout matters more than a common one in an internal tool.
- 5
Decide the target
For each group: keep one, keep two with a stated rule, or keep them all and admit they are different things.
- 6
Plan the migration
An audit that produces no migration path produces a slide deck. Sequence by risk, and pair each removal with its replacement.
What to inventory first
Ordered by how much the finding usually changes the plan.
- Colour values in use, including the ones that were meant to be identical.
- Type sizes, weights and line heights.
- Spacing values, which is where the biggest unexplained variance usually sits.
- Buttons and their states, the most duplicated component in any product.
- Form fields, especially error presentation.
- Empty, loading and error states, usually the least systematic part of the interface.
Deciding what each group becomes
The inventory is the easy half. These are the default calls for what comes back.
| Finding | Decision | Rule of thumb |
|---|---|---|
| Values that were meant to be identical | Collapse to one | No stated difference means no difference. |
| Two variants with a real difference in meaning | Keep both, and write the decision rule | If the rule does not fit in one sentence, it is one variant. |
| A deliberate one-off | Leave it local | Promotion needs three independent uses. |
| A pattern used everywhere but never specified | Promote it unchanged first | Systematise what exists before improving it, or you ship two changes at once and cannot tell which one broke. |
| Something inaccessible and widespread | Fix before consolidating | Standardising on a broken component multiplies the defect. |
Running it so it lands
Do
- Timebox the collection pass. An audit that runs for a month is an audit nobody acts on.
- Extract computed values from the running product, since that is what users actually get.
- Keep the visual evidence, because the wall of variants is the argument.
- Re-run it on a schedule. The first audit is a project, the rest are the process.
Do not
- Do not fix things while collecting. It biases the inventory and hides the size of the problem.
- Do not audit and redesign in the same pass.
- Do not present the count without the ranked first three fixes. A number with no next step reads as a complaint.
- Do not stop at colour. Spacing usually explains more of the perceived inconsistency, and costs less to fix.
In practice
- i.
Spacing tells the truth
Products that look inconsistent for reasons nobody can name usually have dozens of arbitrary spacing values. Auditing spacing first often explains more of the perceived mess than auditing colour, and the fix is cheaper.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Design and Code Parity
Design systemHow closely the design library and the implemented components agree, over time.
Key difference
An audit is a one-off count of what is actually in production. Parity is the standing relationship between the design library and the code. The audit tells you how far apart they have drifted; parity is how you stop drifting again.
Use Design System Audits when
- You are starting or repairing a system and need facts, not opinion.
- The argument about drift needs a list to settle it.
- The output is a count that justifies what the system should contain.
Use Design and Code Parity when
- Both libraries exist and each claims to be the source of truth.
- The question is which differences are acceptable.
- You need drift detected continuously, not counted once.
Local chart
SYS·011 · Region VI · Grid D3
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
Interface Inventory
B. Frost
The widely used method for cataloguing an interface before systematising it.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Check your work
Review passes that test whether this was done properly.
- UX Audit ChecklistCHK·008 · Checklist
Related concept
Connected closely enough to change how you apply this.
- Design System AdoptionSYS·005 · Design system
- Design System GovernanceSYS·004 · Design system
- Design TokensSYS·001 · Design system
- Accessibility AuditFLOW·012 · Workflow