What the Nielsen Norman UX Maturity Scale Actually Means (And How to Move Up It)

Most organizations think they are further along the UX maturity curve than they are. Here is how to figure out where you actually stand, what it takes to move, and what nobody tells you about the gap between Level 2 and Level 3.


There is a moment in almost every design leadership role I have ever held where someone in a meeting says something like “we’re pretty mature from a UX perspective,” and I have to decide how hard to push back.

Sometimes they mean it genuinely. Sometimes they mean “we have designers now, which is more than we had before.” Sometimes they mean “we did a user study once and it went fine.” What they almost never mean is what UX maturity actually requires: sustained, org-wide investment in design capability, research integration, operational infrastructure, and executive backing that compounds over time.

The Nielsen Norman Group UX Maturity Model is the most useful framework I have found for having this conversation without it turning into an argument. It gives organizations a shared vocabulary for where they are, what is missing, and what the next stage actually looks like. I have used it at every organization I have led, and at Logility, it gave me the language to move an enterprise SaaS design org from Level 1 to Level 3 in under twelve months.

This is what I have learned about how it works and what it actually takes to move.

What the Scale Is

The Nielsen Norman UX Maturity Model runs from Level 1 through Level 6. The short version looks like this.

Level 1 — Absent. UX work happens inconsistently or not at all. There may be people doing design work, but there is no shared practice, no research, no design system, no operational structure. Design decisions are made by whoever has an opinion and enough seniority to push it through.

Level 2 — Limited. UX exists but is reactive and underresourced. Designers are order-takers. Research happens occasionally but rarely influences decisions in time to matter. There may be a nascent component library, but it is not governed or consistently used. Leadership acknowledges UX but does not invest in it deliberately.

Level 3 — Emerging. UX is starting to operate proactively. There is a research practice, even if it is lean. Designers are involved earlier in the product process. A design system exists and people actually use it. UX leadership has some organizational credibility and is starting to influence roadmaps rather than just execute them.

Level 4 — Structured. UX is embedded in how the organization builds product. Research informs roadmaps by default. The design system is maintained and governed. DesignOps infrastructure exists. UX leadership is a peer to Product and Engineering leadership, not a service function.

Level 5 — Integrated. UX thinking permeates the organization beyond the design team. Product managers and engineers use UX methods. Customer evidence is a standard input to business decisions, not just design decisions. The organization measures UX outcomes as business outcomes.

Level 6 — User-Driven. The organization treats user experience as a core strategic differentiator. UX is embedded in culture, process, and executive decision-making at every level. Very few organizations are genuinely here.

Why Most Organizations Overestimate Themselves

Level 2 is the most dangerous place on the scale because it is easy to mistake for something more advanced.

A Level 2 organization has designers. It has probably done some user research. It has something that someone is calling a design system. On paper, it looks like a functioning UX practice. In practice, what it usually has is a group of talented people doing heroic individual work with no shared infrastructure, no organizational authority, and no mechanism for their output to consistently influence product decisions.

The tell is what happens when a designer raises a usability concern and a product manager disagrees. In a Level 2 organization, the product manager wins. Not because the PM has better evidence, but because the org has not built the structures that make design evidence legible and authoritative to decision-makers. The designer’s concern gets logged somewhere, maybe, and the product ships as planned.

That is not a talent problem. That is a maturity problem. And treating it as a talent problem — hiring more designers, finding a better researcher, getting a more persuasive design lead — is one of the most common and expensive mistakes I see design organizations make.

What Moving Up Actually Requires

Here is the thing about the NN maturity scale that most explainers skip: moving from one level to the next is not about adding more design work. It is about changing what design work is for in your organization.

Moving from Level 1 to Level 2 is mostly about hiring. You need people doing UX work before you can build a practice.

Moving from Level 2 to Level 3 is about infrastructure and credibility. This is where DesignOps comes in, where a real research practice gets built, where the design system moves from aspirational to actual, and where design leadership starts operating as a strategic function rather than an execution function. This jump is harder than it looks and takes longer than most organizations expect.

Moving from Level 3 to Level 4 is about integration. You are not just building good UX infrastructure at this point; you are weaving UX methods and evidence into how the whole organization makes decisions. This requires sustained executive sponsorship and changes to how product planning and roadmapping work, not just changes to how the design team operates.

Levels 5 and 6 are long-game outcomes of sustained investment. I am not going to pretend I have a three-step plan for getting there. What I know is that organizations that reach them did not do it by accident.

