Reading the room: assess and raise design maturity
TL;DR
Design maturity is how deeply design is woven into the way an organisation works. You don't need a team of designers to raise it. Read the room first, using twelve signals across strategy, culture, process, and outcomes. Focus on the weakest area before anything else. Then prove it: write down a baseline, change one thing, and track a number someone senior already cares about.
We've all been there. The single UX designer in a team of developers.
Everyone's friendly. Nobody's quite sure what you do all day. And somewhere around week three, someone asks if you can "just make it look nice" before Friday.
Here's what I've learned about that spot: you can't fix it by working harder, and you can't wait to hire your way out of it. What you can do is read the room. Work out how much the organisation actually understands about design, then move that one step at a time.
That's design maturity. This post is how I figure out where a team stands, what I do in the first 90 days, and how I show the business it was worth it.
What design maturity actually is
Design maturity is how deeply design is woven into the way an organisation works. Not how good the designers are. Not how pretty the product is.
The model I lean on describes six stages: absent, limited, emergent, structured, integrated, and user-driven. At the bottom, design is something that happens at the end, if at all. At the top, user needs shape strategy, and the whole organisation thinks that way by habit.
Two things from that model change how I work:
It has four moving parts. They're strategy, culture, process, and outcomes. Two organisations at the same stage can look very different underneath.
The realistic goal is one step up. Leapfrogging from stage two to stage five doesn't hold. And maturity can slide backwards if nobody keeps an eye on it.
That last point is the one I find most useful. It means my job isn't to arrive and announce a transformation. It's to find the weakest part, and elevate that first.
How to tell where a team really is
Nobody puts "we're at stage two" in a job ad. So here's what I look for, in plain words. Score each row honestly, then look at the pattern across the four groups, not the average. The lowest group is where I'd start.
Factor | What I look at | Low maturity looks like | High maturity looks like |
Strategy | Vision | Rarely written down. If it exists, few people have heard of it. | Clear, user-centred aims, shared on purpose and used to make decisions. |
Planning and priorities | Plans barely mention design, and when they do, it's to check finished work. | A shared way of prioritising, design quality is tracked, and research can start projects. | |
Budget | Few dedicated people, scraps of budget, designers spread across too many teams. | Enough people and time, allocated on purpose, for improving what exists and building what's needed. | |
Culture | Awareness | Design is what happens at the end to make things look nice. | Everyone understands design shapes a product from the first idea. |
Support | Leaders are indifferent, early research is a luxury, buy-in depends on who you ask. | Support from many teams, respect between peers, and backing from the very top. | |
Competency | No dedicated roles or titles, and basics like qualitative research are missing. | Clear roles and career paths, a wide range of skills, room to grow. | |
Adaptability | Rigid habits. The whole practice rests on one or two people. | Ways of working bend to what the team needs, and work carries on when someone leaves. | |
Process | Methods | Few methods, often used badly. Research rarely changes anything. | A mix of methods across the lifecycle, iteration is normal, discovery comes first. |
Collaboration | Only people with "design" in their title own it. Everyone else joins late. | Working across disciplines is a habit, with regular stand-ups and retrospectives. | |
Consistency | One-off activities that can't be repeated or compared. | Shared tools, training and frameworks, maintained and improved. | |
Outcomes | Impact of the design | Success means a list of features shipped. | Success means the project goals were met and real user needs were answered. |
Measurement | Metrics unrelated to users, or a few token ones nobody tracks. | User-centred goals drive the metrics, which follow the whole journey and reach leadership. |
Teams with strong design grew revenue faster
"Design maturity" can sound like a designer's hobby. The numbers say otherwise: organisations that do design well grow faster than those that don't.
McKinsey tracked 300 listed companies over five years. The top quartile for design practice grew revenue 32 points faster and shareholder returns 56 points faster. Their edge wasn't a bigger design team. They measured design as rigorously as revenue and cost.
IBM and Forrester put a price on it. Forrester's study of IBM's design thinking practice found a 301% return on investment and 75% less time spent on design and alignment. Caveat: IBM commissioned it, and it rests on four interviews and 60 survey responses. A signal, not a guarantee.
And from my own work, at a much smaller scale:
Three systems became one. Staff processing an order used to switch between three systems. Now it's one.
One change, five platforms. One change, five platforms. On a white-label product with a shared design system, developers build a change once and it rolls out to every brand, instead of being rebuilt five times. That saves developer time and effort on every release, and handoffs got faster and more predictable. Three brands run on it now, with two more in development.
None of those started with the word "maturity". They started with a team agreeing that a fragmented experience was a business problem, not a design problem. That agreement is the thing being measured here.
How a team moves up, one step at a time
The stage names come from the model above. The "what I'd do" column is mine, from experience. Read it as a starting point, not a recipe.
Stage | Where it stalls | What to do next |
Absent | Nobody does design on purpose, so nobody knows what's missing. | Fix one visible, annoying problem for real users and show the before and after. |
Limited | Design happens late, by whoever's free, and is seen as polish. | Get into one project at the start. Bring one piece of user evidence to a planning meeting. |
Emergent | A few people care, so results depend on who's in the room. | Write down what worked: a lightweight process, a shared research folder, design in the definition of done. |
Structured | There's a process, but outcomes aren't measured. | Agree two or three user-centred measures with a product owner and report them regularly. |
Integrated | Design and development plan together, but measures stay inside the product team. | Connect those measures to what leadership already tracks. |
User-driven | User needs shape strategy. The risk is standing still, and sliding back. | Protect it: regular reflection, onboarding for new joiners, a visible roadmap. |
A note on how I read this. Teams are rarely at one stage across the board. They're usually uneven: strong process, weak measurement. Good intent, no budget. So the table is a menu, not a ladder. I focus on the weakest factor first, because that's the one holding the others back.
My first 90 days
If I were to join a team, this would be my plan. It will bend to the situation. The order mostly won't.
Days 1 to 30: listen and score
Sit in on planning, stand-ups, and a release. Notice where design shows up and where it doesn't.
Ask for the last three decisions that changed the product, and how each was made.
Score the twelve rows privately. No slides yet.
Days 31 to 60: one small win, together
Pick a problem people already complain about. Not the biggest. The most visible one I can finish.
Do the work with developers in the room from the start, not as a handoff at the end.
Write a baseline before touching anything: what it takes users today, how long it takes, what it costs support. When I audited a volunteer platform, scoring it against recognised usability heuristics (75% overall, with error messages at 39%) gave the team something to argue with instead of opinions.
Days 61 to 90: make it repeatable
Show the before and after to the people who sponsor the work, in their language: time, money, errors, support requests.
Turn what worked into something lightweight and reusable. A research template. A checklist. A line in the definition of done.
Agree on the next target with the weakest factor in mind, and say out loud what I'm not going to attempt yet.
Numbers: what to measure, and how to move it
What I've learned is that one metric is never enough. I think of it as a ladder, from what a designer can observe, like task success, to what a leader answers for, like revenue and retention.
Level | The question | Example measure | Who cares |
Usability | Can people do the task? | Task success rate, time on task, errors per task | Design, product |
Experience | Do people trust and like it? | Satisfaction score, drop-off at known pain points | Product, support |
Behaviour | Do people actually use it the way we hoped? | Share of tasks done on mobile, completion of key flows | Product, engineering |
Operations | Does it cost us less to run? | Support requests, manual steps, tools per task | Operations, finance |
Business | Does it move what leadership tracks? | Conversion, retention, revenue per customer | Leadership |
How I move a number
Baseline it first. Pick one measure a sponsor already worries about, and write down where it stands before you change anything.
Change one thing, and say what you expect. A prediction can be wrong, and that's useful.
Look again after a fixed time. Share what moved and what didn't. A miss, reported honestly, buys more trust than a win nobody checked.
Looking back, and keeping it going
Here's the uncomfortable bit. Maturity doesn't stay put. People leave, priorities shift, a reorganisation lands, and quietly the team slides back to "can you just make it look nice". Levels can regress.
So I treat maturity like a garden, not a trophy.
Re-score every quarter. Ten minutes with the team on the four factors. It works best with developers and product people in the room too.
Pass it on. If I'm the only one who can run the process, I haven't raised maturity. I've just been busy.
I don't have this fully figured out. Every team is a different mix, and I'm still learning where my instincts are right and where they're just habits. But the question I keep coming back to is simple: if I left tomorrow, would this still work?
If the answer is yes, that's the job done.
Sources
Forrester: The Total Economic Impact of IBM's Design Thinking Practice (2018, commissioned by IBM)
Smashing Magazine: Accelerating UX Maturity With A Breakthrough Project (John Scott Bowie)
