Better discoveries with the discovery block diagram

This is the story of how a simple diagram changed how I think about discovery.

Late last year, one of our teams was finishing a discovery. The team had done loads of work and found out lots of good stuff. But their user needs were too enmeshed with the technical solutions being explored.

Nervously, I suggested that the discovery wasn’t finished. I offered to help them rework the output to reflect the quality of their work. But the truth was that I had no idea what a good discovery output looked like.

I asked for help. Our head of user research, John Waterworth, drew something on the whiteboard that I’ll never forget. I call it the discovery block diagram:

This is a diagram of what your discovery output should look like. This diagram, more than anything else, has helped us do better discoveries on Government as a Platform.

Let me talk you through the diagram and explain why it works.

Context: outline the background

In the context you outline the background to your discovery. You might include:

Where the idea for the discovery came from
Who the different user groups are in this space
What’s going on with technology and social trends
What other organisations are doing in this area
What unresolved problems you think there might be

Include whatever makes sense to you. Keep it high level though. List things, don’t describe them in detail. The point is to acknowledge the broad context before you focus on a more specific problem.

Starting with the context, rather than the specific problem, helps you be clear that you have chosen one specific problem over others. It helps decision makers outside your team ask sensible questions about what you are doing and why you’re doing it.

Problem: define your focus

In the problem you state clearly which bit of the context your discovery focused on.

For example, your context will often contain different user groups doing lots of tasks. Your problem might narrow this to one or two specific user groups doing a few named tasks. Without this narrower focus you won’t be able to understand the problem well enough to make the decision you need to make at the end of discovery.

Being clear about your problem shows that there were other problems you could have chosen instead. It removes the air of inevitability, which is rarely helpful, from your work. Again, it helps decision makers understand your choices so they can ask good questions later.

Areas of investigation: show what you learned

In the areas of investigation you divide up the problem into different workstreams and talk about what you found in each one. Separately.

Our work at GDS pretty much always has one area for users and needs, another for technology and data, and a final one on policy and legislation. Sometimes we have an area around design and content too. You might have more areas. Your areas might be different. It depends on the problem you're looking at.

Keep these areas separate though. Don’t mix what you know about users with technology or policy at this point. Give each area the space to tell its own story, and the freedom to come up with its own findings.

This keeps you focused on what you found out. It leaves space for divergent opinions and contradictory facts. This is what a good discovery is all about.

Findings: bring it all together

In the findings you bring the most important things you’ve learned in one place. It’s not about making a huge list of everything you’ve learned. No one wants to see that.

Don’t include too many findings. Any more than 15 will lose your audience. This is about the things that matter most to the problem you looked at. It’s important that your team has an opinion on this.
Don’t go into too much detail. You’ve already gone through the detail in the areas of investigation. Your findings build on this. My advice is to express your findings as bold, standalone, single sentence statements.
Don’t split by areas of investigation. The findings are powerful because they triangulate the things you found across your areas of investigation. You’ve already worked through the different areas.
Don’t ignore your alpha ideas. Your findings are the link between the detailed work you have done and your speculative ideas for potential alphas. The link between the two should be clear.

The best way to think about this is to imagine you’re presenting your work to your chief executive. She doesn’t have time to hear the detail. She barely has time to hear 15 single-sentence findings. Make it count.

Alpha ideas: show the way forward

In the alpha ideas you sell solutions to the problems evident in your findings. You’ve taken your audience on the journey from context to problem to investigation to findings and now they’re ready for ideas.

You might have one big alpha idea you want to pursue. Paint a compelling vision for it and show how it addresses findings. Remember it doesn’t have to address them all. Or you might have a bunch of smaller alpha ideas and want help in deciding which one to do. Outline each idea, show which findings it addresses, talk about tradeoffs.

Whatever your approach, you should probably cost your alphas and model their benefits. People are going to ask those questions. Be ready.

But...discovery is still messy underneath

The discovery block diagram makes discovery look straightforward. This is, of course, a lie. Discoveries are messy and full of ambiguities.

Choosing the right problem is messy. Your team won’t agree on which parts of the context matter. You’ll want to change the problem once you’ve started. It’s OK. You’re allowed to refine your problem all the way through your discovery.
Getting the team to agree findings is messy. It’s hard to boil the things you’ve found into the 15 most important findings. You’ll need time and space to do this. It helps if you’ve been working together throughout.
Defining alphas is messy. Most of the team have secret ideas about how to solve the problems. Some will be deeply attached to these. You need a design process to surface these ideas and resolve them into coherent, practical alphas.
Ending the discovery is messy. John Waterworth says that a discovery is done only when the team agrees it’s done. That’s a challenge when you have an external deadline but it’s this that you should be aiming for.

So, yes, discoveries are messy and full of ambiguity. The discovery block model doesn’t change that. It just gives us a clear idea of what we need to end up with. It’s always helpful to start with the end in mind.

This diagram helps us think about discovery

I wanted to tell you about the discovery block diagram because the best diagrams help us think more clearly about complex things. That’s what the discovery block diagram does for teams doing discovery.

It helps you turn your discovery into a compelling story with a beginning, a middle, and an end. It helps you plan your work without telling you how to do the work. It opens your messy, chaotic, ambiguous discovery work to inspection and critique from your colleagues and decision makers.

Since John drew the discovery block diagram on that whiteboard we’ve done four discoveries on Government as a Platform. Each one started with a conversation about how to get to this output. We’ve seen the quality of our discovery work improve dramatically as a result. Give it a go.

This post is one of three posts about how to run better discoveries. The other two are setting up a discovery to succeed with a small team and finishing off a discovery to do justice to your work. Let me know what you think on @myddelton.