Five levels, described honestly. Most teams sit one level lower than they think — and the cost of that gap shows up in every sprint, as rework, as inconsistency, and as arguments that were settled two years ago.
Design system maturity is easy to overstate because the visible artifacts show up early. A palette, a type scale, a page of components in a shared file — that is enough to say “we have a design system” in a meeting, and it is nowhere near enough to change what ships.
The levels below are defined by what is true in production, not by what exists in documentation. That distinction is the whole model. A team with immaculate guidelines and a codebase full of one-off components is not further along than a team with modest components that are actually used everywhere. It is further behind, because it also believes the problem is handled.
None of this is a scoreboard. The right level is the one that matches how many teams, surfaces and years you are spanning — and climbing past it costs more than the inconsistency it prevents.
It is in the file somewhere
Every screen is a fresh negotiation. Designers re-solve solved problems, engineers re-implement solved components, and the product feels like it was made by strangers — because in a sense it was.
Stop trying to build a system. Write down what already exists instead: an honest audit of every colour, type size, button and input actually shipping. It is usually a shocking document, and it is the only sound foundation for the next step.
A shared vocabulary, and nothing enforcing it
The vocabulary exists but carries no weight, so it drifts. Worse, it creates the appearance of a system — leadership believes the problem is solved while the actual product keeps diverging, one reasonable exception at a time.
Move the decisions into code and design tooling as tokens. When the value lives in one place that both sides consume, adherence stops depending on memory and goodwill.
Reuse, without guarantees
Reuse is real, so this feels like success — and it is where most organizations stall for years. But without shared tokens and governance, the design file and the production component drift apart, and every mismatch becomes a bug ticket nobody wants to own.
Establish parity and a contribution model. One source for tokens, one definition of each component, and a documented path for how a new pattern gets in — and how the exception that spawned it gets removed.
Tokens, parity, governance, and accessibility by default
Very little, day to day — which is why teams stop here comfortably. The residual risk is that the system serves the components it has rather than the product it is becoming, and slowly turns into a constraint people route around for anything genuinely new.
Start measuring. Adoption per team, time from design to shipped screen, accessibility defects, exception requests. A system without numbers is defended by opinion, and opinion loses budget arguments.
The system is the fastest path, and it is measured
Nothing structural. The failure mode here is complacency and staffing — platforms treated as finished get defunded, and a system that stops absorbing new product reality is a level four system with better documentation.
Keep it fed and keep it honest. Fund it as a product with users, retire what nobody uses, and periodically prove the value with the numbers you are already collecting.
Answer these about the product that is live right now, not about the one in the design file. Where the two disagree, the live one is the truth.
Can a new engineer build a correct screen in their first week without asking a person?
This separates level two from level three faster than any inventory. If the answer depends on tribal knowledge, documentation is not doing the work.
If you change the primary brand colour today, how many places do you edit?
One is level four. A handful is level three. “We would have to go and look” is level one or two, whatever the wiki says.
Who decides whether a new component gets added — and who removes the old one?
Additions are easy to govern and everyone does it. Deprecation is the honest test of whether governance exists at all.
Does the design file match what is in production right now?
Not roughly. Exactly. Parity is the single largest difference between a component library and a design system, and it is the one most teams overestimate.
Can you name your adoption rate?
If nobody is measuring, the system is being defended by belief. That works until the first budget cycle where someone asks what it returned.
New tooling is a satisfying purchase and a poor substitute for a decision. The organizations stuck at level two are almost never stuck for technical reasons — they are stuck because nobody owns the system, nobody can say no to an exception, and nothing happens when the guide is ignored. No product solves that.
Maturity is not a score to maximize. A forty-person product organization with one surface does not need a platform team, and building one will cost more than the inconsistency it prevents. The right level is the one that matches how many teams, surfaces and years you are actually spanning.
A system built by designers, for designers, ships beautiful documentation and changes nothing in production. Engineering has to be in it from the first week — the system is a shared contract or it is a picture of one.
A system with no funded owner starts decaying the moment the launch team disperses. Within a year the exceptions outnumber the rules, and you get to have the whole conversation again with a bigger backlog.
We audit the shipped product rather than the documentation, then give you a level, the evidence behind it, and the shortest credible path to the next one.
