A design-system audit for the product you actually have.
Before a redesign, a component library, or a migration: find the decisions that keep getting reopened, and the few that make everything else easier.
What the audit is for
An audit is a close reading of the places where the product loses time: design decisions that get lost on the way to code, components with unclear jobs, exceptions that become the default, and flows that need a restart to grow.
The output is a priority map. It names the work worth systematising now, the work that can wait, and the smallest credible route between them.
- A product and interface inventory
- A practical token and component review
- A map of repeated patterns and expensive exceptions
- A focused recommendation: foundations, patterns, or implementation first
Signs you need this
The same conversation keeps returning. A component gains a new variant every quarter and nobody can say what it is for. Two teams solve the same layout differently in the same release. Spacing gets argued in review instead of settled in the file. A designer draws a state that engineering cannot build, and an engineer builds a state nobody drew.
None of that is a failure. It is what happens when a product grows faster than the decisions behind it. The audit earns its place once the cost has become visible in the calendar: reviews take longer, estimates drift, and small changes reach further than they should.
Good systems begin with a boundary
The useful boundary sits where a decision repeats often enough, or costs enough attention, that the team should be able to reach for a settled answer. Everything else stays a one-off, and that is fine.
How the work runs
The audit is the shortest piece of work Nordlean does, and it is deliberately narrow. It reads the product as it is, not as the roadmap describes it.
- Walk the live product and the design files side by side
- Pull the token, component, and pattern inventory into a single view
- Talk to the people who ship, not only the people who plan
- Mark the exceptions, then work out which of them are load bearing
- Write the priority map, then argue it with the team
The recommendation is about sequence: foundations, patterns, or implementation first. Most teams expect the answer to be all three at once. It rarely is, and the order usually matters more than the scope.
Some of what the audit finds is not system work at all. A flow that keeps causing trouble may need a product decision rather than a component, and saying so is part of the job.
What we need from you
Access, and an honest account of where the work hurts.
- The live product, including the parts nobody demos
- The design files, in whatever state they are actually in
- The front-end code, or a read-only view of it
- An hour each with a designer, an engineer, and whoever decides scope
The files do not need tidying first. A cleaned-up inventory hides the exact thing the audit is looking for, which is the gap between what was intended and what the team reaches for on a Thursday afternoon.
What you leave with
A concise working document, a set of annotated priorities, and a recommendation for the next six to twelve weeks. Clear enough to act on; specific enough to challenge.
Questions
What does a design-system audit produce?
A priority map. It arrives as a concise working document, a set of annotated priorities, and a recommendation for the next six to twelve weeks. It names the work worth systematising now, the work that can wait, and the smallest credible route between them.
When is an audit the right first step?
Before a redesign, a component library, or a migration, and once the cost of repeated decisions has become visible in the calendar. Reviews take longer, estimates drift, and small changes reach further than they should.
What do you need from our team?
Access to the live product, the design files as they actually are, and the front-end code, plus about an hour each with a designer, an engineer, and whoever decides scope. The files do not need tidying first.
Does everything become part of the system?
No. The useful boundary sits where a decision repeats often enough, or costs enough attention, that the team should be able to reach for a settled answer. Everything else stays a one-off, and that is fine.
Related guides
Make the next part of the product easier to build.
Bring the thing your team is repeatedly working around. We will work out whether a system intervention is the right move.
Let's chat ↗