Denis Kharchenko — Lead Product Designer
Design maturity is often described as a progression. First, designers execute. Then they get involved in research and discovery. Later, they influence product decisions. Eventually, design becomes part of strategy.
I understand why this model is useful. But the more I work with product teams, the less I think maturity is about how sophisticated the design function looks. A team can have a design system, run research, work closely with engineering and follow a structured process, while still having very little influence over what the company decides to build.
I started thinking about maturity differently: how much can design change a product decision? That shifts the focus away from the quality of the artefact and towards the system around it.
If a designer joins after the PRD is written and the solution is already agreed, there is still plenty of design work to do. We can improve the interaction, simplify the flow, handle edge cases and make the UI coherent. But the biggest decisions may already be out of reach.
I saw this in RateWise. The simulator looked like a UX problem: it was slow, dense and demanded too much information upfront. But research showed that the deeper problem was what the product was optimising for. Brokers weren't trying to calculate the lowest rate. They were trying to work out which mortgage product fit the person sitting in front of them. That changed the work from improving a calculator to designing for the conversation around the calculation.
This is one of the clearest differences I see between tactical and more mature design work. The question isn't just:
"Can design improve this solution?"
It's:
"Can design still question what the solution is supposed to be?"
The earlier that becomes possible, the more influence design can have.
This is where design maturity can easily get confused with design activity. You can interview users every week and still have most important decisions made before the research starts.
Having a research process doesn't necessarily mean an organisation makes evidence-based decisions. The more useful question is whether the organisation is able to change its mind.
EVmarket was a different version of the same problem. The product assumed that users already understood electric cars, while research showed that many were still trying to understand the basics before they could even start comparing them. The research therefore didn't just improve the interface. It changed who we were designing the first session for and what that session needed to accomplish.
That distinction matters. Research isn't evidence of maturity by itself. What matters is whether evidence can change the direction of the work.
There is an opposite failure mode too. Once teams realise they need better discovery, the natural response is to introduce a process. More templates. More workshops. More checkpoints.
That can help, but process alone doesn't make an organisation more mature. It can just create a more predictable version of the same behaviour.
In a design maturity workshop, we looked at where the design team was already strong and where the surrounding way of working was getting in the way. The team had strong execution, good collaboration with engineering, growing research practice and increasing influence in product discussions. At the same time, discovery was inconsistent, design wasn't always involved early enough, UX metrics weren't embedded into decisions, and important insights could arrive late enough to create rework.
One of the changes we proposed was introducing a 0-stage: Problem Definition before the existing 30/60/90 framework. The intention was simple: establish the problem, assumptions, risks and success criteria before the team starts designing the solution. Other changes connected that stage with continuous discovery and introduced shared templates for problem framing, validation and handoff.
That led me to a distinction I find useful:
"A mature process doesn't tell designers what to do. It makes the important questions hard to skip."
The process should create space for uncertainty rather than hide it. It should help the team ask:
AI makes this way of thinking harder to ignore. With a traditional interface, a lot of the work is about designing a sequence of screens and states. With AI, you're often designing when the system should act, when it should ask, how it should communicate uncertainty, and what happens when it doesn't know.
In one recent AI product, I worked on an interaction where the system could take a user's input and determine whether it had enough information to proceed.
The important design decision was when clarification was necessary at all. How the step looked mattered much less.
A clean request should move through quickly. An ambiguous one should trigger questions. The system should explain what it found and what each answer would change, rather than asking users to review everything it had processed. That led to a simple principle:
"How certain the system is should influence how much it asks."
This is another shift from designing screens to designing a decision system. And it brings the same maturity question back into focus: where does design have influence? Not just over the interface, but over the behaviour of the product itself.
The more I think about this, the less useful it feels to treat design maturity as something a design team can achieve on its own.
Better craft still matters. Research still matters. Design systems still matter. But none of them are enough by themselves.
A designer can be good at framing problems and still be brought into the work too late. A team can have a sophisticated design system and still make product decisions based mostly on opinion. A company can run continuous discovery and still ignore what it learns.
That's why the changes from the maturity workshop weren't limited to the design team. They included roadmap shaping, regular discovery reviews with PM and Engineering, shared UX metrics, problem-framing workshops and stronger design–engineering rituals.
Making designers more effective was only part of it. The goal was to change the environment in which product decisions were made.
So I don't think design maturity is a ladder for designers to climb. It's a way of looking at how a product organisation makes decisions.
For me, those questions tell us more about design maturity than how polished the final interface looks.
More case studies and notes: denisxko.com · full text of everything: /llms-full.txt
© Denis Kharchenko. All rights reserved.