Audit Your Design System With 6 Dimensions, Not One Score

A design system can look healthy on paper and still quietly fail. Tokens are in place, the component library is published, and the documentation site exists. Then you open ten production screens, count how many are actually built from the library, and the number is embarrassing. Strong infrastructure, near-zero adoption. A single maturity "level" would have told you none of this.

That is the core problem with rating a design system on one scale from 1 to 5. Maturity is not one thing. It is at least six different things that rarely move at the same speed. NN/g's framework names them, and once you stop treating maturity as a badge and start treating it as a profile, the question changes from "how mature are we?" to something far more useful: "where exactly is the gap, and is it the gap worth closing first?"

Why does a single maturity score mislead you?

A single score averages away the one number you needed to see. If your infrastructure is a 5 and your adoption is a 1, an averaged "level 3" describes a team that does not exist. Worse, it points you towards the wrong work. A "level 3" team tends to invest in more infrastructure, because that is the part they are good at and enjoy. Meanwhile, the actual bottleneck, adoption, gets no attention at all.

I have watched this happen. The system keeps improving at the thing that was already fine, and the reason nobody uses it never gets addressed. A profile forces the honesty a score lets you avoid. It shows you a shape, and the shape usually has one leg much shorter than the rest. That short leg is your roadmap.

What question does each of the six dimensions really ask?

Treat each dimension as a question you answer with evidence, not a feeling. Here is how I read them, with a threshold for each so the answer is not just "kind of."

• Organizational alignment: Is the design system a funded product with a named owner and a roadmap, or a side project someone maintains after hours? The threshold is boring but decisive. If no single person has design-system work in their actual job description, alignment is low, whatever leadership says in meetings.
• Team efficiency: How long does it take to assemble a standard screen from existing parts? If a common layout, a form with validation and states, takes a designer or developer a full day because they are rebuilding primitives, efficiency is low. Hours, not days, is the bar for a system that is pulling its weight.
• Infrastructure: Are design tokens the single source of truth, and is the library shipped as a versioned package consumed through a package manager? If components are copy-pasted between projects, or tokens live in three places that disagree, you do not have infrastructure. You have a folder.
• Governance: What is the median time from "we need a new component" to "merged, documented, and released"? Weeks is workable. Months means every team routes around you and builds one-offs, which is how you end up with fourteen button variants nobody sanctioned.
• Support: Is there a named channel and a human who answers it, with a first response typically inside a working day? A system with no support trains people to stop asking and start guessing. Unanswered questions are silent adoption killers.
• Adoption: What percentage of shipped, production UI is actually built from library components? This is the one people avoid measuring because it is the one most likely to hurt. If fewer than roughly 40% of your live screens use the library, adoption is your problem, full stop, no matter how good the other five look.

Notice that four of these six are measurable this week without a survey. Coverage, build time, cycle time, and response time are all countable. Alignment and support have a harder edge but a clear pass/fail test. That is what makes this a diagnostic rather than a vibe check.

How do you turn six answers into a profile you can act on?

Score each dimension low, medium, or high, and write the profile as a single line. Something like: infrastructure high, governance medium, support medium, efficiency medium, alignment low, adoption low.

Read it as a shape, not a sum. The pattern above is extremely common. It is a system built by people who love tooling and shipped into an organization that never committed to it. The high infrastructure is real. It is also irrelevant until alignment and adoption catch up, because a beautifully engineered library that 15% of screens use is a cost center, not a system.

The opposite profile exists too. High adoption, low infrastructure. Everyone uses the components because they are genuinely helpful, but they are held together with duct tape, versioning is manual, and one breaking change could take down five products at once. That is a system living on borrowed time, and the fix is technical, not political.

The point of the profile is that these two teams need opposite next steps, and a maturity score would have given them the same one.

Which gap should you close first?

Close the dimension that is capping the others, not the one that is easiest to improve. In practice, there is usually one leg holding everything back.

If adoption is low while everything else is medium or high, do not build more. Go find out why people are not using what exists. Nine times out of ten it is friction: the components are hard to discover, hard to integrate, or missing the three variants every team actually needs. That is a support and governance problem wearing an adoption mask.

If alignment is the low leg, no amount of engineering rescues you, because the system will keep losing the resourcing fight. The work there is a business case, an owner, and a line in someone's roadmap, not another Figma library.

If infrastructure is the low leg but adoption is high, you have permission to fix the plumbing, and you should, quickly, before growth turns fragility into an incident.

The sequencing logic is simple. Find the shortest leg. Ask whether it is capping the value of the taller legs. If it is, that is the work. Ignore the temptation to top up a dimension that is already at 4 just because you know how.

What does running this audit actually feel like?

It feels uncomfortable in a good way, because it converts opinions into numbers you cannot argue with. This is the same move theuxbites makes on the technical side of a site. A Lighthouse score or a heuristic flag is only useful once it stops being a grade and becomes a specific, prioritized thing to fix. A design-system audit works the same way. The framework is not the deliverable. The prioritized short leg is.

So block two hours. Pull ten real production screens and count component coverage. Time how long the last standard screen took to build. Look up how long your last new component took to ship. Check whether anyone answered the last question in your support channel. Write the six-word profile. Then look at the shortest leg and ask the only question that matters: is this what we are working on next?

If the answer is no, you now know something a maturity score would have hidden from you for another six months.