Most UX maturity programmes begin with a useful question: how well are our product teams able to work with user experience? They lose their value when that question turns into a grading exercise. A score goes into a deck, a heat map starts circulating, and the next quarter is spent debating the scoring model instead of deciding where support should go.
I help run the India side of a global UX maturity programme at BMW TechWorks India. The rule that has kept the work useful is simple: the index only exists to decide what we do next for teams.
Decide what changes before you measure anything
Before choosing dimensions or writing survey questions, we had to be clear about the decisions the results would inform. If a low score would not change the support a team received, the assessment would become documentation rather than enablement.
For us, the possible responses were concrete: foundational training for teams new to UX practice, design-system support where adoption was stuck, structured measurement for applications ready to track experience quality, hands-on UX help where a session would not be enough, and leadership sponsorship where teams could not create the conditions on their own.
That decision list matters because it keeps the maturity conversation honest. The point is not to prove that one team is better than another. It is to decide which kind of help would make the next quarter more useful for the people building the product.
Teams are rarely immature. Conditions are.
This is the part that decides whether people cooperate with the programme or brace for impact.
A team with no designer, no access to the right tools, no onboarding into standards, and no senior sponsorship is not immature. It is under-resourced. Those two readings need completely different responses. The opposite is true as well: a polished interface does not prove a mature practice. It might reflect one strong designer, an inherited component library, or visual cleanup near the end of delivery.
So we look at three things separately: how the team makes product decisions, what the product tells us through research and feedback, and whether the operating conditions around the team make good UX practice possible.
Collapse those signals into one number and you lose the most useful information: what kind of support the team actually needs.
You need leadership, and leadership changes the tone
A portfolio-level assessment needs senior sponsorship. I took our plan to a forum of around twenty to twenty-five senior technical stakeholders and asked for three things: sponsorship, an application inventory, and a nominated lead for each team.
Without that support, the people who answer a maturity survey are usually the people already closest to UX. You get a flattering picture, and the help goes to the teams least likely to need it.
But sponsorship also changes how the work feels. When leadership asks teams to participate, an enablement programme can start to feel like an audit. We had to repeat the purpose clearly: this was for identifying where support goes, not for ranking teams, and every team that took part should get something useful back. That message becomes especially important when someone later asks for a team-by-team breakdown.
Annual index, quarterly response
An annual report on its own is still just a document. The value is in what happens between reports.
We run the index once a year, then use a shorter cycle for the work around it: workshops, training, Knowledge Cafes, hackathons, onboarding teams to UX Measurement and In-App Feedback, and following up with teams that need specific help. The assessment tells us where to point that effort, so enablement becomes less like a general calendar and more like a targeted service.
The annual index sets direction; the quarterly loop turns findings into support.
FIG. 1 — REPRESENTATIVE MODEL
Teams also need time. Rescoring too often mostly measures noise. The better question between annual reads is whether the support is helping teams make better product decisions.
What to look at after the score
The interesting outcomes are behavioural, not numerical:
Teams bringing research or feedback in earlier than they used to
More applications adopting a measurement method that fits their context
Recurring user issues reaching a prioritised backlog instead of staying anecdotal
Teams using the design system with less hand-holding
Leaders factoring UX capability into planning and staffing conversations
The questions getting harder, moving from access problems to product problems
That last signal is the one I trust most. When a team stops asking how to get into Figma and starts asking how to structure a research plan, something real has changed. No maturity index will show that as clearly as the conversation itself.
The team you are assessing is a user too
The teams being assessed receive the invitation, answer the questions, spend time explaining their work, and expect something useful in return.
That means the programme has its own user experience. The invitation should explain why the work matters. The questions should use language a product team actually uses. Follow-up should be quick. Recommendations should fit the constraints the team really has, not the ideal conditions we wish they had.
When that works, the relationship changes. DesignOps is no longer the function standing outside with a scorecard. It becomes the partner helping teams choose the next improvement they can realistically sustain.
Measure only what you are prepared to act on, and make the intervention more important than the index.
More on how the programme was run is in the UX maturity case study.