UX Maturity Reviews: Assess Your Research Function

Assess your UX research function across five capabilities, identify its biggest constraint, and build a focused improvement plan.

What a UX maturity and capability review is—and is not

A research function can produce good work and still struggle to influence the decisions that matter. UX maturity and capability reviews provide an evidence-led way to identify the operating constraint.

The review assesses how reliably research helps people make product decisions. It is not a performance judgement on individual researchers or a league table between teams.

Overall UX maturity covers an organisation’s willingness and ability to deliver user-centred design, including the practice, resources and operations that support it (Nielsen Norman Group). A research capability review is narrower: it examines the research function while recording organisational conditions that enable or limit it.

Avoid assigning one overall label too quickly. Strategy may be clear while recruitment is fragile; governance may be strong while findings are difficult to retrieve. Different parts of a maturity system can develop at different rates (Nielsen Norman Group). The review should make those differences visible and actionable.

Set the boundary before you score. Review one product area, a portfolio or the whole function. Name the decision the review should support, such as whether to improve research operations, change planning practice or add specialist capacity. For a wider organisational view, see UX Maturity Model for Product Teams.

The five capabilities to assess

Use these five capabilities to examine the conditions behind reliable research. Research-function models can include people, execution, research operations, impact and executive support (UserTesting). This worksheet groups related practical concerns into five areas that you can assess independently.

Capability	What you are assessing	Score 1: ad hoc	Score 2: repeatable	Score 3: embedded	Score 4: adaptive
Strategy	Connection between research priorities, roadmap and investment decisions	Requests drive work	Priorities are documented for some work	Research informs regular planning	Priorities adapt using decision outcomes and new evidence
People	Role clarity, competence, development and collaboration	Responsibilities are unclear	Individuals have workable roles	Teams collaborate with clear expectations	Capability is deliberately developed and shared
Process	Methods, planning, recruitment, cadence and quality checks	Studies vary without a repeatable approach	Core steps are repeated inconsistently	Workflows support regular delivery	Workflows are reviewed as needs change
Governance	Consent, privacy, participant stewardship and standards	Guardrails are unclear	Basic materials exist	Standards are consistently used	Guardrails support safe, proportionate research at pace
Evidence use	Findability, synthesis, decision traceability and follow-through	Findings are isolated or forgotten	Some outputs are shared	Evidence is accessible and used in decisions	Decisions and outcomes inform future research

These scores describe observed practice, not people. A team does not need a score of 4 in every category. The appropriate level depends on product context, decision risk and the work the team needs to support.

Strategy asks whether research addresses live product and business questions. People covers research skill, role clarity and the working relationships that let product and design colleagues use research. Process includes choosing suitable UX research methods, planning studies, recruiting participants and checking quality.

Governance covers consent, privacy, participant stewardship and clear boundaries for non-researchers. Evidence use asks more than whether reports exist: can someone find relevant evidence, understand its limits and trace how it informed a decision? Sound research operations practice can help make these capabilities sustainable.

Run the review: a 60-minute evidence-led procedure

Treat this as a compact baseline, not a workshop designed to manufacture agreement. Reserve 60 minutes, invite a small cross-functional group and ask each person to bring evidence.

Step 1: assemble lightweight evidence. Gather a recent roadmap, study plans, recruitment records, consent materials, repository examples, decision logs and feedback from people who commission or use research. You do not need a perfect archive. You need enough material to distinguish reliable practice from assumptions.

Step 2: score independently. Give participants the worksheet and ask them to score each capability from 1 to 4 before discussion. Include research leadership, product and design representatives, plus relevant operational partners. Independent scoring surfaces different experiences of the same system.

Step 3: attach evidence. Record one artefact and one specific stakeholder observation beside every score. An artefact might be a study plan, consent form, repository entry or roadmap decision. “Product managers cannot locate previous concept-testing findings” is more useful than “research needs better visibility”. Mark unsupported assumptions as unknown rather than forcing a score.

Step 4: compare and diagnose. Discuss the evidence behind score differences and note variation between product areas. A matrix can reveal uneven operational capability; for example, a team may have stronger governance than knowledge management (Rally). Identify the capability most limiting reliable research use instead of averaging everything into one maturity label.

