User needs 101

Trying to learn about user needs but don’t know where to start? Then this is the post for you.

What are user needs?

The one line definition of ‘user needs’ I tend to give is:

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

People smarter than me have written about user needs in detail.

Rather than duplicate their efforts, the following is a step-by-step guide linking to their work.


Step-by-step guide to understanding user needs

Here I have linked to posts and writing about user needs that I have pointed people to time after time.

I encourage you to read them all (and in the order provided) to help you understand this fundamental concept of user centred design.

  1. First read Learning about users and their needs – from the UK government service manual. It gives a brief introduction to what user needs are and why you should seek to satisfy user needs in the design of your service or product.

  2. Next see Ben Holliday's approach to understanding different types of user need – this should give you a more rounded view of what they are.

    This is important because as Ben says, user research should be used to understand real life stages and context, not only the needs that IT projects or existing products create.

  3. Armed with an understanding of the different types of user need, read Pete Gale's post: How we talk about user needs.

    Acknowledging the origin of a particular need can help you to keep in mind what your users are really trying to do and what is the result of service design itself.

  4. Hopefully by this point what user needs actually are, is reasonably clear to you as well as why service design tends to start with user needs.

    Now I encourage you to read Will Myddelton's Useful Heresy number 1 'User needs' is a harmful concept for training researchers which is an excellent examination of the user needs concept, why its difficult to grasp and why it is more than a set of neatly organised user stories.


Writing user needs

By now you will have seen that most often user needs are written as a statement from the user’s perspective. Below is an annotated user need statement.

The user As a British person

Their need: I need to provide proof of my identity and visa permissions to border control

Why the need exists: So that I can travel abroad

The test of a good user need

When writing user needs, this advice from Leisa Reichelt (adapted by Ben Holliday and my former team at DWP Digital) is helpful to keep in mind:

  1. If you showed it to a user, would they recognise it as their need?
  2. Is it written with words real users use?
  3. Does it describe the problem rather than the solution?
  4. Will it stay the same regardless of changes to technology, policy and existing services?
  5. Does it help you organise and prioritise work?

More often than not I have found if a user need statement satisfies these tests it will be what what Pete Gale talks about as an ‘expressed user need’.

Meeting expressed user needs is generally what makes the difference between a service being able to deliver underlying policy intent or business objectives.


Working with user needs

Doing research by talking to and observing users is incredibly energising, builds trust and gives your team genuine insight into what people are doing and why they are doing it.

You should then be able write down what you believe are the needs of your users in the form of user need statements.

Now what?

Now, more research, design, ideation and creativity comes in. Now you do the work to test that your understanding of your users and their needs is correct or not.

The needs you have identified and written down are the foundation of what you need to achieve.

Adding measures

It is important to understand what it looks like when you have successfully met the needs people have with your service.

The first thing I suggest you do as a team is to break down user needs and think about what must happen or be true for a user need to be met?

You can write them a little like clauses in a contract.

Some needs will only have one clause and other needs will have multiple clauses. To explain what I mean let’s look at the previous example:

The user As a British person

Their need: I need to provide proof of my identity and visa permissions to border control

Why the need exists: So that I can travel abroad

Satisfaction clauses: This need has been met when:

  • I understand what a passport is and why I need it
  • Where, when and how to apply for a passport
  • I know what a visa is, if I need one, how to obtain it and when

These are what will help your team decide what possible solutions will best satisfy the need. Quite often satisfaction clauses become design questions for the team, for example:

How might we:

  • help people to understand what a passport is and why they need it
  • help people to know how and when to apply for a passport
  • help people to know what a visa is, when they need to obtain one and how to obtain one for their destination

Hopefully it is then easy to see how these design questions should be the starting point for user research and for the team to then try multiple different theories about how best to answer the question (solve the problem).

Examples of user needs and their metrics

One lovely thing about GOV.UK you might not be aware of is that user needs for many sections and services of the site are publicly accessible via a dedicated URL for example:


A spreadsheet to capture user needs

At the time of writing, during the global pandemic. Large whiteboards and physical wall space are less applicable than they were.

So I am sharing a User needs capture sheet I have pieced together over recent years for teams to collaborate and share user needs with each other.

A screenshot of the first three columns from the sheet, showing as a

It is made up of columns which will form a user need statement. It also has columns for classifying the type of need it is.

The measures (it’s done when the user knows or can…) have some columns for narrative and finally there are some columns for noting where the need was seen, to help people remember the research or data that it was prompted by.

To update the dropdown lists, you can edit the ‘data’ sheet. For example if you want to change the list of users to choose from. Edit the cells in column ‘A’.

There are lots of ways to capture research and document user needs, this just happens to one I like best. I find it easier to get my head around needs written and organised like this but whatever works for you and your team is fine.

I’ve seen Trello boards which roughly follow this structure, each card is a need in a column and that allows comments on each need and the ability to attach links and documents.


Summary

Hopefully this guide has helped you understand the concept and value of user needs.

User needs are the foundation of building a successful service because as Leisa points out

Understanding user needs enables better service design which results in greater digital take up, higher compliance, more effective policy outcomes, fewer user errors and inaccuracies, reduced failure demand and, overall, makes your service better value and cheaper to run.

If having read this and the links I’ve shared, you can you look at the work of your team and spot what is, and importantly, what isn’t a user need then you are in a great position help your team do it’s best work.