Category: research

Originally published on the GDS User Research Blog

‘Start with user needs’ is the first of our design principles and it’s the first thing we ask teams to demonstrate to meet the Digital by Default Service Assessment. Even Members of Parliament (video) talk about user needs these days. This is all good.

But what does it actually mean to understand user needs? How do we do it right?

Observe and talk to end users

Do user research to observe and talk to users. Understand what people are really trying to do, and the real problems they have trying to get something done. That will show you what their needs are.

Needs can be functional and emotional

Needs can be functional things people need to do, for example, to check eligibility. Needs can also be emotional, perhaps people are stressed and anxious and they need reassurance.

Both of these types of needs are important to understand if you want to design services that are so good people choose to use them, and are able to use them without assistance.

There’s no substitute for talking to real users

You need to go to the source – to the user, and discover (not just validate) the user needs.

You may get some user needs from stakeholders, but you won’t get them all. You can’t even guarantee to get the most important user needs from stakeholders.

Some of our colleagues might be service users, but at the very least we tend to know far too much about government and technology to accurately represent ‘typical’ end users.

Treat ‘user needs’ from stakeholders as assumptions

You are not your user and you cannot think like a user unless you’re meeting users regularly.

Our delivery teams and various stakeholders never accurately represent our end users. Not even when our end users are civil servants. Treat any user needs you get from stakeholders as assumptions.

Get out into the field

In the discovery phase of your project, your team should be out in the field doing user research. You should be discovering what your end users are doing when they encounter your service.

This let’s you make sure that your service is a verb – a thing that supports a task that people are trying to do, not a noun – the thing you’ve always called the form before.

Understanding user needs saves money

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.

And it also just makes the world a better place. That’s good too.

Originally published on the GDS User Research Blog

Here are some things you should know about doing user research in the discovery phase.

1. You should definitely do user research in the discovery phase.Understanding who your users are and what’s going on when they come across your service is one of the most important parts of discovery. Have an experienced user researcher in your discovery team. Plan for the rest of the team to spend plenty of time going out into the field to meet real users with the user researcher.
2. Discover people not projects. If you want to deliver a service that really meets user needs, you need to understand what people are trying to do, and how they’re trying to do it, when they encounter your service. This means that research during discovery might seem ‘bigger’ than it needs to be for your specific project. This is because you’ve got a bunch of preconceived ideas about what your project should be. This is exactly why we do user research: to find out what people are doing now to solve their problem, understand what needs they have, and to understand how we can best help meet those needs. Then it’s time to work out what the project should be.
3. Discovery is for discovering, not for prototyping. Making is an excellent way to learn about a problem, but that doesn’t mean you need to make from the very beginning. Put the code away for a few weeks, get out into the field, and understand your users. Understand how different they are from you and your team. Spend some time doing this at the outset of the project, and it’s much more likely that the thing you make will meet everyone’s needs and not just yours.
4. If you haven’t discovered you were wrong about some things, you probably haven’t done it right. Discovery is not for validation. The point of research during discovery is to work out what people need, and what you need to do to meet those needs. It’s not to prove that a project should proceed. If you set out to validate, you won’t learn what you don’t know. What you don’t know is the thing that will ultimately make your project fail. It’s fine to have some hypotheses about what the project will be, but go into discovery to test those hypotheses, not to validate assumptions. The way you frame the user research in discovery will make all the difference.
5. Do qualitative, contextual user research in discovery. Try to meet at least 6-8 people of each ‘type’ of user of your service. (Your user researcher will help you understand what ‘types’ there might be and which ones matter). Go to the place your users are currently doing the thing you’re going to make better, and get them to show you how it works, what it looks like, how it makes them feel (user needs are both functional and emotional). Don’t ‘outsource’ this and get a report and a presentation at the end – bring the team along to observe the user research – everyone should see at least 2 interviews.
6. Maps and stories are good things to make with user research in discovery. Lots of teams have found that making maps of the journey that people go through (in doing the thing they need to do when they encounter your service) can be useful. It’s also important to try to capture the stories of the people you meet, what they’re doing and what their needs of the service are. There is no one right way to do this – talk to other people who have tried different things to get inspiration (being part of the cross government user research community is a great way to do this).

Doing user research to understand your users will help make sure you design the right thing, before you start worrying about designing it the right way.

Originally published on the  GDS User Research Blog

More and more teams across government are putting user needs first and the demand for user researchers is high. In some parts of government, people who haven’t had any experience doing user research have now taken on this role. If you’re one of those people, this blog post is for you, and for your managers.

