Public sector · Research operations · Agile delivery
Making user research part of how a government team delivers
Embedding research in agile delivery to help an HMRC team make better-informed decisions, build research capability and meet the GDS Service Standard.
The team needed to deliver a digital service that met the Government Digital Service (GDS) Standard, but user research wasn’t yet part of its established way of working. Evidence could arrive too late to influence development, contributing to work that had to be revisited. I designed a repeatable research framework aligned with the delivery cycle, ran more than ten rounds of research with internal HMRC users, coached colleagues to take part in sessions and analysis and created a shared research library.
- Methods
- Mixed methods
- Generative research
- Evaluative research
- Strategy & influence
- Research operations
- Embedding research in agile
- Research practice
- Coaching & capability building
- Research democratisation
- Stakeholder communication
- Accessibility
- Knowledge management
- Client
- HMRC Digital Market Unit, through Capgemini UK
- Role
- Senior User Experience Researcher
- Timeline
- Jan–Aug 2021
- Stakeholders
- Product owners, product managers, developers, programme board
- Participants
- Internal HMRC users: 10+ rounds of 5–6 people
- Methods
- Evaluative: remote usability testing. Generative: interviews, contextual inquiry
- Tools
Confluence
Outcome
- The framework was associated with a 30% reduction in wasted development time, as estimated by the team.
- The service passed its GDS Service Standard assessment, with research insights supporting the team’s work towards that outcome.
The challenge
Research needed to change how the team worked
The brief was to test the product. But I saw a broader problem: the team needed a more reliable way to bring evidence about user needs into delivery decisions.
The team hadn’t historically worked in a user-centred way. Research wasn’t embedded in the sprint rhythm, so it was harder for findings to influence decisions before development effort had been committed. Running more usability tests wouldn’t solve that on its own: the team needed a repeatable approach that connected research to the decisions being made, made findings accessible and helped colleagues use evidence with more confidence.
“Dora has endeavoured to make her work inclusive with the […] team, which historically has not functioned in a user-centred way. With her nature and professionalism, she has demonstrated the value of research to the team in a manner that engages.”
The question I focused on
How might we make user research a consistent input to agile delivery, rather than an activity that happens alongside it?
Generate evidence early enough to inform upcoming development decisions.
Involve the people making and implementing decisions in research, rather than relying only on reports from a researcher.
Make findings easy to find, understand and reuse across the team.
My approach
A research loop around delivery
I owned the research approach, from establishing the framework to making findings useful to different audiences. Rather than treating each study as a separate project, I introduced a repeatable cycle that fitted the team’s delivery rhythm.
Plan research around decisions
I worked with product owners to identify the questions each round needed to answer and the decisions the evidence should inform. This shifted the starting point from “what should we test?” to “what does the team need to understand before moving forward?”
Combine methods to understand users and evaluate solutions
Across more than ten rounds of 5–6 internal users each, recruited through internal newsletters and contact lists, I ran remote usability tests, interviews and contextual inquiry over Microsoft Teams. Evaluative usability testing showed how people used the service; generative interviews and contextual inquiry revealed the work practices and needs behind it.
Make accessibility part of the research
Each round took the GDS Service Standard and accessibility requirements into account, including screen-reader use and colour, keeping inclusive use within the team’s ongoing evaluation rather than a separate final check.
Bring colleagues into the research
I coached more than 20 stakeholders, product managers and developers to observe sessions and take part in research and analysis, so they gained direct exposure to user evidence and could engage with it more independently, rather than depending on a researcher for every insight.
Tailor findings to decisions and audiences
After each round, the delivery team got concise headline findings in an insights session. The programme board got an executive summary with headline findings and key metrics. The substance stayed the same; the level of detail matched what each audience needed to act.
Create a shared research library
Research plans, findings and supporting materials lived in Confluence, so the team could find and reuse past work without relying on individual knowledge or one-to-one requests.
The research materials themselves are covered by a non-disclosure agreement, so they aren’t shown here.
The framework in practice
Each research round followed the same five-stage cycle.
- Align
Agree the research questions and upcoming decisions with product owners.
- Recruit
Include a range of internal users, from newcomers to experienced users.
- Observe
Run sessions with colleagues watching and, where appropriate, taking part.
- Synthesise and share
Headline insights in a concise session, with the supporting evidence documented.
- Apply
Feed findings into development and use the next round to examine remaining questions.
next round, back to Align
The cycle made research continuous: findings informed delivery and delivery created new questions for research.
What changed
The framework was meant to change not only how often research happened, but how the team engaged with evidence.
Research became part of delivery
The team had a repeatable cadence for gathering and discussing user evidence, with findings shared in time to inform ongoing development and the team noted the product improving after each round.
Colleagues gained direct experience of research
More than 20 colleagues were coached to observe, run and analyse sessions. Stakeholders highlighted the clarity and timeliness of the insights sessions and their usefulness during development.
Research became easier to access
A shared Confluence library gave colleagues one place to find research plans, findings and supporting documents.
Findings supported the service assessment
Insights from the mixed-method research contributed to the team’s work towards the GDS Service Standard assessment, which the service passed.
Impact
About 30% less wasted development time
A team estimate, not a formal measurement. The framework was associated with this reduction, an indication that bringing research into delivery helped the team spot issues earlier and avoid some rework.
10% bigger research budget
Following stronger stakeholder buy-in. I treat this as evidence of organisational support, not as a direct measure of research quality or user outcomes.
GDS Service Standard assessment passed
Supported by insights from the mixed-method research. Research was one contribution to a wider service effort, not the sole cause of the outcome.
Stakeholder feedback
In their own words. Excerpts are unedited apart from removed internal project names.
“Dora has run the User Research sessions very effectively and fed back excellent Insights sessions after each round, documenting the ‘headlines’ in a clear, concise format for the [product] team to then work on during development. […] Dora’s planning cannot be faulted.”
“I needed an executive summary with headline findings and key metrics for the purposes of programme board. You were very swift to supply this recognising that I did not have time to review each of the recordings […]”
Key learnings
- Research operations are part of research impact. A study has limited influence if its findings arrive too late, are hard to access or can’t be translated into decisions. The framework connected research activity with the team’s delivery process.
- Participation builds capability. Inviting colleagues into sessions and analysis helped them develop their own understanding of user needs. Capability isn’t built through reports alone; it needs practical experience and chances to apply evidence.
- Senior research involves designing for independence. My goal wasn’t to become indispensable to every decision, but to create a system where colleagues could access research, understand its implications and use it with growing confidence, with research expertise still there where it was needed.
What I’d do differently next time
The 30% figure was a team estimate. Next time, I’d define the impact measures with product and delivery leads before introducing the framework: agreeing how we’d measure wasted development time, establishing a baseline and tracking changes consistently. That would make it easier to assess the framework’s contribution and separate the effects of research from other changes in how the team worked.
I’d build more regular opportunities for the team to revisit research evidence during delivery, beyond individual insights sessions, so colleagues could spot when earlier findings still applied, recognise when assumptions needed retesting and carry learning across sprints.
And I’d evaluate the framework itself at regular intervals: whether research was reaching decisions early enough, whether colleagues were reusing existing evidence and where the process added unnecessary overhead. A research framework should evolve in response to the team, just as product research evolves in response to users.