User needs are what make your TfG boat rock. Fudge the needs and you’ll sink. Nail them and you’ll be cresting a wave of user value from here to Tech for Good Bay.
Warning: There are a fair few ‘musts‘ and ‘shoulds‘ in this article. Stop reading now if you don’t want to be told what you ‘should’ do…
Every feature must meet a user need
Every part of your digital service. Whether it’s app, website 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?
If it’s public facing it should meet a need belonging to your public users.
If it’s service facing it should meet their workers’ user needs. This includes services that use your product with their own service users.
If it’s internally facing it should meet your worker’s user’s needs. For example your product has an admin portal. Each admin feature should meet one of their user needs.
And if your product faces multiple user types (likely!) then each feature must meet a distinct need of one, or more, of the groups.
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 – that’s complacent guesswork
-
You think it’d be a good idea – that’s assumptions (assumptions are cool but you gotta test and validate them)
-
Your trustees want it do that – that’s hijacking
-
Your dev team thinks it should – that could be technical bias
-
Your users say they want it – that’s poor user research
-
You want to add it because there’s time – you should use your resource to do more research or testing
Types of user needs
Everyone agrees there are two types of user needs:
- Functional – focused on tasks, e.g. “I want to check my eligibility for benefits
-
Emotional – more open – e.g. “I feel worried and need some reassurance”
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 actually are valid user needs.
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 its 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 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 direct 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 products 😉
Leave a Reply