Better discoveries

At GDS we work through four stages when we design and build services. Discovery is where you explore the problems you are going to solve. Alpha is where you prototype solutions that might work. Beta is where you take what works and turn it into a product with real users. Live is where you run the product for real.

Of these four stages, discovery is always the hardest to do well. Why?

The state of discovery today

We all know deep down that doing a proper discovery is important. You know those projects where you worked your arse off but had that creeping feeling throughout that you were doing the wrong thing? That's why it's important. Yes, it saves money and stuff as well, but deep down it's important to us not to waste our lives.

We also know that doing a proper discovery is surprisingly easy. At least if you compare this to building a product. It doesn't take very long. You don't need many people. And it's not technically difficult because you're not building anything.

Yet teams mangle discoveries. Discoveries are too short. Discoveries start without a user researcher. Discoveries dive straight into prototyping. Discoveries don't keep the human and technological aspects separate. Discoveries fail to highlight the most important of user needs which are screamingly apparent in their absence during later stages. Some discoveries simply never happen.

If it's important and easy to do, why is it so hard to do discovery well? I think it's because discovery is about leadership. And leadership can be terrifying. 

Management versus leadership

Brief digression. Peter Drucker has a great quote about leadership.

    'Management is doing things right; leadership is doing the right things'

I used to laugh at my old boss for drawing a distinction between management and leadership (sorry DJ!) but this quote makes me regret being so precocious. Peter Drucker's distinction is helpful in thinking about discovery. Here's why.

In the alpha, beta and live stages you are mostly concerned with doing things right. Your user research is about checking whether your solution works with the people who will use it and fixing problems that come up.

This is management territory.

People feel safe in management territory. The overall direction is set. It's relatively predictable where things are going. You think you know how much money you'll spend. And you dream you have some idea of how long things will take. This is familiar ground. This is normal work. This is business as usual. This is how the civil service mostly operates. It manages things that exist. It tries to do them right.

But discovery is different. Here you are concerned with doing the right things. You're hunting around for the right problems to tackle rather than coming up with solutions. Your user research is about digging into people's needs, tasks, motivations and goals rather than finding problems with your design. And you end up having to take a punt on a future direction. A informed gamble, but still a gamble.

This is leadership territory.

Many people don't feel safe in leadership territory. It can be terrifying for all involved:

• user researchers can be more comfortable finding problems with something that exists than making a bet on what to build.
• software teams can be more comfortable making things for the future rather than finding out how things are today.
• senior managers can be more comfortable planning in advance so they can allocate budget and people and resources.
• politicians can be more comfortable creating policies based on their political realities than working out what the constraints are.

This is why discovery is hard. It's not because the work is hard to do. It's because discovery is about leadership and this scares people. And when we're all scared, we're pretty good at silently conspiring to avoid the thing that scares us.

Better discovery

This has changed how I think about doing better discoveries.

It's not about describing the discovery work more clearly (although that helps). It's not about convincing people of the value of discovery (although we could do with more ammunition). And it's not about doing service assessments at the discovery stage (although it would be good to know that all projects at least had a discovery stage!).

Instead, if discovery scares people (it does) then we need to find ways to make a safe space for discoveries to happen. People produce better work when they are not scared. We need to stop putting pressure on discovery teams to validate pre-existing decisions. We need advocates for discovery at a senior level - not people that do the work but the people that set the right conditions - and this is one of the driving reasons behind creating lead user researchers on our programmes at GDS.

And if discovery is about leadership (it is) we need to start giving our most important discovery projects to our best leaders and teams. Too often we start discoveries with a cobbled-together team and only put a 'proper' team together for alpha and beta. We need to stop this because we are setting these teams up to fail at discovery. We need to wait for the right people to be ready to start discovery together. A few weeks here versus a couple of years of wasted effort further down the line. What's the rush?

In the end, discovery is hard because it's about leading our organisations into new futures that are not mapped out in advance. This is scary and it needs good leadership. But better discoveries lead to a better us. And we're worth it.

I wrote this post inspired by Ben Holliday's recent blog output. The question of why discovery is hard has been on my mind a lot in the last year, but these ideas are not fully formed so (as always) I welcome critique and questions at @myddelton.

Updates

• @mattedgar (who wrote good things about the culture of discovery) pointed out that we should continue to ask 'are we building the right thing?' through alpha and beta too. I have simplified here to make a point. But he is (of course) right.
• @jukesie reminded me that he wrote this post about decoding discovery which is well worth a read too.

Eight principles for user researchers on Government as a Platform

