Read the Map Before You Move: Using Maturity Models Without Fooling Yourself
Maturity models, when used as strategic maps rather than scorecards, can guide design and research teams in aligning their efforts with organizational goals, fostering informed decision-making and sustainable growth.
By Ray with my favorite human, Benjamin Scott. Design Brief,
You want to grow your team's design and research work. Fine. But most leaders reach for a maturity model to get a score, feel good or bad about it, and move on. That misses the point. A maturity model is a map, not a report card. It tells you where you sit and what the next honest step looks like. Get that wrong and you spend a year building things nobody asked for. Get it right and every move you make earns its keep.
A maturity model is a shared map, not a grade
Think of these models as a way to agree on where you stand. Chris Avore puts it plainly: maturity models help you understand where you stand relative to others and show a path, without telling you exactly how to get there. His research model sorts orgs into four stages, from Laggard to Modern, across things like executive attitude, research scope, and governance.
The stages are not a ladder you climb once. Avore notes it is common to sit in a mixed state, cautious executives who still fund discovery research, and just as common to slide backward from project to project. So do not chase a clean label. Use the model to name what is real: where you are strong, where you are thin, and what your leadership actually believes about design.
One rule saves you grief. Pick one model and stick with it. Udit Maitra built his plan on the Nielsen Norman Group model and warns against switching frameworks mid-journey. Jumping between maps just resets your sense of progress.
Score it with the people who fund it
Do not rate your own maturity alone in a doc. That gives you a number you already believe. Maitra ran a survey across Business, Engineering, and UX, then sat down with 15 people one on one to ask why they scored things the way they did. His team landed between levels 2 and 3. The point was not the score. It was hearing where each group thought design fell short and why.
Those conversations are where the real plan comes from. Maitra asked simple questions: why do you think we belong here, where do we fall short, where should we focus. Patterns show up fast when you ask the same thing 15 times.
This also builds the buy-in you will need later. When your CFO or eng lead helped set the score, they own the gap too. You are not selling them a problem. You are finishing a conversation they started.
Tie the next move to a goal someone already cares about
A maturity gap on its own does not move anyone. Maitra's trick was to attach each research or design step to a goal a stakeholder already had. He wanted user personas, so he asked a business lead what their quarter priorities were, then showed how personas would sharpen feature bets. The lead ended up asking him to run it. Same with a design system: he framed it against the 220 hours a month engineers were burning arguing over handoffs, and promised to cut it. Engineering signed up on the spot.
Watch what happened. He did not pitch "raise our UX maturity." He worked next to people, learned their targets, and let their goals pull his plan forward. That is the difference between evangelizing and getting a yes.
So before you name your next investment, ask what business or engineering pain it kills. If you cannot connect the two, the move is probably for you, not for them, and it will stall.
Turn the gap into small, dated steps
A maturity model shows a big jump. Your team lives in weeks. Maitra used a plan he calls IPA: Identify where you are, Plan what the next level needs, Action it one piece at a time. He broke each big plan into micro-goals, each with an owner, a timeline, and a way to see progress. Then he re-scored a year later with the same stakeholders.
Michael Winnick's model gives you the shape of those steps for research. He tracks six moves: scope, approach, talent, structure, tempo, and output. Each one runs from foundation to expansion to integration. His warning is the useful part. Treat each step as an addition, not a swap. The tactics that got you from step one to two do not disappear when you reach for step three. You stack them.
That framing keeps you honest about pace. You do not leap from an agency model to a hybrid research team in a quarter. You add embedded researchers while keeping what already works, and you let output evolve from full decks to just-in-time updates to a real repository as demand grows.
Culture is grown, not decreed
Here is where leaders overreach. They read the model, see "design-driven culture" at the top, and try to mandate it. Mia Blume argues culture is something you garden, not architect. You shape the system around it, the environment, the structure, the incentives, the processes, and culture grows from those conditions. You cannot order it into being.
That lines up with everything above. Every maturity move is really a change to the system: how research gets staffed, where it sits, what gets funded, how findings travel. Change those and the culture follows. Announce a value on a slide and nothing sticks.
So when a model tells you a level up means "design is a respected partner," do not chase the feeling. Prune one unhealthy pattern. Run one small experiment. Let the score catch up to the system you built.
The deep cut
The number is bait. Leaders get hooked on moving from a 2 to a 3 and forget the model was only ever a way to start better conversations. The value is not the level you reach. It is the shared language it gives you and your funders to argue about the same thing.
Watch for a specific trap in low-maturity orgs. Edward Liu is honest that when a company does not get design, your time gets eaten defending the team. In that spot, a maturity model is not a growth plan. It is cover. It gives your defense a name and a next step leadership can see, so you are fighting for a map everyone can read instead of your own gut.
Three questions for your team
- Where does each of us think we sit on the model, and where do Business and Engineering think we sit? Run it as a survey, then talk through the gaps. The disagreement is the plan.
- What business or engineering goal does our next research or design investment serve? If you cannot name one, pick a different move or find the person whose target it fits.
- Which one system element, an incentive, a process, a reporting line, could we change this quarter to nudge the culture we want? Small and real beats a values slide every time.



