Discovery | Alpha | Iterative design
User interviews | Usability testing | Prototyping | Project direction
As a Lead User Researcher working on NHS Test and Trace, I built a user research function from scratch in a new team. Here I discuss the challenges I encountered introducing research capability in the team, and how I implemented a collaborative, agile user research framework to ensure the service met the needs of users. I cover multidisciplinary collaboration from the perspective of a user researcher, detailing my experiences working in blended, cross-organisational teams.
Some background
A common misconception about NHS Test and Trace is that it only involves the COVID-19 app. In fact, the organisation had numerous work-streams. I joined the Single Digital Front Door Team (SDFD).
Our objective was to help the general public to understand and find the right information and guidance around coronavirus testing. Our aim was to ‘funnel’ individuals to a centralised space that allows them to access the necessary information to support their goal. Understanding the end-to-end journey was pivotal for us, with focal points including finding the right test, how to get the test, how to take a test, what to do following a test and so on. Key touchpoints included search, NHS.UK and GOV.UK.
The challenges I faced
No previous research capability and only surface level agile methods
Delivering an MVP before the launch of universal testing (the free lateral flow testing scheme for England)
Conducting rapid discovery and alpha phases within this six-week window
Constantly shifting policies and programme priorities
Complex and often poorly defined stakeholder landscape
Service ownership was fragmented, and content governance highly political
A fully remote team who had never met in person, working through lockdown restrictions
How I approached the project
Define my role as a User Researcher
Upon joining the team, I wanted to first understand the UX maturity of the team. Were they adopting user centred design methodologies? Had research been conducted before and were the services being designed based on user needs? I mapped out all the team members and stakeholders into a clear org chart, before conducting stakeholder interviews to better understand the project landscape.
This enabled me to decide on a strategy to embed user research appropriately into the team, defining and communicating my role and value as a user researcher. This also allowed me to hold myself accountable to all the work I delivered in the team.
​
Start with user needs
For me, it was essential that I started my role at Test and Trace by first understanding the user needs that we were fulfilling on the service.
I created a repository on Airtable to collate user needs. Through a number of workshops, we hypothesised a set of user needs we'd be addressing in the project team. By reviewing secondary research conducted by satellite teams, we had a clear foundation to build on once we started our own research activities. Our needs were tagged based on user groups, journey stage, theme, priority and associated hypotheses. This was also used as a working document that was tracked and updated throughout the project.
Who were our users?
A real challenge I encountered was how to actually define users. Everyone in the UK was technically a user, because everyone benefited from access to COVID-19 testing. We had to devise a practical way of defining users for recruitment. To do this, we developed a circumstantial scale, segmenting users by different attributes, and recruiting based on a balance of factors, to ensure our sample was representative.
The diagram below illustrates the different attributes we balanced for each of our research studies.
Recruiting the underrepresented and over-impacted
COVID-19 had a disproportionate impact on people from particular socio-economic and ethnic backgrounds, including those with specific access needs. Statistically, these people were more likely to die from COVID-19. Therefore, we created a set of secondary criteria, ensuring 50% of our participants captured a set of criteria that reflected these attributes. This way, we could more confidently design services that helped those most at risk in our society.
An agile user research framework
Once I had communicated the role of user researchers in the team, connected with stakeholders, defined user groups and created a repository for user needs, it was time to implement a user research framework in the team. This was essentially a process for integrating rapid research into an agile, sprint based workflow.
The sprint cycle
The process was designed as a dual-stream framework, built from a prioritised user research backlog. The first stream was a rapid, responsive, and generally qualitative stream, where we conducted research to support the immediate team goals, whether that be usability testing of live or proposed solutions, or exploratory research to help guide design ideas. This stream was a 10-day sprint cycle (see diagram), where we defined research objectives, planned and executed the research, then presented findings in a two-week period.
The second stream was more automated and quantitative, where we evaluated the outcomes and impact of live solutions. Both streams fed back into the prioritised research backlog
A research sprint in action
Kick-off workshop and prioritisation
Days 1 and 2 focused on creating a clear and succinct set of research questions and objectives to take into the research. To do this, I ran a collaborative workshop with the immediate team (and wider stakeholders when relevant). Here we were able to revisit the research backlog, discuss our priorities and the work we were completing in the sprint, before defining our research questions.
Following this, I ran a prioritisation exercise with the project manager to determine which questions we should focus on. To remove emotion from this process, I created a prioritisation matrix that allowed us to assign a subjective score to each research question/topic. This gave us autonomy to make decisions as a team, based on facts.
Recruitment and planning
Once we had agreed our priority research questions, we broke off into a smaller squad (consisting of team members who were focused on the research outcomes, and a junior researcher) to create a test plan and recruitment screener for the research. This included objectives, research questions, participant criteria and a draft of the session structure, including journeys to be tested when applicable. For recruitment, we used a number of internal research panels, as well as a trusted third party recruitment agency.
Alignment
Finalising materals
To begin week two of the sprint cycle, we would finalise any materials that were being taken into the research sessions. This could include prototypes and research assets (such as information and marketing prompts). These were generally prepared in collaboration with the squad. We would also confirm our participant recruits for the sessions.
The first week of this sprint cycle always ended with a number of alignment sessions. As the organisation was so fragmented (with multiple overlapping project teams), it was important that other teams, wider stakeholders, SLTs and researchers were aware of the work we were conducting. Therefore, I ran sessions with a number of representatives across Test and Trace to walk through our high level research objectives and research plan.
Conducting the research
The research was typically run over 1-2 days (if qualitative). We would run the sessions entirely remotely on MS Teams due to lock-down restrictions. Team members were encouraged to support with note taking during these sessions, and wider stakeholders were able to sign up for observation. Note taking for the research was completed on Miro, ensuring we could keep all our work in the open.
Analysing and debriefing
Once the sessions were completed, I analysed the research using thematic analysis, breaking down insights into key themes and observations. As we had already established our research questions in the planning, I was able to derive insights based on the initial hypotheses we were investigating. Again, all analysis was completed in the open on Miro.
Once analysis was completed, I led a debrief workshop, where findings were played back to the team and stakeholders, and we would collaboratively decide next steps and actions based on the findings. This approach moved away from traditional documentation, supporting more rapid, outcome focused research.
Backlog grooming
The sprint would conclude with a backlog grooming session, where we would revisit our research backlog, establish whether our research questions were adequately addressed, and update our tickets. For tracking, we used Trello. This enabled us to start the next sprint with an updated backlog, ready for the kick-off workshop on day 1.
My final thoughts
-
An agile framework allows us to be responsive – the rigidity of a process allows us to be flexible, taking away the thinking and ensuring that we can move together as a single team and address big problems in a systematic way
-
Collaboration is key – it’s really important that we collaborate with each other and share our skills across the board
-
Tracking success helps you improve (and win hearts and minds) – by being able to quantitatively demonstrate the value of not only your research but the designs you’re doing, you can get buy-in from tricky stakeholders and convince them of the value of the work you’re doing
-
Always aim to build relationships outside your team – this was particularly important on Test and Trace because it was a large and confusing environment at times, so a strong network and relationships with wider organisations, user researchers, designers and other teams were extremely important
-
Remote research isn’t a bad thing! – it’s highly effective and just as valuable as in-person research, and it means you can reach a more diverse range people who may not be able to come in for a session
-
Focus on actions and outcomes, not documentation – the true value of research lies in what it can bring to the team and the actual outcome of the work you’re doing, not in shiny decks and documentation