Reposted from my original post on the GDS blog.

We're working hard on Government as a Platform at GDS to make sure user researchers are doing the right job. We've had some problems figuring out what that job is at times.

So we've developed eight principles for how to be a user researcher on Government as a Platform.

1. Start with your team's needs

Everyone knows we start with user needs. Except we don't. We start with the needs of our team.

When we don't do this our research isn't useful to our team and they ignore it. There's nothing more pointless than doing research that no one listens to.

As soon as we start meeting the needs of our team they trust that we're here to make their lives easier. They listen to us. Then we switch to a relentless focus on user needs.

2. Use research questions

We do research in an agile environment. But the sprint cycle isn’t quite right for planning research. We need a way to plan our research and track our progress over time. We use research questions for this.

The first thing we do on any project is sit down with the whole team. We ask them what they want to know from the research. They come up with dozens of questions they want answers to. We organise these into a set of research questions that everyone agrees are important.

We use these questions to plan the research we need to do. Then we answer the questions.

3. Talk to users all the time

It is critical to always be doing research.

Without constant research we can't get our team the exposure hours they need with users. Or we turn up at research playbacks with nothing to show. Or we just don't get a proper feel for the problems our users have.

We all talk to users every single week. We do a mixture of telephone interviews, lab sessions, guerilla tests and site visits to make this easy.

4. Involve the whole team

The job of our user researchers is not to do user research but to help our teams understand what matters to users. When this happens the team does user-centred design without thinking about it.

Our whole team generates the research questions. Developers take notes in the lab. A non-researcher comes on every site visit. Everyone takes part in debriefs and playbacks. We ask the product team what they would change about the research to make it better.

It's easy to stop doing this. People are grumpy. Co-ordinating everyone takes work. You can do things faster yourself. But it's the single most important thing on this list.

5. Present one list of problems

Our research process generates a list of the top 10 problems for the team to work on. The team prioritises this list together every two weeks. Everything else we find goes into a research backlog, which we ignore.

This sounds radical and reductive but it means our team always knows what to work on. The beauty of agile is you don't have to address everything at once. The team solves the biggest problems and we come back and do it again in two weeks.

Our team are fantastic at solving problems. Our job is to make sure they are working on the ones that matter most to our users.

6. Maintain a research wall

The research wall is the centrepiece of our work. We use it to show four parts of our research that are critical to the team.

We show the interface and highlight the issues coming out of research in context. Our designers and developers constantly refer to the wall while working. It's powerful.

We show the list of the top 10 problems. Our product managers use this list to plan and track their ideas for solutions. Problems only leave the list if they disappear in the next round of research.

We show the research questions and our progress against them. Our researchers use this to plan research and decide which questions to ask when we meet users.

We show things that were problems that our team has now solved. This makes us feel good. It's important to feel good.

You might think our walls are decoration. You’d be wrong.

7. Document the research

OK. Now we get to the grunt work. Just because we work fast doesn't mean we don't document our work.

We document our research activities: what was it, who did it, when and where did it happen. We include notes, recordings and any materials.

We document our analysis sessions: photos of post-it groupings, frequency counts of important issues and lists of findings.

We document our research playbacks: the top 10 problems, the research backlog and any problems marked as solved this cycle.

And we document the ever-changing answers to the research questions in one big Google Doc that we add to over time.

I'm not going into all the reasons that documentation matters. It matters. And it doesn't take long if it's a habit, so we make it a habit.

8. Manage your contacts

More grunt work. Our users are service teams. We have to find and recruit them ourselves. This is a staggering amount of contact admin.

Let's look at GOV.UK Notify. We've spoken to more than 60 service teams in the last four months. We take each one from first contact, to telephone interview, to lab session, to site visit, to beta partner. Each stage involves scheduling activities. The people we talk to change. The services themselves change.

We need to be great at email, phone calls, calendars, room bookings and travel arrangements. We use Trello to manage our contacts and maintain a research pipeline. This is the foundation of all our work.

All eight principles are critical

Every user researcher on Government as a Platform does all eight of these things. Even the less glamorous ones. Especially the less glamorous ones.

There are lightweight ways to do all these things. We encourage these. But I want to be clear. We would rather slow the pace of the research on a project than stop doing a single one of these things. Because when we do these things the whole team has a laser focus on meeting the needs of our users. Not just for a sprint or two, but for the whole product lifecycle.

And that's what we are here to do. That's the right job.

Let me know what you think on @myddelton. Reposted from my original post on the GDS blog.