Learn more about this course.

User needs, personas and stories

Learn about user needs, personas and stories.

In this step, we will build on what we covered in our first course, by revisiting user needs and user stories. We will also introduce a new concept – user personas.

User needs – understanding the problem

Understanding what people actually need should always be the starting point for designing and building good products and services. There is little value in building a solution if you do not understand the problem you are trying to solve.

Want to keep
learning?

This content is taken from
Government Digital and Data online course,

User Research in Government: Developing Further

View Course

Let’s consider why people need to use government services. It is generally because they have a task or goal that they need to complete. For example, people frequently interact with government services for reasons such as:

renewing car tax
applying for a passport
looking for information about schools

We can express these tasks that users need to complete in a specific format, called a user need. This format is commonly used across multidisciplinary teams to help design and build usable, effective products and services. It helps everyone stay focused on what users are actually trying to do.

These tasks often arise from a specific problem or situation:

renewing car tax might reflect the need to drive legally
applying for a passport might relate to a need to travel abroad
looking for information about schools might reflect a need to make informed choices about education

Each of these can be expressed as a user need, which frames the task as clear statement of what someone is trying to achieve and why.

We write user needs in this format:

As a … [type of user]

I need to … [specific action or goal]

So that… [reason the action or goal matters]

For example, we could describe needing to renew car tax like this:

As a driver, I need to ensure my vehicle is compliant with current regulations, so that I avoid fines and can use my car without worry.

This shows what the user is trying to do and why it matters to them. You may notice that this user need does not actually mention paying car tax. This is because paying car tax is a solution that meets the fundamental user need, which is compliance with the law.

User needs should describe what the user needs to do, not how they might do it. They should be based on evidence gained through user research, not assumptions or guesses.

User personas

A user persona is a profile that represents the characteristics of a user group. A persona represents what a specific user group does, needs, and what barriers they may face.

As with user needs and user stories, user personas are developed through user research and interaction with users. Personas are created by identifying shared characteristics among users, and using those characteristics to create a profile that represents different groups.

Let’s use the example of car tax again.

People who need to renew their car tax are drivers of all ages and backgrounds who own cars. To build a service that will enable everyone to renew their car tax, user researchers need to talk to a representative range of people within this group.

Research should be conducted with a group of participants that reflects the diversity of all users who need to use the service. This means engaging with people of different genders, ages, and social backgrounds and including both disabled and non-disabled people. You also need to include people with different levels of confidence and ability when it comes to using technology and digital services.

Though there will be a huge amount of diversity among such a large group of users, subgroups can often be identified based on shared characteristics. To help teams design for these subgroups, user researchers often create personas – fictional characters that represent these users.

For example, one persona might be John, a pensioner who relies on his car for day-to-day tasks and who prefers to speak to someone over the phone or in person, because he is not confident in using a computer or smartphone. Another could be Jane, a young mother with a busy schedule of work and childcare, who uses a tablet and prefers to do things online to save time.

John and Jane are fictional characters, but they represent groups of users who share similar needs, behaviours, or characteristics. The team developing a service for renewing car tax can use personas like John and Jane (and any others the team identifies) to test assumptions and to understand and prioritise user needs.

Personas are not a replacement for engaging directly with users, but they are a valuable artefact that helps the team remember, communicate, and build on what they have learned. As user research continues, personas should evolve to reflect new insights and changing user needs. Personas are never static – even the most detailed user persona should be revisited as the team learns more.

We will learn more about user personas in step 1.7.

User stories – refining the problem

User stories are a way of describing potential solutions that aim to meet user needs.

User needs are high-level and broad in scope, and should never refer to solutions, so we break them down into user stories. A single user need can have multiple user stories, which may relate to different features, solutions, functionalities, or things that could be useful to people using the service.

It is good practice to ensure that user stories can be traced back to the original user need. This helps teams avoid becoming too focussed on a specific solution that may not actually meet that need.

As with user needs, user stories always come from consistent user research, not from guesswork.

User stories are generally written using the same format as user needs. This can sometimes be confusing for user researchers, but with experience, you will learn to tell the difference between them. As well as sometimes referring to solutions, user stories also contain additional information called acceptance criteria.

Acceptance criteria are things that must be true for the piece of work to be considered complete, normally written as a list of statements beginning with “it’s done when …”.
Every user story will have its own set of acceptance criteria. These should be decided before work begins, as this will allow the team to test whether or not the thing they are building meets the user need.

Let’s explore this using the car tax example. Our user need is:

“As a driver, I need to ensure my vehicle is compliant with current regulations, so that I can legally drive without incurring a penalty.

A user story for this could be:

“As a vehicle owner, I want to receive a reminder when my car tax is due, so I can renew it on time and avoid a fine.”

Some acceptance criteria for this could be:

the user receives a reminder at least two weeks before the tax expiry date
the reminder includes the vehicle registration number, expiry date and a link to the renewal service
the reminder includes instructions on what to do if the user no longer owns the vehicle

We will learn more about user stories in step 1.8 and introduce you to a new concept, jobs to be done, in step 1.9.

Task

Think of a public service you have used recently. This could be something like booking a doctor’s appointment, renewing a driving licence or registering to vote.

What task were you trying to achieve when you used this service? Try to identify a user need behind that service, then write a user story and acceptance criteria that could help meet that need.

Share your user needs with your fellow learners in the comments below.

Want to keep learning?

This content is taken from Government Digital and Data online course

User Research in Government: Developing Further

View Course

See other articles from this course

This article is from the free online

User Research in Government: Developing Further

Created by

Join Now

Learn more about this course.