Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Learning about users and their needs
When designing a government service, always start by learning about the people who will use it. If you don’t understand who they are or what they need from your service, you can’t build the right thing.
Meeting the Digital Service Standard
- show that you have a deep knowledge of who your users are
- explain how you’ve designed the service to reflect your users’ needs
- be able to provide evidence to support your understanding of users and their needs
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 etc)
- interviewing and observing actual or likely users
- talking to people inside and outside your organisation who work with actual or likely users
Treat any opinions or suggestions that don’t 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?]
As a [British person]
I need [a passport]
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 don’t 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.
You should present what you’ve learned a 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.
You may find the following guides useful:
You might also want to read the Performance Platform team’s blog about understanding the needs of service data users.
- Published by:
- User research community
- Last update:
Guidance first published