Welcome aboard

The first thing to say is, welcome aboard! Many of us think that doing user research is a rewarding career.

It’s exciting to see the user research capability within government growing and maturing, and we hope you’ll help us shape it in the future.

More to it than meets the eye

User research may seem pretty straight forward – find some people and ask them what they think. How hard can it be?

As with most things, you’ll find there’s much more to it than first meets the eye. Being a good user researcher is a craft, there’s much to learn and it takes plenty of practice.

Many of the researchers in my team have more than 15 years user research experience. They’ll be the first to say: “There are still things I’d like to be better at.” We’re all still learning,  everyday.

So, get stuck into learning your new craft with vigour. Don’t simply do what the person in charge of your project tells you to do. Very often, they  don’t know much more about user research than you do.

Here are some tips to help you get up to speed as quickly as possible so you can bring the real value of user research to your team.

Things you should read

If you’re new to user research, there are lots of quick, easy-to-read books that’ll get you off to a great start.

The essentials

Steve Krug wrote two books that every user researcher should almost know by heart.

• Don’t Make Me Think (give it to everyone in your team)
• Rocket Surgery Made Easy (about usability testing)

Read a couple of these…

Choose one of these books as a good and fast introduction to how to approach user research in projects. They’re both great books.

• UX for Lean Start Ups by Laura Klein
• Just Enough Research by Erika Hall

These books will help you with the all-important techniques for facilitating user research sessions. You should read at least one of these.

• Interviewing Users by Steve Portigal
• The Moderators Survival Guide by Donna Tedesco and Fiona Tranquada
• Interviewing for Research by Andrew Travers

Invest in these books…

A bit more of an investment in terms of time and money, but these books will give you a really thorough insight into how good user-centred design should happen.

• Designing for the Digital Age by Kim Goodwin
• About Face: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin and Christopher Noessel

Every user researcher worth their salt has also read…

The Design of Everyday Things by Don Norman. You’ll never see the world in quite the same way again.

Things we’ve written – you should read these too

There’s a lot of useful guidance on the GOV.UK Service Manual.

Plus, some blog posts you should make sure you’ve read:

• User research for govt: 8 strategies that worked for us
• Doodles on why doing user research in the right place matters
• Anatomy of a good sticky note
• 6 case studies: using research and data to improve a live service
• Sample size and confidence – how to get your team to trust qualitative research
• Including people with low digital skills in user research
• User research not just usability
• How we do research analysis in agile projects
• It’s user research, not user testing

There’s your ‘homework’. It’s a great place to start, but there’s more you can do.

Find your tribe

There’s an active community of user researchers in the UK government. We talk on email and we get together at meetups where we learn stuff, do show and tells, ask questions and share knowledge. Everyone learns as a result. If you’re doing user research within the UK government, you should join the community.

Find a mentor, apprentice yourself

Make sure you work with someone who’s an experienced user researcher.  This will make the biggest difference to your progress.

Ideally, your organisation will only hire people with no experience if they already have people who have lots of experience and who can mentor and support you.

Sometimes you do find yourself without much support. If that happens, there are two things you should do:

1. Ask the organisation to hire an experienced user researcher. Even hiring an experienced contractor to work with you for a few months will make an enormous difference in your ability to develop as a user researcher. If you can get someone like this on the team, spend as much time with them as possible. Watch what they do, have them watch you and give feedback, ask them lots of questions about what you’re thinking of doing and why they’re doing what they’re doing. Be like a sponge.
2. If you can’t get someone with user research experience into the organisation, use the network to find someone else in government to mentor you. We’re a pretty friendly bunch who want people to do well, and do user research well. Ask a good user researcher if you can shadow them a few days each month, and if they can visit you and give you feedback on what you’re doing.

We actually encourage all user researchers – even the experienced ones – to spend 2 hours every 6 weeks watching other researchers or being watched. The best thing you can do is find a mentor to work closely with you. You might want to use the government user research community to do that.

Training is a good starting point

Doing a training course is usually the first thing that people think about. Training is good, but it’s just a starting point, it doesn’t mean you’re really equipped to take on the role without support.

 

You don’t have to be the expert on users

Probably the most important thing to remember is that it’s not your job to be the expert on users. Rather, it’s your job to know the techniques that will allow your entire team to become expert in what users need – and need us to do – so they can easily interact with government. User research is a team sport.

And last but not least, enjoy!