Service design starts with user needs
Understanding different types of user needs when designing products and services
It’s important to start with user needs, but I’ve found it’s not always clear what we mean by user needs.
I’ve seen teams getting stuck with what I can only describe as a narrow focus or understanding of user needs for the services they’re working on.
Functional and emotional needs
I like to think about two different types of ‘needs’ when designing public services (this distinction was first made by Leisa Reichelt here):
1. Functional needs
Functional needs are the practical things that people need to do as part of a product or service.
2. Emotional needs
Emotional needs are the result of someone facing a situation in their lives. It might make them feel stressed or anxious. They might need peace of mind or to feel confident about something.
Both types of needs are closely related but they’re also very different things.
For example, finding a job is practical (functional), but the fear of getting sick and losing your job is emotional.
Emotional needs can be very simple despite being the result of complex situations or problems. I always use this example: the welfare state in the UK was founded to meet an emotional need – that people would no longer have to fear becoming sick or unemployed. It’s something that’s been primarily built on meeting an emotional need, through a system of care at the point of contact and (conditional) financial support.
Paying tax is another good example. This is a scary thing to deal with for many people, especially when it coincides with major life events. You might remember the feeling of anxiety that a letter from HMRC (the UK tax system) can cause, with the doubts about what might happen if you don’t do the right thing at the right time.
User needs are about understanding the problem space, not a solution space
In service design, user research should be used to understand real life stages and context, not user needs that IT projects or existing products create.
In this illustration emotional needs are more open, and practical (functional) needs are more focused. This focus is the result of constraints.
Emotional needs are about understanding life stages or the things that happen in people’s lives.
This emotional space is where we learn more about the significant events, both planned and unplanned, that people experience and have to deal with in their lives. For example, planning for retirement, or going through a bereavement.
When we better understand life stages and context we can then move onto understanding things that people have to do. For example, if you’re planning for retirement you will have to check your State Pension at some stage.
An emotional need is never something that people have to do.
It’s easy to conflate needs with design decisions and constraints that mean people have to do something. For example, proving your address, verifying who you are, or applying for something are all things that we make people do, not what people need to do.
An example: retirement
Retirement is a life event that many people are anxious about and put off doing anything about. It starts with an emotional need. For many people this is knowing that you haven’t planned or saved for the future and the worry that you feel when you think about it.
If we start by understanding this need then we can practically help people to do something.
Check your State Pension is a government service that meets a functional need. It lets people take a practical step towards planning for retirement by showing them what their pension is worth and when they can get it.
Functional needs exist within constraints. There is only a need to check your State Pension because the State Pension exists. It’s a government policy designed to meet the need people have to retire, or to help them make adjustments to their working lives as they get older. If this government policy was to change then so would the functional needs in this space.
When a user need is functional we accept a set of constraints that tell us how the world we’re working in must work. The problem space is clearly defined.
In this example, we accept that most people retire by claiming a State Pension along with any private savings and investments they’ve made (we accept that this is how retirement works).
Imagining the alternative
Understanding emotional needs can help us redefine what functional needs might look like in the future.
Emotional needs are less liable to change because of a policy intent or business model. By understanding life stages and context we can create the space we need to imagine alternatives to how things must work, moving our focus to how things could work.
Thinking back to retirement, it’s okay to accept the practical constraints of how the pensions system works today. The problem is what happens next. Eventually you have to be able to rethink policy to meet the changing expectations of society or the market you’re delivering services for.
User research to develop a deep understanding of life stages, context and emotional needs is where we can start to think about an alternate vision for future services. It’s the space where it’s possible to reinvent things or to find a new set of constraints to work with.
Oversimplifying
I’ve noticed that a common argument against user-centred design is that it oversimplifies inherently complex solutions, systems, processes, and enterprise-level technology.
I think that this misses the point of designing for people.
Emotion does oversimplify things. It’s how people navigate their way through life.
For example, the difference between feeling secure and being afraid is very simple. If you feel afraid then you don’t feel secure. The complexity of the situation you find yourself in when you’re afraid is different.
Sometimes we need to be able to cut through complexity, and emotional needs are a way of focussing on what’s really important to people.
Design is about emotion. Its ability to simplify a view of the world is an important way of dealing with and navigating complexity in service design.
There’s never a perfect framework
I’m not the first person to try to explain different types of user needs. It’s important to always remember that asking good questions, and constantly questioning things, is better than finding the perfect framework.
I always encourage teams to explain, understand and capture user needs in whatever way enables them to build the best possible service for people.
Next step: test your user needs
When you’ve captured a set of user needs, Leisa’s checklist is a good place to start the next step – testing them.
The test of a good user need (adapted):
- If you showed it to a user, would they recognise it as their need?
- Is it written with words real users use?
- Does it describe the problem rather than the solution?
- Will it stay the same regardless of changes to technology, policy and existing services?
- Does it help you organise and prioritise work?
We’ve made this into a poster for teams (download).
Examples of good and bad user needs
Here are some examples of good and bad ways to capture user needs.
Good: Need to know if I can or can’t go to the UK –Bad: Need to complete an application and send documentary evidence of my eligibility.
Good: Need to know exactly what I can and can’ do while here, so I’m not thrown out of the country – Bad: Need to read latest guidance on policy changes.
This blog post is taken from material that was part of a Leading Service Design workshop with Kate Tarling (workshop slide deck). It’s also published on Medium.
This is my blog where I’ve been writing for 20 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky and LinkedIn.