https://dwpdigital.blog.gov.uk/2015/01/20/digital-academy-understanding-the-problem/

Digital Academy: Understanding the problem

Ben Holliday - Head of User Experience Design
Ben Holliday

At the start of a project in ‘Discovery’ your team’s job is to learn as much as possible about what your users need to do. Your goal is to understand the user needs for the service before you start to design or prioritise solutions.

Jon Kolko describes this process beautifully in his book ‘Well designed: How to use empathy to create products that people love’:

“Your job is to help your team ship the right product to your users. Your job is to figure out who your users are, what they want to be able to do, and what the right products are to help them do that.

You’ll need to spend time with the people who are going to use your product and watch them do whatever it is they do. Your goal is to both understand them and empathise with them.”

Understanding user needs is more about having a willingness to learn, than knowing what you’re doing. The important thing in ‘Discovery’ is to go and see things for yourself.

Depending on your job role, this might feel uncomfortable or put you in unfamiliar situations. This is all part of the learning opportunity to see things differently. Experiences like this help us to break away from existing assumptions about who our users are and what they need.

Try to involve your entire team in this process. If you do have a dedicated user researcher in your team they’ll be able to help you. If not, talk to your User Research team for advice.

Start with what happens now

You want to know what people need to do, so a good place to start is to find out what they do now.

When you’re working on a digital service, it’s rare that this will be solving a completely new problem. Start by looking at existing channels. For some services this might include telephony (phone services), a paper process, or face-to-face interactions with front-line staff.

Think about who your service is for. As you start to learn more about what these people need, you’ll begin to understand the details of what they do – where, when, and how frequently.

An example – Cold Weather Payments

An example project we use in the Digital Academy is Cold Weather Payments. This is where, if you’re getting certain benefits, you may get a Cold Weather Payment of £25 for each 7-day period of very cold weather between 1 November and 31 March.

We know that, broadly speaking, the people that benefit from this service are pensioners, and people that get income-related benefits. A good place to start would be to talk to the people in these groups. You could even start with your own friends and family if they get Cold Weather Payments.

We also know that we tell people on GOV.UK to contact their local Jobcentre Plus or pension centre if they have questions about Cold Weather Payments, for example, if they think they have a missing payment. We could start by talking to staff about the types of customers that contact them or arrange to listen to calls to understand the support and advice being provided. We could even call existing helplines to ask questions ‘as a customer’ so we can experience what it’s really like to use the service.

Any of these approaches should start to show us what happens now. For example, the policy intent for Cold Weather Payments is that people will be able to afford to put their heating on, but what if we found that most people spent the extra money on something else? Maybe people don’t know they’re getting Cold Weather Payments so don’t turn the heating on when the weather is cold because they don’t realise they can afford to.

With this type of insight we can start to understand that people have a need to know they’re getting Cold Weather Payments so they know they can afford to put the heating on and use this money for its intended purpose.

Make a research plan

It’s important to have a plan, but it’s equally important to keep planning to a minimum - don’t use this as an excuse not to get started because time is often limited at the start of projects.

Assume that, at least to start with, you’re probably going to ask the wrong questions and have incorrect assumptions about users - this is the whole point of ‘Discovery’.

Start by writing a short research plan. Keep this simple, but include:

  1.  a summary of what you want to learn (use bullet points for any key questions you need to answer)
  2.  a set of opened-ended questions you can use when talking to people (don’t include more than 10 questions – these should help you focus on what you want to learn, acting more as prompts, rather than like ‘survey’ questions).

When you talk to people, let the conversation flow rather than sticking rigidly to your plan. The most difficult skill to master is giving people the space to talk without interrupting them (this is harder than you think).

As you start to learn you’ll want to make adjustments to your initial set of questions, so don’t be afraid to do this as you go along.

Most importantly, make sure that you don’t ask people questions about their preferences – we’re interested in what they do, rather than their opinions.

Keep a record of what you learn

Find ways to record and keep a record of everything you’re learning. This will help you to share what you find with the rest of your team.

If you're working on your own try to take some notes. If you can work in a pair let someone else take notes while you ask questions.

Most importantly, take time out to write down key observations or quotes. It’s a good idea to use post-it notes so you can stick up observations in your project space to discuss with your team.

Don’t treat ‘Discovery’ as an exact science

At the ‘Discovery’ stage of a project we’re interested in empathy and understanding. It’s not about how much research you do, it’s about how well you understand the needs of your users. This way you’ll be better equipped to make difficult product decisions as you prioritise work to build your service.

Leave a comment

We only ask for your email address so we know you're a real person