Haelo
Design SystemsEditorial14 July 2026·4 min read

NN/g's New Design-System Maturity Model: What It Really Tests

Design systems have a measurement problem. Teams can point to component counts, adoption dashboards, and Figma library stats, but few can answer a harder question: is the system actually healthy, or just busy? Nielsen Norman Group's new maturity framework, built around six dimensions, is an attempt to give that question a shape.

The framework's stated purpose is diagnostic rather than promotional — a tool for design-system teams to assess where they stand and decide what to fix next, rather than a badge to earn. That framing matters more than it sounds. Most design-system content in the wild is case-study shaped: here's how Airbnb, Shopify, or IBM built theirs. NN/g's move is to step back from exemplars and offer a structure any team, at any scale, can apply to their own mess.

That's the right instinct, because design-system maturity has always been unevenly distributed within organisations. A system can have gorgeous documentation and a rotten contribution process. It can have governance nobody follows and adoption nobody measures. Reducing that to a single "maturity level" — the way CMMI or DevOps maturity models once tried to do for software — tends to flatten real, contradictory states into a tidy score. The value of a multi-dimensional model is that it resists that flattening. Six axes means six separate diagnoses, and a team can be advanced on one and embarrassingly behind on another. That's closer to how design systems actually behave in practice: not linear projects but ongoing negotiations between design, engineering, and product priorities.

What should a working designer or design-system lead actually do with a framework like this? Treat it as an audit prompt, not a scorecard to optimise. The temptation with any maturity model is to chase the highest tier across every dimension, which produces exactly the kind of over-engineered, over-governed system that slows teams down rather than helping them. A component library with perfect versioning discipline and zero adoption is not mature — it's abandoned. The framework is only useful if teams are willing to sit with uncomfortable answers: that their token pipeline is solid but nobody outside the design team understands it, or that adoption looks strong because three product squads are mandated to use the system while the rest quietly maintain their own components.

This also lands at a moment when design systems are under real organisational pressure. Budgets for dedicated design-ops teams have tightened since the hiring peaks of 2021–2022, and AI-assisted UI generation is raising fresh questions about whether rigid component libraries are the right unit of reuse at all. A maturity framework published now reads less like housekeeping advice and more like a defence of the discipline: a reminder that a system's worth isn't just in how much surface area it covers, but in whether it's governed, adopted, and evolving in ways people can actually verify.

The honest test of any maturity model is whether it changes behaviour six months later. Checklists get filled in once during a workshop and then forgotten; the frameworks that stick are the ones teams return to quarterly, arguing over where they've slipped rather than where they've scored well. Whether NN/g's six dimensions earn that kind of repeat use will say more about the framework's design than its content.

Full details are available from Nielsen Norman Group at nngroup.com.

design systemsmaturity modelcomponent librariesdesign tokensprocess