A design system audit is an inventory of what your system actually contains. It measures how far the product has drifted from that inventory, and what it costs to close the gap.
This assumes you have a system to audit in the first place. If you are still deciding whether you have one or just a component library, start there.
Most audits sold today only look at Figma. They count components, flag detached instances, and call it done.
That is half the job. The design system that actually ships to users is the code. The Figma library is a drawing of it, a useful one, but still a drawing.
An audit that only reads the drawing can tell you the drawing is tidy. It cannot tell you the product is consistent.
This post covers both sides: what to check in Figma, what to check in the codebase, and how far apart they usually are.
The Figma-only audit, and why it feels productive
A Figma audit is real work. Run one properly and you will find duplicate components, six button variants nobody remembers making, layers still named "Frame 247," and styles that were never turned into variables.
It is also satisfying. You can see the mess. Then you can watch it get clean.
That is most of what Ramotion, DOOR3, Sparkbox, Netguru, and House of Maestro sell as a design system audit. None of it is wrong to do.
The problem is what it leaves out. A tidy Figma file and a consistent product are two different achievements. Only one of them is visible to a user. Nobody has ever filed a bug about a detached instance.
Here is the distinction worth holding onto, because none of those audits draw it clearly. A detached instance in Figma is cosmetic. It costs a designer some relinking. A hardcoded hex value inside a shipped component is a bug. It renders on a real screen, to a real person, and it will not update when the token changes.
One of those is housekeeping. The other is the product being wrong.
Audit the code, because that is the system that ships
Here is what I actually look for once I open the repository, not the Figma file.
Hardcoded values. Grep the component code for raw hex colors, raw pixel values, and magic number spacing. Every one is a place the token never reached. These findings carry real consequences. When the brand color changes, a hardcoded hex does not.
Duplicate implementations. Two Button components living in different folders. Three separate modal implementations. A card component that got copy pasted once and quietly diverged. This is extremely common, and it is invisible if you only look at Figma.
Components in code that Figma has never seen. An engineer builds a utility component under deadline pressure. It never makes it back into the library. Nobody audits for this, because nobody looks at the code.
Components in Figma that were never built. This is the reverse drift. The library looks richer than the product actually is.
Token value disagreement. The same token name resolves to a different value in Figma and in code. This is the worst one on the list, because both sides believe they are correct. The way to stop it recurring is upstream, in the figma to code workflow itself, where shared token names keep the two from drifting in the first place.
None of this is exotic. It is the same discipline a usability audit applies to a flow: watch what actually happens, not what the file says should happen.
Figma's Dev Mode and Code Connect exist specifically to make design and code parity checkable side by side. If you can read both a component's Figma definition and its React implementation, use them. They will not do the audit for you, but they cut the time it takes to find where the two disagree.
Measure adoption, or the audit is just opinion
Here is the second gap. Nobody selling these audits publishes an adoption number. An audit without one is a list of complaints with no scale attached.
The real question is simple. What share of the product's UI is actually built from the design system, versus one off code that happens to look similar?
A few honest ways to get at it:
- Scan the codebase for imports from the design system package. Weigh them against total component usage across the app.
- Tag components at runtime. Look at what actually renders on the pages people use most, not the pages that happen to be newest.
- Do not trust a self reported number from the team. Teams routinely believe adoption is far higher than it really is, because they are counting the components they built, not the screens users actually see.
None of these measurements are exact. Every number you produce here is an estimate, and the report should say so, plainly, next to the number.
An honest estimate beats a confident fiction. A client can act on a range if they understand how you counted it. They cannot act on a suspiciously precise number nobody can defend under a follow-up question.
Who is actually paying for the drift
Nobody selling these audits names this, and it might be the most useful line in this whole post for a founder or a head of engineering.
Engineers pay for it. Quietly, every day.
Every time a Figma spec does not match the shipped component, an engineer has to guess. Is the spec stale, or is the code wrong? They usually guess in a hurry, mid sprint, and each guess widens the gap a little further.
That cost never shows up on a design ticket. It shows up as velocity: why does a simple change take three days. It shows up as a growing suspicion among engineers that the design files are not worth opening.
The same pattern shows up in how B2B teams brief and manage design agencies, where unclear ownership between design and engineering quietly taxes every handoff.
Once that suspicion sets in, the design system is dead. It does not matter how good the Figma file looks.
What the deliverable should be
Two different outcomes get sold under the same name, and almost nobody separates them.
A Figma cleanup plan: rename layers, relink instances, fix component descriptions, tidy the file. Useful. Low stakes. A designer can execute the whole thing without touching a pull request.
A codebase migration plan: dedupe redundant components, replace hardcoded values with tokens, and delete dead ones. Then sequence all of it without freezing feature work for a quarter. This is the plan that actually changes what users see. It needs someone who can read the code, not just the file.
Most audits sold today deliver the first one and get priced like the second.
A real report contains all of this:
- An inventory of both sides: the Figma library and the coded components.
- A drift list ranked by user impact, not by tidiness.
- An adoption estimate, with the method stated next to it.
- A migration sequence, with an owner named for each item.
Anything short of that list is a Figma cleanup wearing a bigger price tag.
Audit the drawing, or audit the product
The Figma audit is not wrong. It is half of the work, and it is the easier half. The half that actually ships to users is the code, and that is the half almost nobody checks.
If your last design system audit never opened the repository, you paid for a report about a drawing. A tidy drawing, maybe. Still a drawing.
An audit is also only the first of three things you can buy, and what each engagement shape costs is worth knowing before you sign one bundled quote. We audit both sides: the Figma library, the shipped components, the adoption estimate, and a migration sequence somebody can actually follow. If that is what your team needs, our design system consulting work starts there.