How to spot a user need and make your digital service float like a boat

Every part of your digital service should meet a user need. Whether it’s a website, a video-based service or something else. Not just some. All.

The GOV.UK team say “Every part of the GOV.UK website design and architecture, and every piece of published content, should meet a valid user need.” Insert your service name into the above sentence. Note that it applies to both features and content.

Who are the users anyway?

Users are always people. There are several possible user types and they cannot be organisations (they have business needs).

If your service is public facing, every feature or piece of content should meet a need belonging to your beneficiaries. For example ‘as a person at risk of experiencing a crisis I need to know where to go to get the right type of help at the right time, so that I feel prepared for that eventuality’.

The internally facing parts of your service should meet your workers’ needs. For example if your service has admin functions, each feature should meet one of your staff’s user needs - e.g. to be able to easily generate reports for a senior manager (you could also write a need from the manager’s perspective).

If your service is charity facing (i.e. delivered to other charities, like a member organisation) it should meet their workers’ user needs. For example ‘to keep up to date with new national policies that affect my work in the sector’.

And if your service will have many user types then you need to think about the needs of each user type.

These things are not user needs

Many things pretend to be user needs. They are impostors! It’s not a user need if:

• You’ve always known it to be true – that’s still guesswork. Validate it.
• You think it’d be a good idea – that’s an assumption (assumptions are cool but you must test and validate them)
• Your trustees think it should be included – that’s hijacking
• Your development team thinks it should be included – that could be technical bias
• Your users say they want it – that’s poor user research

Types of user needs

Everyone agrees there are two types of user needs:

• Functional – focused on tasks, e.g. “I want to check if I am eligible for benefits"
• Emotional – more open – e.g. “when I go seeking advice on my benefits I feel worried about money and need some reassurance”

Categorising user needs is good. You should do this.

User needs vs assumptions

Many user needs begin life as assumptions. We think we know what our users need or how they’ll behave, but we don’t have clear evidence.

This is normal. As humans we are full of assumptions, so as digital service makers we need to become aware of them. That way we can test them out and see if they are valid user needs (they might still be).

How do you know it’s an assumption?

It’s an assumption if:

• You think it’s true but don’t have any evidence
• You believe it to be true because your staff tell you it is
• It’s a stakeholder opinion – e.g. your team, another service, your brother or your gran tells you they believe it
• It’s difficult to write it as a user story

If it comes from a stakeholder it’s probably an assumption. So treat it as one until you either validate or discard it.

How do you know it’s a valid user need?

Validated assumptions become user needs. But user needs can also arise directly out of user research.

It’s easy to tell the difference between a user need and an assumption. It’s probably a user need if:

• You’ve talked to your users
• You’ve carried out good user research
• You’ve asked them ‘why’ they want what they want, in a way that uncovers underlying needs, or
• You’ve watched what they do when they encounter your service – whether digital or human. You have directly observed evidence of their actions and experience.

Here’s a helpful download about recognising user needs from FutureGov’s Ben Holliday.

Good user needs save you from feeling stupid later

They help you create user value. The type of value that makes great digital services. You can’t give it your best shot without knowing them. If you don’t know them then you’ve not really tried.

So don’t fudge your user needs. Learn them and bake really good digital services (ideally in your ship's oven) 😉