Search

Show your commitment with a team contract 

It can be useful to formalise your commitment to user research at the start of the process. You can do this with a 1-page team contract. Use the contract to explain, in simple terms, what your team will build and how you'll apply user research. 

Ask the digital leader responsible for the service to sign the contract before the team starts. This will give the team confidence to do the user research to check they’re building the right thing. 

Continuous research

To work in an agile way, service teams must update their understanding of users and their needs throughout the service design and delivery process.

You will need to do research in every iteration of the development stage, starting in Discovery and continuing through to Live. Make sure your user research plan shows this. 

This will help you: 

• save time by building only what your users need
• reduce risk by learning quickly what works for users
• understand the problems users have and how they can be resolved
• respond to changing user behaviour and feedback to continuously improve the service.

Make time for user research  

You'll develop a user research plan after your team kick off meeting. In the meantime, talk to your team about how you will schedule the user research. 

Build research activities and analysis into the team’s regular schedule. This will make sure your whole team knows what's happening so they can take part. It can take a long time to recruit users for research, so it’s important to start early. 

Qualitative and quantitative research 

Seek support for both qualitative and quantitative research. Quantitative research gives you a limited view of who the users are and what they need. 

Start the Discovery stage with qualitative research, such as in-depth interviews with users. Use quantitative research to help you work out which user groups you should talk to. 

Get started with a user researcher

User researchers should be a core part of your team throughout each stage of service design and delivery. They'll do user research at least every 2 weeks. 

It’s always better to work with a full-time user researcher. If you don't have these skills on the team, make it a priority to secure an expert as soon as you can. In the meantime, you can still do some user research activities like pop-up research. 

GOV.UK has a useful blog on getting started with user research. 

Don’t outsource user research 

Your team needs to build empathy with the users to understand what to build, this is especially important in Discovery. 

It's best to do the research in-house. This will help you team understand the relationship between the users' questions and the research findings.

Get help from other teams 

Your agency may have teams who can support your research. They may recruit users on your behalf or support you to meet users accessibility and inclusivity needs.

Remember everyone on your team needs to engage with users. Don't rely on other teams alone. 

Outcomes from Discovery 

Once you complete your research, you'll be able to analyse your findings to gain insights.  

In the Discovery phase you should: 

• understand the problem you’re trying to solve for the user 
• understand the touchpoints along the user journey, often expressed as a journey map, service map, mental model or alignment diagram 
• create a clear set of needs and develop task models for different types of users 
• understand the gaps, limitations and barriers for the user  
• understand the opportunities for further research 
• document user groups descriptions and characteristics that are significant for the service, often expressed as user profiles or personas combined with actual stories from user.  

Complete Discovery research

You’ll have done enough research when you understand: 

• who uses your service 
• what users needs from your service 
• how people with support and access needs interact with your service.

User research in Alpha 

In the Alpha stage, try lots of different approaches to meet user needs and find out which approach works best. 

The Alpha stage will help you reduce risks, including: 

• design risks, making sure you have the right scope for the service 
• business processes, finding out if government can build the service 
• technical capability, making sure you can integrate the service and make it secure. 

Work out what works, not what's popular 

Be prepared to park any ideas that do not meet user needs. You may find different elements of an idea work. Take what is working and combine it with other ideas. Remember to document what you’ve tested so you can refer to it later. This helps the team remember what’s been tested and what hasn’t. 

Do task-based testing so you can understand which version is most effective. Remember we care about what works, not the preferences people have. 

You’ll know something works when people find it easy to complete a task. They will understand what they are doing and won't make mistakes. 

Keep interviewing, iterating and testing 

Once you have a prototype, even if it’s a paper one, you can start to test it with users. 

You can see if your ideas will meet user needs and find out if the prototype is usable. You can use this insight to iterate your design and test again with users. 

Combine prototypes tests with user research interviews. This will help you to deepen your understanding of user needs. 

User research in Beta stage

In the Beta stage, you’ll learn ways to improve your service. Including different kinds of experiences users may have, including usability and accessibility issues.

There are 2 different research stages in Beta: 

1. Researching as you build the beta service. 
2. Researching with users of a working beta service. 

Private Beta research  

As you build out your Beta service, you'll continue to do task-based usability testing with a range of users. This time, you are aiming to refine a solution for launch.

When you do the task-based usability testing:  

• decide on a hypothesis, this is how you think the design will meet a user need 
• use a structured approach to evaluate, this will make it clear what work needs to be done 
• test with people who have different needs.

Public Beta research  

In Public Beta you will continue with your research and explore the information and data you gained from your public users. 

In this stage you will conduct interviews and feedback from users and front line staff and do user shadowing.

You will also 

• create 2 versions of the service to see which performs better, this is called A/B testing
• collect analytics and key performance indicators
• do audits including usability and accessibility tests 
• collect operational data to measure service performance, such as customer service insights  
• do follow-up interviews to collect detailed feedback from service users.

User research in Live stage 

In the Live stage you will test and collect feedback to make sure your service meets user needs. These research activities will build your understanding of common issues to help you improve the service. 

You can learn more about user needs through: 

• web analytics and operational data  
• surveys or follow-up interviews  
• face-to-face and remote usability tests  
• A/B testing on new and changed features. 

The frequency and depth of the research you do in Live depends on what you are trying to find out. For example, you should start the Discovery process again before adding a new component to your service. 

Sort observations 

When you’re ready, ask your team to place their observations on a wall or virtual canvas. As a group you will work to sort your observations into similar themes.  

The idea is to look for patterns or clusters in the data by grouping the information until clear themes emerge. You can group by:

• common topics, for example identity, delivery, payment 
• stages in a user journey, for example ‘supply photo’, ‘attend interview’, ‘pay’ 
• individual pages or steps in a transaction 
• types of users, for example, first time user, business user. 

Name your groups 

Once you’ve sorted your observations, agree on a title that represents the cluster. From there, you can break large groups into smaller themes by matching observations.

For example, if users need to supply a photo to use your service, you might have a ‘photos’ group that could broken down into:

• photo rules and requirements 
• using a photo booth or store photographer 
• taking a photo at home 
• reasons a photo might be rejected. 

Determine findings 

The final part of the analysis is determining what the observations mean. When you agree on what you’ve learned, write it as a finding or insight and add it to the relevant group on your affinity map. Write findings as short statements that summarise what you’ve learned, for example:

• ‘the legal declaration is threatening and difficult to understand’
• ‘people think they can click the progress bar to navigate’ 
• ‘users are confused about what they need to do because so many questions are optional’.

Confirm the actions 

Use your findings to make decisions about what to work on or change. This supports the agile method of continuous planning with new facts or requirements. As a group, discuss if there are any actions you want to take. Write these on sticky notes in another colour. Add them to the relevant group on your affinity map.  

Actions might include:

• new design ideas to work on 
• new questions to include in user research 
• things you want to change in a prototype and test in another research session 
• new user stories to add to the product backlog 
• new details you need to add to an existing story 
• strategic insights you can use to develop your user needs, proposition or product roadmap. 

Share your findings 

Collate your findings so you can share them with the wider team and stakeholders. This is sometimes called a shareback.

You can share insights in different ways. If you've been testing prototypes you might show printouts with comments on sticky notes. If you've only just started, you might read out quotes and observations.

Use an electronic presentation to share your findings or whatever medium suits your team.