A reassuring maturity score, a design system dying anyway: the scene has become common in product teams. On paper, the system scored “Level 3 out of 5,” the result of a grid dutifully filled in the year before. In reality, no one was really maintaining it anymore, for lack of an executive sponsor, and every product team had quietly gone back to coding its own buttons.
The design system (the shared library of interface components, visual rules, and documentation that lets every team on a product speak the same visual language, much like a shared dictionary keeps people from each inventing their own words) has become, over the past decade, a standard investment in product organizations. But judging whether that investment is paying off still mostly comes down, for most teams, to a five-level maturity ladder, from initial “chaos” to final “optimization”: a single number, easy to present in a leadership meeting. That is exactly the problem.
The false comfort of a single number
Nielsen Norman Group (NN/G), one of the most widely cited user experience research firms in the world, published an article in early July 2026 that breaks with this logic: Design-System Maturity: A 6-Dimension Framework. Its starting point is a sharp critique of the models used for years: design systems, its authors write, don’t mature in a straight line; the reality of the work is far messier and more multifaceted than a ladder can capture.
This isn’t an isolated reversal. NN/G published another article at almost the same time, UX Maturity Is a Living System, Not a Ladder, applying the same critique to its own long-standing six-level UX maturity model, a model this same firm had itself popularized for years. The institution that did the most to popularize the ladder metaphor in the design world is now the first to challenge it. That signal carries more weight coming from within than from a competitor.
Six dimensions to measure design system maturity
The new framework drops the linear progression for an evaluation across six dimensions, each rated independently on a scale of 1 to 5:
- Organizational alignment: is the system positioned, funded, and championed by leadership, or does it survive on the goodwill of a few believers?
- Team effectiveness: does the team behind the system have the capacity, the range of skills, and the collaborative practices to sustain it over time?
- Infrastructure robustness: are components, tokens (the technical variables that encode a color, a spacing value or a typeface, so that a design change propagates automatically across the whole product), documentation, and tooling complete and reliable?
- Governance (the rules that define who can propose, approve, or change a component of the system, much like a condo association’s bylaws settle who is allowed to knock down which wall): are decisions clear, or does every team negotiate case by case?
- Support: is the design system team actually investing in helping the people who use it day to day?
- Real adoption: is the system merely available, or genuinely used, correctly applied, and trusted by product teams?
That last dimension deserves a closer look. NN/G breaks it into three layers: usage (is the system accessible and actually being used?), conformance (are teams applying it correctly, or quietly working around it?), and trust (do teams see it as reliable and able to evolve with their needs?). A system can show a high usage rate while being routed around the moment a need falls outside the expected cases: the classic adoption metric, often waved alone as proof of success, only captures part of the reality.
What this changes on a Monday morning
In practice, NN/G recommends running the exercise as a group: between four and eight evaluators, mixing design system team members (design, engineering, product, content), representatives from the product teams who use it daily, and sponsors from leadership. Each one rates all six dimensions separately.
The value isn’t in the average, it’s in the gap. If the design system team rates itself a 4 on “support” while the product teams who depend on it rate it a 2, that two-point gap says more about the system’s real state than a consolidated “Level 3” score. It points precisely to where the effort should go: not into the technology, but into the support that users actually perceive.
For a design system lead preparing a budget review, the difference is concrete. Saying “we’re a Level 3 out of 5” to leadership looking for where to cut arms no one. Showing that governance and infrastructure are strong (4 or 5) while organizational alignment is weak (2) shifts the conversation: the problem isn’t the team’s work, it’s the missing sponsor. NN/G makes a related point in a companion article on DesignOps (the discipline that organizes a design team’s work, processes, and tools, much like logistics organizes the work of a factory): overall maturity on that front remains low across most organizations today.
What a grid doesn’t solve
The new framework has a cost: getting six to eight people through a cross-rating exercise takes time, facilitation skill, and an organization willing to hear uncomfortable results. Nothing guarantees that the ratings, inherently subjective, escape the same biases as the old ladder: an optimistic evaluator stays an optimistic evaluator, dimension by dimension.
Above all, no grid, however fine-grained, protects a design system from purely organizational shocks. A merger, a reorganization, a budget cut can wipe out a system rated mature on all six dimensions the week before. The framework helps diagnose a problem; it doesn’t prevent one from happening.
And because this framework was just published, it doesn’t yet carry the weight of field experience the older ladders have built up over the years, despite their documented flaws. It is a promising proposal, not yet a standard proven over time.
Performing maturity, or practicing it
NN/G provides a self-assessment template, designed to be used in a workshop, a retrospective, or a one-on-one, without requiring a full formal audit. The idea connects to a broader debate in the design ops community: should a maturity model exist to produce a score to display, or to open up a difficult conversation? Too many teams, NN/G warns, end up performing maturity rather than practicing it, optimizing for the rating instead of for real usage.
The scene from the opening, that design system dismantled despite its “Level 3,” may not have been a random accident. It was a system with the right score, and the wrong questions.
Sources
- Design-System Maturity: A 6-Dimension Framework · Nielsen Norman Group
- UX Maturity Is a Living System, Not a Ladder · Nielsen Norman Group
- DesignOps Maturity: Low in Most Organizations · Nielsen Norman Group
