Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Start by learning user needs
When designing a government service, always start by finding out what your users’ needs are. If you don’t know what these are, you can’t build the right thing.
Identifying user needs means working out what people or businesses need from your service - not what government thinks they need.
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 that user needs exist
Identifying user needs
People and businesses use government services to help them fulfil a task (eg register to vote, check if a vehicle is taxed, pay a VAT bill etc).
To design a service that meets your users’ needs, you must understand:
- who your users are (and aren’t)
- the task that users are trying to do and why they need to do it
- any aspect of users’ lives that influences how they do the task
- the problems that users experience trying to do the task
Focus on needs driven by what your users want to do rather than business objectives or the mechanics of delivering your service.
You should also understand the needs of all your users, not just ‘typical’ users.
When researching, pay particular attention to users who have problems completing the task or using your service. This will help you create a simpler, clearer, faster service that more people will be able to use.
Researching user needs
When to research
You must keep researching throughout each development phase to continually improve your understanding of user needs.
In the discovery phase, you should be finding out what task users are trying to complete and how your service helps them do this.
Where to get information
You can get information about user needs by:
- using existing evidence (eg analytics, search logs, call centre data, previous research reports etc)
- interviewing and visiting users
- talking to people in your organisation who deal with users
- talking to third parties who manage or deliver any aspect of the existing service
Treat any opinions or suggested user needs that don’t come from users as assumptions that have to be proven.
For example, team members, colleagues, stakeholders and third parties might have theories about what users need, but you can only validate these theories by doing research with users.
Writing user needs
User needs are usually written in the format:
As a… [who is the user?]
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:
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 in language that users would recognise and use themselves.
You need to set the boundaries of what your service can and should offer to prevent a bottomless list of user needs.
Validating user needs
You should keep reviewing and validating user needs. Good user needs should:
- be based on something a real user would say
- help you design your service and prioritise your work
- be based on evidence from user research, not assumptions
- avoid including or implying a solution (eg email or a form)
Share your user needs
You should share the user needs you find with anyone who’s interested in your service, including colleagues, stakeholder, users and the public.
When presenting them, it can be helpful to group them by:
- theme (eg identity, payments, licensing etc)
- user journey (ie steps in a process)
- audience, user type or persona
The more you share, the more people will learn about 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.
Turning user needs into user stories
User needs tend to be high-level and broad in scope. As you design your service, you should break them down into smaller user stories about specific features, functionality or design requirements.
You can use these to organise work into manageable chunks that create tangible value.
User stories often follow the same format as user needs but include additional information like acceptance criteria, level of complexity and dependencies.
When writing a user story, you should keep a record of the user need 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:
- Published by:
- User research community
- Last update:
Guidance first published