Step 5: validate briefly. Test the provisional diagnosis in short stakeholder conversations. Ask which decisions are delayed, made with avoidable uncertainty or repeatedly revisited. Record strengths worth protecting alongside gaps to address.

Here is a completed worksheet for a fictional product team. It is illustrative, not client evidence.

Capability	Score	Artefact	Stakeholder observation
Strategy	3	Quarterly research plan linked to roadmap themes	Product lead uses findings in planning
People	2	Role descriptions and development notes	Designers involve research late in some projects
Process	2	Two recent study plans	Recruitment timing varies between studies
Governance	3	Current consent template	Teams know when to seek support
Evidence use	2	Repository with incomplete tagging	Previous findings are difficult to find

The initial constraint appears to be process, specifically recruitment. Before changing it, check participant handling and consent requirements. UX research panel management and AI notetaker consent and privacy cover related operational considerations.

Use the prioritisation matrix to choose the next improvement

A score tells you where to investigate. The prioritisation matrix helps you decide what to do next. Rank only improvements connected to the limiting capability.

Capability gap	Evidence	Affected decision	Expected impact	Effort	Dependency	Owner	First milestone	Review date
Inconsistent participant recruitment	Recent study plans show variable lead times; product team reports delayed concept tests	Which concepts progress to build	Timelier evidence for concept decisions	Medium	Approved consent and participant process	Research operations lead	Document workflow and run it for the next study	After the next research cycle

This is a hypothetical example, not client evidence. Its first action is a consent-aware recruitment workflow, not an automatic technology purchase or a broad redesign of the research function.

Compare candidate improvements against four questions:

Is the gap supported by artefacts and observed behaviour?
Which decision is affected, and how often?
What effect should the change have on that decision?
What effort and dependencies must be resolved first?

A hiring need is more credible where the constraint is sustained capacity or specialist competence that a workflow cannot safely absorb. A workflow improvement fits where the work is known but inconsistent. Tooling may help where valuable evidence is inaccessible, provided ownership, standards and adoption are in place.

Use this comparison before deciding when to outsource user research or estimating options with a user research cost guide. External support can address a defined gap, but internal decision ownership still matters.

Choose one or two improvements that remove a current bottleneck. Reassess after a meaningful planning or delivery cycle, and revisit scores sooner if the product context, leadership or operating model changes.

Turn the review into a credible capability plan

The review becomes useful when it changes a visible behaviour. Turn the selected improvement into a short plan:

Desired behaviour: what people will do differently.
Owner: the person accountable for moving it forward.
Required support: time, leadership backing, specialist input or budget.
First milestone: a concrete deliverable or observed change.
Evidence of progress: artefacts, decision records or stakeholder feedback.
Review cadence: when the group will check whether the constraint has eased.

Frame the leadership conversation around decision risk and the operating constraint revealed by the review. “Concept testing is delayed because recruitment is inconsistent” is clearer than “we need to increase maturity”.

Do not copy another organisation’s operating model without testing whether it suits your decisions, product pace and participant responsibilities. Do not reward score inflation. A score is a snapshot of current conditions, not a permanent label.

If you need an independent baseline or facilitated discussion, Glasgow Research can help you run a research capability review. Read Research Operations: Build a Reliable Research Practice for operating foundations that support lasting improvement.

Frequently asked questions

What is a UX maturity and capability review?

It is a structured assessment of the practices and conditions that allow a research function to produce evidence and influence decisions. Capabilities can develop unevenly, so assess them separately before choosing an improvement.

How often should a UX research maturity assessment be repeated?

Repeat it after a meaningful planning or delivery cycle, and after material changes such as a reorganisation, new leadership or a change to the operating model. A fixed universal interval is less useful than reviewing when decisions and conditions have changed.

Who should take part in a research capability review?

Include research leadership and representatives from product, design and relevant operational partners. Ask people to score independently before discussion so differing experiences are visible.

Should every research team aim for the highest maturity score?

No. The appropriate capability level depends on product context, decision risk and the work the team must support. Focus on removing the most consequential current constraint while sustaining practices that already work.

About Glasgow Research — Glasgow Research helps B2B SaaS teams turn customer and market research into product decisions. Work with us.