Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. User research
  3. 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

To pass point 1 (understand user needs) in your service assessments, you must:

  • 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.

Sharing what you know about users

Once you’ve learned about the different kinds of users of your service, you should present what you know in a way that’s easy for others to understand and share.

You can present what you know by creating:

  • experience maps that show how users interact with existing services
  • user profiles or personas that describe groups of users with similar behaviour and needs

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 [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

You should share your users’ needs with anyone who’s interested in your service, including colleagues, stakeholders, users and the public.

When presenting them, it can be helpful to group them by:

  • audience, user type or persona (for example, new parent, caseworker, small business etc)
  • stage in a process (for example, register, apply, interview etc)
  • theme (for example, identity, payments, licensing etc)

The more you share, the more people will learn 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:

Published by:
User research community
Last update:

Guidance expanded and clarified in response to community feedback.

  1. Guidance first published