user research: hand holding a voice recorder and a woman with a tablet

User research in government digital services: 7 steps to get it right

Research is embedded into every phase of a Government Digital Service (GDS) agile project. Although it is quite rare to find anyone who questions the need for user research, it’s not uncommon for people in project teams to hold different views about what good user research looks like and even how it should be carried out.

To make sure that everyone understands how user research can help you get to the best outcomes, we need to bring people with us. We need to help them to understand the value of research and the different forms of research that are most helpful at which parts of a GDS project. 

In this article we’re sharing our seven golden rules for getting the most from user research.

1. Make sure everyone understands what user research is for

User research always has a very specific goal and this relates to which phase of the agile project lifecycle you are in. 

When user research is done as part of a Discovery it is all about understanding what people are doing now – the potential challenges they face, their behaviours, motivations, and any unmet requirements that we can uncover.

In Alpha, user research takes on a different focus. This time it’s all about evaluating prototypes based upon the riskiest assumptions that user research conducted within Discovery has led us to. 

Ultimately, and as UX research specialist and author of ‘Just Enough Research’ Erika Hall says, the goal of user research is to ground ideas in reality and improve the odds of success, closing the gap between the design environment and the chaotic world in which our products must survive.

Across a diverse project team, this isn’t always well understood. It is also worth bearing in mind that your customer may not have had any exposure to user research before – particularly the different types of research that will be used within an agile project. It may also be the case that your customer is more familiar with quantitative research methods than qualitative research methods. This can lead to a mismatch of expectations when it comes to trying to agree on your research approach and, ultimately, the insight that you are hoping to deliver. In our experience making sure that everyone understands and buys into this goal is always first on our checklist when we start discussing user research.

2. Try to find the one big question you need to answer

Effective user research should focus on finding out the things you don’t know. It should also look to identify the interventions which may have the biggest positive impact on the lives of the people that you are designing for.

It will provide evidence to help you decide whether you want to move into Alpha – not when – and whether there is a viable product or service that you can build which makes it easier for people to do what they need to do.

There can be a temptation to see user research as a chance to validate attitudes toward a solution that the team already has in mind. This is a mistake because what matters most at this stage is closing the gap between the assumptions and biases you might have and the people who might use the product or service. If all you are looking for is evidence to confirm existing assumptions or biases then you are not using user research effectively. 

Effective research won’t focus on just what people say but also on what people do. It certainly won’t seek to establish a single truth but provide themes which give enough user insight to move confidently to Alpha.

READ: User-centred design at Zaizi: Putting users first

3. There’s no single “right” way of doing user research

Research is everywhere. From consumer research to political or academic research, research is embedded within our daily lives. One result of this is that it tends to shape people’s opinions and expectations around  the ‘right’ way of doing research: surveys, interviews, focus groups, large sample sizes, small sample sizes, quantitative research, qualitative research, statistical significance, confidence intervals, percentages, and so on. 

In our experience, the most effective way of building a shared understanding of which research method is most appropriate and when to use it is to break it down into simpler language. We tend to use qualitative research as a way of finding out what is happening and why it is happening. We tend to use quantitative research to find out how often something is happening – in other words, how big is the problem that we are looking to solve? 

The UX specialists Nielsen Norman Group outline 20 different methodologies for user research. Each has its place depending on your time and your budget but most importantly the fundamental question you want to answer.

Zaizi team member working on user research
Zaizi team working on user research

4. Consider organisational needs, not just end-user needs

When we think about the term ‘users’, we tend to think of the end user. The person who is using the product or service directly. Conducting user research with end users is non-negotiable.

Also important is consideration of advisers, case workers, people working on customer support lines. So too are the wider internal stakeholders in the client organisation who manage the product or service or are responsible for policy outcomes. Although they won’t necessarily use the product or service in the same way that an end user does, they will be affected by it and it is important to know how. Not engaging with these groups could mean that your product or service delivers unintended outcomes that may have a negative impact on the organisation that you are delivering for. 

When it comes to recruiting the right sample of end-users it is critical to include those with accessibility needs, those with lower levels of digital literacy, and in hard-to-reach and minority groups. Diversity in age, ethnicity, gender and economic background must also need to be considered.

When carrying out qualitative research, the target is to speak to just enough representative people to provide the themes and insight that will inform the next stage of service design rather than a statistically significant sample of each group which would almost certainly be cost and resource prohibitive.

5. Make sure research is iterative and embedded in the design process

The timelines and outputs of user research should always be aligned to the timeline of the project phase. If this isn’t the case then you need to think about re-focusing or narrowing the scope of your research or, if this isn’t possible, even spinning out more research. If not, you won’t leave yourself enough time to turn what you learn from raw data into actionable insights.

It’s important then for teams to think about research as iterative and embedded in the design process. In Discovery, you may need to do two or more research sprints – concurrently or consecutively – to get initial insight and build on it.

You will certainly want to gather further insight from users as your progress further along the stages of an agile project. That’s why it’s important that a project team appreciates that user research isn’t just a feature of discovery –  it carries on throughout the whole project lifecycle.

With user research it is always the case that seeking perfect information comes at the expense of discovering what is just good enough to move forward.

READ: How to design the best service design team for digital public services

6. Agree the guardrails for project-team input and research feedback at the outset

While there is necessarily a high degree of uncertainty about what you will learn from user research, one critical area to nail down at the outset is how the project team will be involved in the user research and ultimately how the research will inform the project and its outcomes.

It is also important to establish how your customer can engage in the user research process. While you should definitely encourage your customer to get involved in user research, you should establish roles, responsibilities, and boundaries.

For example, although a well-run semi-structured interview may seem like a breezy conversation between two people, it is a formal research activity designed to uncover information relevant to the project. This means that you should establish who is best suited to design and run research activities and also some ground rules about when and if it is OK for observers to contribute. Without careful consideration, you can run the risk of carrying out invalid research that might deliver false confidence in the product or service that you deliver.

Linked to this is the way that the findings of the research are shared. It’s not uncommon when presenting the main themes and insights for clients to be curious about seeing source material or watching interviews themselves. This is to be encouraged but with clear guidance around how to identify outlier commentary versus insights gleaned from a number of participants. 

The User Experience Professionals Association has a set of guidelines as part of its professional code of conduct which can provide a guide to best practice.

7. User research: uncomfortable truths often deliver the most value 

When you conduct user research you are likely to deliver insights which challenge policy, defy what has been said or believed before or tell you things which will have significant cost, resource and time implications for a project.

This is often a good indicator that you are doing user research right. If done well, it will often uncover uncomfortable truths but these are key to building better services, making better decisions, and improving people’s lives.

User research intended to rubber stamp a decision that has already been made, validate an existing solution, will not deliver the full benefit that user research can offer. It should always challenge thoughts, beliefs, biases, and assumptions. 

If you’d like to find out more about our services, please get in touch.

Thanks for joining us! We’ll keep you informed with regular updates.

Sign up to our newsletter

Consent(Required)
This field is for validation purposes and should be left unchanged.