Originally published on the GDS User Research Blog
Here are some things you should know about doing user research in the discovery phase.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.