Learning about users and their needs
When designing a government service, always start by learning about the people who will use it. If you do not understand who they are or what they need from your service, you cannot build the right thing.
Understanding user needs
People and businesses use government services to help them get something done (for example, register to vote, check if a vehicle is taxed or pay a VAT bill).
‘User needs’ are the needs that a user has of a service, and which that service must satisfy for the user to get the right outcome for them.
Services designed around users and their needs:
- are more likely to be used
- help more people get the right outcome for them - and so achieve their policy intent
- cost less to operate by reducing time and money spent on resolving problems
Researching users and their needs
You must keep researching throughout each development phase to make sure your service continues to meet user needs.
When to research
In the discovery phase, you should find out:
- who your likely users are and what they’re trying to do
- how they currently do it (for example, what services or channels they use)
- the problems or frustrations they experience
- what users need from your service to achieve their goal
In the alpha, beta and live phases, you should:
- improve your understanding of your users and their needs
- test design ideas and new features with likely users
- assess users’ experience of your service, to make sure it meets their needs
How to research
You can learn about users and their needs by:
- reviewing existing evidence (for example, analytics, search logs, call centre data, previous research reports, data from Citizens Advice etc)
- interviewing and observing actual or likely users
- talking to people inside and outside your organisation who work with actual or likely users (for example, caseworkers, call centre agents and charity workers)
Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research.
Who to research with
You must understand the needs of all kinds of users, not just ‘typical’ users. You also have to consider the needs of people who provide the service or support other users (for example, caseworkers, call centre agents, inspectors, lawyers and charity workers).
When researching, focus on users who have problems using existing services or getting the right outcome for them. This will help you create a simpler, clearer, faster service that more people can use.
Writing user needs
Once you have a good understanding of your users’ needs, you should write them down and add them to your descriptions of users.
User needs are usually written in the format:
I need/want/expect to… [what does the user want to do?]
So that… [why does the user want to do this?]
If it’s helpful, you can add:
As a… [which type of user has this need?]
When… [what triggers the user’s need?]
Because… [is the user constrained by any circumstances?]
Example:
As a [British person]
I need [to provide proof of my identity and visa permissions to border control]
So that [I can travel abroad and prove my identity]
Write user needs from a personal perspective using words that users would recognise and use themselves.
Focus on what’s most important for your users so you do not create an unmanageable list of user needs.
Validating user needs
Good user needs should:
- sound like something a real user might say
- be based on evidence from user research, not assumptions
- focus on the user’s problem rather than possible solutions (for example, needing a reminder rather than needing an email or letter)
As you progress through the development phases, use what you learn to continually validate and refine your user needs.
Share your user needs
Once you’ve learned about your users and their needs, you should share what you know with anyone who’s interested in your service, including colleagues, stakeholders, users and the public.
Present what you’ve learned in a way that’s easy for others to understand and share. For example:
- experience maps that show how users interact with existing or future services and the needs they have at each stage (register, apply, interview etc)
- user profiles or personas that describe groups of users with similar behaviour and needs (new parent, caseworker, small business etc)
The more you share, the more others will understand about your users and what they need from your service. They’ll also ask questions, spot gaps and comment on what you’re doing - all of which will help you design a better service.
Linking user needs to user stories
User needs tend to be high-level, broad in scope and stable over time.
As you design your service, you’ll use them to write user stories. These describe the specific features and content you need to create for your service to meet your users’ needs.
User stories are normally written in a more constrained format than user needs and include additional information like acceptance criteria, level of complexity and dependencies. Teams use them to organise work into manageable chunks that create tangible value.
When writing a user story, you should keep track of the user needs it relates to. This traceability allows you to track related activities and determine how well you’re meeting a particular user need.
Related guides
You may find the following guides useful:
You might also want to read this blog post about understanding the needs of service data users.
- Last update:
-
Guidance first published