The Logility Story

When I joined Logility, the org was at Level 1. Not Level 2. Level 1.

There were designers, but there was no shared tooling, no design system, no research practice, no DesignOps infrastructure of any kind. Design decisions were made in isolation and rarely connected to customer evidence. UX had no organizational authority, and the existing team was in pure execution mode with no capacity or structure for anything else.

Twelve months later, we were at Level 3.

Here is roughly what that required.

The first thing I did was not build anything. It was listening. I spent time understanding what the actual friction points were for the design team, for the product managers they worked with, and for the engineers waiting on their output. I needed to know where the pain was before I started investing in infrastructure.

The second thing was establishing basic shared practices. Shared tooling. A starter design system built around what the product actually needed rather than what looked good in a portfolio. A lightweight research process that could produce usable findings in a sprint rather than a perfect study in a quarter. These are not glamorous deliverables, but they are the foundation that everything else sits on.

The third thing was building organizational credibility. I was not going to move the maturity needle by building a better Figma library. I was going to move it by getting design evidence into roadmap conversations, by connecting design decisions to business outcomes, and by making UX legible to the executives who controlled investment decisions. That meant translating design work into the language of business impact, consistently and visibly.

By month twelve, we had a functioning DesignOps practice, a design system that was actively maintained and governed, a research practice integrated into sprint planning, and UX leadership with a seat in roadmap discussions rather than receiving them as output.

The Level 1-to-Level 3 jump in 12 months is not a typical timeline. It happened because the organization was ready to invest, I had leadership backing, and the team was talented and willing to build something together. I am not telling the story to suggest it is always that fast. I am telling it because it shows that maturity is not a function of time. It is a function of deliberate investment and clear-eyed diagnosis of where you actually are.

The Diagnosis Problem

The biggest obstacle to using the maturity model well is that most organizations do the diagnosis wrong.

The most common mistake is assessing maturity based on artifacts rather than outcomes. You have a design system, so you must be at Level 3. You do user research, so you must be beyond Level 2. What matters is not whether the artifact exists, but whether it functions as intended and whether it influences decisions.

A design system that nobody maintains is not evidence of maturity. User research that gets ignored in roadmap planning is not evidence of a research practice. An artifact that exists but does not work is sometimes worse than no artifact at all, because it gives leadership the impression that the problem is already solved.

The assessment questions I use are outcome-oriented. Not “do you have a design system” but “when a component changes, who is responsible for updating it and how does that change get communicated to the teams using it.” Not “do you do user research” but “can you name a product decision from the last quarter that changed because of something a user told you.”

Those questions get at whether the practice is functioning, not just present.

Making the Case to Leadership

If you are trying to use a maturity assessment to build a business case for investment, the framing matters a lot.

Do not walk into the room and say, “Our UX maturity is at Level 2, and it should be at Level 4.” That is a design conversation, not a business conversation, and the people who control investment budgets are having a business conversation.

Walk in and say, “Here is what our limited interactions are costing us.” Show the rework cycles. Show the time between research insight and product change. Show the engineering time spent on inconsistent components because the design system is not governed. Show the correlation between UX debt and customer churn or support volume if you have that data.

The maturity model is a diagnostic tool. The business case comes from translating that diagnosis into outcomes the organization already cares about. What is the cost of where we are? What is the value of where we could be? What would it take to get there?

That is a conversation leadership can engage with. Maturity levels alone are not.

Where to Start

If you are doing this assessment for the first time, my recommendation is to start with the Level 3 criteria rather than Level 1.

Level 1 and Level 2 are easy to assess and hard to argue about. If you are doing occasional research that rarely influences decisions, you are at Level 2. If designers are involved after product decisions rather than before them, you are at Level 2. That part is usually not in dispute.

The productive diagnostic question is whether you have the conditions for Level 3 and what specifically is missing. That is where you find the concrete investments that would move the needle.

Level 3 requires a functioning research practice, a maintained and governed design system, DesignOps infrastructure, and UX leadership with organizational credibility and roadmap influence. Look at each of those four things honestly and ask what “functioning” actually means in your context. That gap between where you are and what functioning looks like is your roadmap.

Everything else follows from that.


Amber Hansford is a Director of UX based in Atlanta who has spent fifteen years building design organizations and the practices that make them function. She raised UX maturity from Level 1 to Level 3 at Logility in under twelve months. If you want to talk about where your organization is on the scale and what it would take to move, start here.

Leave a Reply

Your email address will not be published. Required fields are marked *