What, So What, Now What explains how the user research process is about going from observations to findings to actions. Step-by-step. In that order.Read More
I’m a lead user researcher at GDS. My job is to support our user researchers in helping their teams make better products. This means I think a lot about the relationship our product teams have with user research.
Over the last two years I’ve stumbled into a useful model for talking about this relationship with researchers and their teams. The model helps them understand what to expect from each other, recognise and support each others’ strengths, and work together to make better products.
The model? There are three types of user research product teams should care about:
- Testing things the team have built
- Working out what the team should build next
- Understanding potential users and their lives
Not revolutionary. Not innovative. Just helpful in doing the trickier parts of my job. Like adding a new user researcher to a team, making the role of our user researchers clear, and helping our teams get value from research.
1. Testing things the team have built
For many people, doing usability testing on existing software is all there is to user research. It is the easiest type of user research to grasp. So this is where we start.
The benefits are clear. It helps find and fix problems before you release software to the world. It is easy to get started for researchers (easy to learn) and for teams (easy to prepare to do). It fits neatly with agile because you can slot it into every sprint.
The problem is harder to see. Building software costs lots of money. Even in agile. This sunk cost makes it hard to tackle the big problems hard-coded in architectural decisions. This limits the scope of designers to make necessary changes. At its worst, teams make tiny, insignificant changes and ignore the bigger, more important stuff.
User researchers and their teams must be alert to this. If big problems are showing up in testing, teams should be spending more of their research effort on working out what the team should build next...
2. Working out what the team should build next
Research can help you figure out what to build before you start building. This mostly involves interviewing users about specific tasks and watching them use prototypes.
The benefits are strong. You understand the big architectural choices before sinking money into building them. You empower designers by giving them space to explore multiple options and do rapid iterations. This leads to huge progress, quickly.
There are two problems that block teams from doing this well:
- At one extreme, teams avoid this work. Maybe because it doesn’t fit neatly with agile. Or because they won't invest their developers' time in prototyping.
- At the other extreme, teams get stuck doing too much prototyping. They want all the answers before they build. Prototypes can never give you all the answers.
This is the hardest research to get right. You must balance doing too little (too risky) against doing too much (too slow). You have to work closely with designers, technologists and product managers. There is an art to this.
Although it’s the hardest research to do right, it’s not the most harmful to get wrong. That dubious honour falls to not understanding potential users and their lives...
3. Understanding potential users and their lives
Understanding people that might use your product (not just current users) is about listening to their stories and observing their daily lives. Away from your product.
The benefit is ensuring you have a workable proposition. This research can trigger innovative ideas, establish whether a market exists, and even help you pivot to new users when you need to. It’s worth saying that the findings from this last a long time too. People’s lives don’t change as fast as your product. This is worth doing well.
The problem is that many teams don’t value this work. Early on, they’re sure their assumptions are right. Later, they’d rather avoid knowing their assumptions were wrong. They say this work is a waste of time because it doesn't focus on the product or lead to immediate action. This work doesn't fit neatly into sprints, either, and things that are hard to manage often get ignored.
Let's be honest though. User researchers can get too fascinated by people and their lives. We sometimes get lost in this work for its own sake. Maybe some complaints about this work being a waste of time are not baseless. We should think on that.
Whatever, the most frustrating thing about my career has been watching teams of talented people working on things with flawed propositions. User research doesn’t have all the answers, no, but remaining unaware of hard truths about people and their lives is a pretty reliable way to undermine your product.
OK. That's the model. As Simon Wardley would say, all models are wrong, but some are useful. Here are three ways this model is useful to me.
Adding a new user researcher to a team
Talking about these three types of user research is useful when a new user researcher joins a team. This happens a lot in my job.
- If the team is starting a new thing, focus the user research on understanding potential users and their lives. No discovery should be building protoytypes, let alone working software, so there's no choice but to start here.
- If the team is underway but doesn't appreciate user-centred design, focus the user research on testing things the team has built. All teams grasp this and it’s a great way to build the trust you will need later.
- If the team is up and running smoothly with user-centred design, focus the user research on working out what to build next. In mature teams with good propositions, the biggest value that research can bring is to find the riskiest thing on the roadmap and work on that with the designer and product manager.
It’s helpful to have this clear focus when you join a team. Over time the researcher’s job is to expand to cover all three types of user research.
Making the role of our user researchers clear
I tell our user researchers that their job is to make sure that all three types of research are being done by their teams (except in discovery of course). Framing the role like this gives our researchers plenty of freedom to come up with their own approaches to their work. This has worked out well for us.
Beyond that I don’t much care what methods they use or how often they do research. I want to hear how they are balancing the three types of research on their team and whether their teams are blocking any of the three types. This is a good conversation.
Researchers tend to prefer one of the three types. Some are most comfortable testing, some love getting in there with designers and prototypes, and others just want to explore the wide open spaces of people and their lives. It's fine to have a preference, but I expect researchers in product teams to do all three well. So the three types are a useful tool for conversations about professional development too.
Helping our teams get value from research
Finally, talking about these three types of user research lets me have better conversations with product teams about how user research can solve their problems.
- Some teams get obsessed with building things above all else. This can be costly as they’re not using design to de-risk development properly. I’ll ask them to slow down and go back to working out what to build next.
- Other teams get paralysed working out what to build. This can be costly as they're wasting too much time on certainty. We are gamblers, not scientists. I’ll push them to take a punt so they can start testing things the team has built.
- We’ve all been on teams with a flawed proposition. This is not only costly but also emotionally difficult. I think of James Baldwin, who said “not everything that is faced can be changed, but nothing can be changed until it is faced”. I think of Rebecca Solnit, who said “we prefer ugly scenarios to the pure unknown”. Then I’ll try and help teams face the unknown by understanding users and their lives.
These are difficult conversations to have. Honestly, I've not always been successful in having them. But it helps me, in these conversations, to have a model of the value that user research brings to our product teams.
Sharing this model with you
I have thought long and hard about sharing this model. Leisa Reichelt, who I admire more than any other user researcher in the world, flatly told me that we didn’t need yet another way to talk about user research when I shared it with her six months ago. So I went away and wrote about discoveries instead. Thank you Leisa.
But I haven’t been able to let this go. On my good days I think this is because it’s a model with universal applicability. On my bad days I worry that it’s because - like all designers - I’ve fallen in love with my own idea.
All I know now is that it’s been useful to me. Maybe it will be useful to you too.
Let me know what you think on @myddelton. One final thing. You may be wondering what is wrong with discovery, alpha, beta, live as a model. The problem is people end up equating each stage with a type of research. Given that teams spend most of their time in beta and live, it's harmful to think they should only be doing usability testing...
For my end-year review one of our user researchers asked me to talk more openly about the mistakes I’d made throughout my career. She said it was important for senior people to show that they didn’t have all the answers.
I loved this feedback. It struck a chord with me for another reason too.
I’m about to leave GDS to go and work for the Home Office. I’ve been wondering how to mark this change. So over the last week I’ve been giving this talk to say goodbye.
My GDS best bits
Even at my most open and vulnerable I can’t just post up my mistakes! I’m human after all. So here are the five things I’m most proud of from my time at GDS.
- Working as a user researcher on GOV.UK Notify
When I joined GDS I spent four months working on GOV.UK Notify as a proper user researcher. It was the first time I’d ever worked on an agile product team. I loved it. It taught me a huge amount in a short time.
- Helping GDS think about service teams as users
I stood up in front of hundreds at an all-staff and talked about the idea that civil servants were our users. It was terrifying. I said difficult things. But people listened. That’s when I fell in love with GDS.
- Understanding the user needs of service teams
Given civil servants were our users we needed to understand their needs better. We interviewed 150 teams from huge online services to tiny offline transactions. This work changed how we think about our users.
- Exploring the biggest unmet need of service teams
Three things are common to all services - publishing to all (GOV.UK), talking to individuals (GOV.UK Notify) and collecting information (unmet). We ran the Submit discovery to look at collecting information. It’s the best work I’ve ever done.
- Building a team of user researchers
The reason it’s OK for me to leave GDS is the team of researchers we built. We took risks and hired non-seniors. We trusted and supported them. Now they’re flying on their own. Could. Not. Be. More. Proud.
My biggest mistakes at GDS
Now that’s all out of the way let’s get down to these mistakes.
#1. Ignoring hypothesis-driven design for too long
I’ve always thought in terms of research questions. I was wary of hypothesis-driven design because I worried that hypotheses are ‘validated’ or ‘falsified’ with too little attention paid to the details. But I’ve learned that hypotheses are a great way to link problem-oriented researchers with solution-oriented designers and developers.
#2. Failing to write up my most important research
After interviewing 150 service teams we presented our results. We got a lot of people excited. We took that momentum and carried it into a discovery. But what I failed to do was stop and take the time to write up those results for others to read later. I get requests pretty much weekly for the write-up. It’s still on my to do list. Huge mistake.
#3. Holding alpha workshops when I wasn’t ready
At the end of our Submit discovery we held design workshops with people from across GDS. We wanted to use their creative thinking to widen our alpha pool. But I wasn’t ready to hold these workshops. Instead of cancelling, I went ahead and ended up talking at these talented people for three hours. Wasting their time. Horrible.
#4. Leaving the Submit team after discovery ended
This one is hard to admit. On the Submit discovery I was the product manager on top of my normal role as lead user researcher. We finished with huge team momentum. But I decided to walk away and go back to my normal job - for good reasons - and I became part of the reason that momentum was lost. Momentum is a precious thing.
#5. Forcing researchers to recruit participants
Civil servants are our users. We can’t recruit using agencies. We can’t pay incentives. The best answer two years ago was to recruit people ourselves. But I failed to tackle this at a structural level. Now our 10 researchers spend too much time recruiting participants. I was scared of the size of the problem to solve. That’s a poor excuse.
#6. Doubling up our researchers without thinking
I introduced a senior and non-senior researcher to some teams. A move that let us recruit juniors, open career progression, respond to new projects, and be resilient when people left. But I didn’t think about how our researchers would get on with each other or split work between them. We’re humans. Humans are complicated.
#7. Failing to record sick leave and annual leave
This one sounds like a little mistake but was a huge one. I pride myself on being a good manager. But I didn’t always log sick leave and annual leave properly for the people I managed. Knowing what I now know, this is unfair to the people I managed and undermines much of my other good work. I’m never making this mistake again.
#8. Talking down the work of our teams in public
My worst mistake to own up to. Part of my job is to critique the product strategy of our teams. This is a natural - if difficult - conversation to have with the team leaders. But there were times where I let my frustrations show to other members of the teams. I upset people I cared about. I burned bridges I needed and they needed. I’m sorry.
#9. Failing to sell ideas to our senior management
The Submit discovery felt unstoppable to me. I thought it responded to a clear user need, had significant cost benefits and opened up strategic opportunities. But I got carried away by being too close to it and failed to communicate these things to our senior leadership. I’m still kicking myself for this. Because I know how to do this.
Other mistakes in my career
In writing up my biggest GDS mistakes I realised something. Many things that I did well at GDS were linked to mistakes I'd made beforehand. These are some of them.
#10. Writing discussion guides at 2am
I did a lot of this at cxpartners. I used to say this was because I wanted to spend time working on the prototypes. But these days it feels more like a control-freak mechanism to ensure I didn’t have to take feedback into account. At its worst, my intern turned up to moderate his first research session to find me still writing a guide.
#11. Researching my designs in a leading way
I used to be both researcher and designer. I was an excellent researcher when I was testing designs made my other people. I found all sorts of problems. But when I tested my own designs they magically performed much better. Yes, I was a good designer, but no, this wasn’t the whole truth. Don’t mark your own homework.
#12. Presenting a huge list of problems to people
When I started out as a user researcher I wanted to hold on to every observation. Partly because I felt this was the way to prove myself. Mostly because I didn’t have any idea how to prioritise. But if you present a huge list of problems to a group they’ll smile, nod, and ignore the whole list. Much better to show them four or five things.
#13. Expecting people to work the same way I work
When I started managing people I was out of my depth. I tried to turn people into clones of me. Leaning over to edit documents. Holding them to timelines I’d set myself. But people don’t respond well to being managed like this. State the goal, let them go, trust them, and give useful feedback. Let them make their own mistakes.
#14. Sharing the wrong things with people
Our society and culture encourages us to be transparent and open. To avoid being ‘two-faced’. I tried this with the people I managed. But it unsettled them when I told them things that were unclear or too far outside their normal world. Now I take this advice from a trusted friend - be judicious with information, emotion, and opinion.
#15. Being angry at others when out of my depth
At cxpartners I was handed an impossible project. I tried to deliver it and spent months being furious with the people who set it up. But what I didn’t realise was that I had the power to say no. That though anger is a useful sign that something is wrong, it’s rarely a useful thing to hold onto for any length of time. I’m still learning this.
#16. Binding my identity to my work too closely
Lots of these mistakes come from linking my self too closely to my work. I worry that saying no will stop people loving me. Once upon a time this was useful because I had loads of capacity. But these days there are far more requests than I have time to spare. Learning that the world doesn’t fall apart when I say no has been huge for me.
#17. Burning out in 2014
I've written before about burning out. I used to think that I could cope with anything work threw at me. But during the impossible project, trying to make a webfont work at 3am, I broke down in tears. I went to New Zealand for four weeks and spent half of it recovering. I did counselling. I had coaching. I learned to deliver the impossible project. It took me six months to regain my confidence. Then I came to GDS.
So, yes, I’ve made mistakes
We all make mistakes. All of the time. Every one of us. It's unavoidable.
It doesn’t matter that we make mistakes. What matters is whether we are able to recognise the mistakes we made. This is hard work for lots of reasons:
- It’s not always possible in the moment.
- It requires us to take a long, hard look at ourselves.
- It means putting aside our anger with others.
- It can involve someone being brave enough to bring something to our attention.
- It means we need to find space to reflect on things away from everyday work.
After we recognise our mistakes we can change things. Of course we will always make more mistakes. But at least we won’t be repeating the ones we made before.
I hope that sharing this prompts you to think about the mistakes you've made. And then, having done this, to try talking them through with someone you trust. I think you’ll be surprised at how helpful people can be when you do...
Let me know what you think on @myddelton. Thanks to Amber Westerholm-Smyth for prompting me to do this and Mia Kos for once saying we should talk more about our failures. Finally, I want to give a huge thank you to the wonderful people at GDS for giving me the space to make these mistakes and learn from them. I will miss you all.
Discovery is important because it sets direction by focusing our work on the right problems. We’ve all worked on things where we’re solving the wrong problems. Too many hours wasted on bad directions. People’s lives. Taxpayers’ money. Our careers.
Yet I see too many teams doing bad discoveries.
A big part of this is that we’re not clear enough about how to run good discoveries. This gets in the way of motivated teams and stops them doing better work. There are other reasons, of course, but this post is for motivated teams that want practical tips.
To come up with these tips I ran two discoveries to find out what works, and what doesn’t, from experience. These are my three stories about doing better discoveries:
- Better discoveries with the discovery block diagram
- Setting up a discovery to succeed with a small team
- Finishing off a discovery to do justice to your work
You won’t find much in these stories about how to do the investigative work of a discovery. There’s plenty of good stuff out there about that. Instead, these stories are about the invisible essentials of good discoveries - how you think about the work, how you plan your work together, and how you bring it all together at the end.
Without better discoveries we can never bring the full power of user-centred design to our workplaces. Of course these stories don’t contain all the answers, but they're a good place to start if you’re running a discovery yourself. I know because we’ve used them to do better discoveries at GDS.
I hope they do the same for you and your workplace.
Let me know what you think on @myddelton.
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.
Starting a discovery isn’t easy because you’re going into the unknown. If you’re not careful you can dive into the discovery work before you’ve properly set yourself up. This can lead to people heading off in different directions and wasting precious time.
I learned this on a discovery earlier this year. We were looking at whether GDS could do something to help service teams collect information from their users. It took us two and a half weeks to set our team up properly. This was much longer than I expected.
Let me talk you through what I learned about setting up a discovery.
Choose the right goal
For years I thought that the goal of a discovery was to explore a problem. So I asked our team to explore the problem of “how do services without access to a development team collect information from their users?”.
We went around in circles for two weeks. We couldn’t get a grip on what we were aiming to achieve. We didn’t know what work to do. Eventually my colleague Pete Herlihy suggested we had the wrong type of goal. Discovery isn’t about exploring a problem, he said, it’s about making a decision about what to do next.
We reframed our goal in terms of making a decision. “Decide if there is an opportunity for GDS to help services without access to development teams start collecting information from their users online”. We included why GDS was funding our discovery.
This focused our work. It grounded us in our organisational context. I worried this would feel too restrictive, but overnight we started talking about the problems we needed to explore to make that decision. Not every single problem we could imagine.
We should have started with a goal framed in terms of making a decision. We should have done this before the project kicked off.
Run an inception workshop
A couple of days after we’d set our new goal we took the whole team to the park, sat under a tree, and ran an inception workshop.
For 90 minutes we talked about our goal and how to achieve it. What did we need to know to make a decision? As we talked, we wrote post-its for each topic that came up and sorted them into these categories:
- Goals (things we wanted to achieve)
- Reckons (things we thought we already knew)
- Stuff to find out (things we wished we knew)
- Rabbit holes (things that would lead to lots of wasted time)
- Scope (things we’d do, things we wouldn’t do)
- This is not (things that seemed related but weren’t part of this)
- Icebox for alpha (ideas for later)
The conversation went all over the place. From users to technology to policy to data to cost savings. Discussions about whether something was a reckon or something to find out, whether something was in or out of scope. Everyone contributed.
There was something magic about having a free-flowing conversation that turned into a bunch of structured notes as we talked. Try this for yourself.
Set “discovery is done when” objectives
We took the notes from the inception workshop and turned these into 20 outcome-focused objectives. Here’s our list of ‘discovery is done when’ objectives:
- We understand types of users for end users and service teams
- We understand problems end-users have with paper forms
- We understand problems service teams have with paper forms
- We understand when/where end-users need paper forms
- We understand when/where service teams need paper forms
- We understand the appetite for process change in service teams
- We understand how paper forms are created/updated
- We have a picture of the range of complexity across paper forms
- We know what proportion of paper forms require evidence
- We know the different types of supporting evidence
- We understand why signatures are required on paper forms
- We have a list of important design patterns used in paper forms
- We have a list of important fields/data types used in paper forms
- We understand how information collected gets into databases
- We understand error rates and their impact on data quality
- We understand how and why departments are using form builders
- We understand commercial form builders and their benefits/costs
- We have a cost model for paper forms
- We have an estimate of the number of paper forms in government
- We have a prioritised list of alphas, including benefits/costs
Look at this process. We started with a simple team conversation about our goal, and ended with a list of outcome-focused objectives. A list that described where we needed to get to without telling us what we had to do. Perfect for a self-organising team to pick up and run with.
This is my secret to setting up a discovery. Take a clear goal, discuss it as a team, and agree “discovery is done when” objectives.
Divide up the work
We divided our work into four areas of investigation in keeping with the discovery block diagram. This worked surprisingly well. We split the 20 objectives into four areas led by four different people:
- Users and their needs - user researcher (objectives 1-6)
- Content and design - service designer (objectives 7-12)
- Data and technology - technical architect (objectives 13-17)
- Cost models - delivery manager (objectives 18-20)
The team worried this meant going off in four different directions. That’s not how we worked. We did things together, whether visiting service teams, analysing data, documenting designs or coming up with cost models. Discovery is a team sport.
Why divide the work then? It made it clear who in the team was responsible for each of the 20 objectives. When we got into the barely-controlled madness of discovering things it was useful to have this to keep us on track. We knew we needed good enough answers to all 20 objectives rather than perfect answers for a few of them.
This gave each person space to develop their own way of telling the story of their bit of the discovery. It preserved the diversity of viewpoints that we brought to the work as individuals. Each of us ended up owning a major slice of the story.
Plan the work against the time you have
Finally, we planned the work. We mapped the 10 weeks down the left hand side, the 4 areas of investigation across the top, and the activities on post-its in the middle.
We didn’t expect to stick to this plan. Instead, we used it to come face-to-face with how little time we had. It’s easy to underestimate the time you have available to do things. This leads to avoidable compromises at the end.
Here’s what we ended up planning:
- Weeks 1-2: form as a team, work out goals, and plan the work we’re going to do
- Weeks 3-8: do the exploratory work to answer the objectives
- Week 9: bring together everything we learn into clear findings
- Week 10: come up with alphas and present our work to decision makers
After realising that we had only 6 weeks to do the investigative work, we were able to make better decisions about how many interviews to do, how many services to visit, and how many different systems to assess. You always have less time than you think.
Sit back and watch the team go
Setting up in this way meant that the whole team knew what we were trying to do, and without being told how to do it. This shared understanding about direction is what enables a team to perform as more than the sum of its parts. Watching the team go off and do the work was one of the most amazing experiences of my working life.
This is now my standard advice to teams who are setting up discoveries:
- Choose the right goal
- Run an inception workshop
- Set “discovery is done when” objectives
- Divide up the work
- Plan the work against the time you have
One final word of warning. This works because it’s a shared process which involves the whole team. The critical ingredient for setting up better discoveries is making sure that the whole team is ready to start on day one. That’s (much) harder than it sounds.
This post is one of three posts about how to run better discoveries. The other two are better discoveries with the discovery block diagram and finishing off a discovery to do justice to your work. Let me know what you think on @myddelton.
Finishing a discovery is harder than it looks. It’s easy to fall into the trap of discovering new things right up until the last minute. This means we don’t leave enough time for bringing findings together, designing alpha ideas, or persuading our decision makers.
I learned this on a discovery earlier this year. We were looking at whether GDS could do something to help service teams collect information from their users. Even though we left two weeks to finish our discovery we still struggled to do everything in time.
Let me talk you through what I learned about finishing a discovery.
Wrap up the areas of investigation
We’d been working on four areas of investigation in keeping with the discovery block diagram. Users and needs led by a user researcher, technology and data led by a technical architect, content and design led by a service designer, and cost models led by a delivery manager.
With two weeks to we needed to bring all the different things we’d learned together. Without a shared understanding we knew we’d struggle to agree a direction.
We stopped work, cleared our calendars for a week, booked out a meeting room, and tackled one area each day. Monday was users and needs. Tuesday was content and design. Wednesday was technology and data. Thursday was cost models.
Each afternoon, we did a three hour workshop with the whole team. The goal was to end with a list of findings we agreed on. How we did this was up to the person running it. We ended up with workshops full of lively disagreements and resolutions.
I worried that a week was overkill. It wasn’t. It takes time to build a shared understanding across the whole team. It takes time to re-form as a team after six weeks dashing around the country to find things out.
Agree one set of discovery findings
On the final day of this week - the Friday - we created a single set of discovery findings. This was also in keeping with the discovery block diagram.
We gathered together as a team. Each person wrote the 10 findings they thought were most important and then we turned them into this list:
- Forms are hard to find
- Too many forms don’t work for people with access needs
- Bad guidance makes people call before a form is submitted
- Forms are wrappers for evidence (and evidence is complicated)
- Users have to fill in unnecessary and duplicated information
- Too many forms handle offline payments in a horribly insecure way
- Data submitted ends up in a huge variety of systems
- Error rates are very high
- Eligibility is determined too late
- Bad forms are expensive
- Problems and costs of forms are not being measured well
- Forms are not easily changed (legislation and policy can block)
- Operations and caseworkers are removed from improving forms
- Digital forms alone cannot kill old systems
It was easy to create these 14 findings because we’d already worked through each area of investigation in detail. This meant that each finding was backed up by a rich web of stories, diagrams and data.
We didn’t split these findings by area of investigation. Each finding brought together things we’d learned across the whole discovery. We had seen the same things cropping up in our user research, design analysis and technical investigation. The findings were a powerful triangulation of all the important things we’d learned.
These findings were the backbone of our work. They helped us brief people in our design workshops. They helped us generate our ideas for alpha. They helped us communicate with decision makers. They helped us tell the story over and over again.
Generate ideas for alphas
In the final week of our discovery we moved to ideas for alphas. This meant switching from talking about problems to talking about solutions. We found this hard because we’d avoided talking about solutions up to this point (as all discovery teams should).
We had two plans to come up with alpha ideas. Neither went smoothly.
The first plan was to run design workshops with multi-disciplinary people from across GDS. The workshops were great at forcing us to finish off our findings. They worked well at promoting our work across GDS. They fell down in coming up with alpha ideas because I didn’t spend time enough time preparing though. More attention next time.
The second plan was for the team to hunker down in a room and come up with a final set of alpha ideas ourselves. This worked beautifully in that our team came up with a huge variety of alpha ideas. But then I ruined this by clumsily fitting these into my own pre-conceived framework. This was the lowest point for me in the discovery. We recovered by organising our ideas into a roadmap as a team.
I learned, painfully, that you need to allow enough time to come up with alpha ideas. There’s a whole design process hidden in this final part of a discovery that I’d never properly noticed before. I’ll respect that in future.
Persuade your decision makers
Finally we had to communicate what we’d found and persuade decision makers to fund alpha ideas. Luckily the way that we had run the final two weeks of our discovery prepared us beautifully for these presentations.
- We had a convincing backstory. Each person had been practicing the story of their area since the findings week. As we stood in front of our decision makers, each of us had powerful things to say about users and needs, design and content, technology and data, and cost models.
- We had a compelling summary. By using the findings to frame design workshops we’d found ways to make them stand alone. This made them punchy for decision makers who didn’t have time or inclination to hear the details.
- We had a believable future. Our roadmap of alpha ideas painted a vision for public beta. Yes, I worried about showing a roadmap and a vision, but decision makers aren’t comfortable with ambiguity. Sometimes you have to play the game.
Having these things prepared us for the final presentation. Luckily for us. When you’ve been wrapped up in discovery it’s easy to underestimate how difficult it is to communicate what you found out and persuade people to make a decision.
It's important to plan the end (before the end)
Finishing our discovery in this way meant we did justice to our earlier hard work. This is now my standard advice to teams who are finishing discoveries:
- Wrap up the areas of investigation
- Agree one set of discovery findings
- Generate ideas for alphas
- Persuade your decision makers
This means planning in advance. Booking your meeting rooms weeks out. Inviting people to design workshops before they have other commitments. Lining up decision makers for the right place at the right time. Being clear that your team will stop work.
One more thing. This is a story about finishing a discovery as one team. We had to leave time to share things, argue about things, make things clear, and resolve things. Yes, it can be quicker to do these things as individuals. But this is a false economy.
Taking the time to finish as one team gave our findings greater depth through resolving multiple perspectives. It meant that every team member was able to tell the story of what we learned and where we’re going. These are important things.
This post is one of three posts about how to run better discoveries. The other two are better discoveries with the discovery block diagram and setting up a discovery to succeed with a small team. Let me know what you think on @myddelton.
Recently I've realised that I'm not spending enough time talking through the problems I face at work. This has been a hard-won realisation for me.
I used to be able to solve work problems by reading things in books and articles and then practicing them on my own. This is how I learned to be a designer and a researcher. I learned how to interview people, make prototypes, do usability testing, give presentations, run workshops, and many other things like this. It felt like a superpower.
But as my work changed - from working on my own to leading teams - this superpower stopped working.
This showed up in a series of personal crises at work:
- when I was designing an online supermarket and burned out because I couldn't work out how to share work with my team
- when I jumped from managing no one to managing four people and struggled to do my job because I couldn't figure out how to let go of enough control
- when I became paralysed at the thought of doing a product manager role on top of my role as lead user researcher because I didn't realise I could negotiate with my own managers to put some aspects of both roles on hold for a while.
I didn't get through these crises by reading books (although god knows I tried). I got through them by talking things through with other people.
I think this is because these crises were not about how to do specific things on my own. They were about how to act and behave in complex situations that involved many other actors and their own motives. Books can't ask questions to clarify context before they give advice. People can, and do, ask questions (or at least the best ones do). And it's this back and forth about the context that makes their advice so powerful.
I noticed something else too. The people that helped me most were not the kinds of people I'd talked to up to that point in my career.
Previously, I would talk with other researchers and designers because the problems I was facing were practical problems about how to do specific things. But researchers and designers were often as clueless as I was about how to deal with this new class of problems.
I had to find new people to talk to.
I solved the three crises using a mixture of counselling and coaching. It turns out that counsellors and coaches are experts at asking the right kinds of questions and then giving powerful, contextual advice.
But this is too expensive in the long run.
Now I talk through these problems with people I know at work who face similar problems themselves. These people are not just researchers and designers - they include product managers, content designers, delivery managers, and technologists. There are only two qualifications. Do I trust this person enough to share my problems? Does this person have experience of facing similar problems themselves?
These conversations are amazing. In the last two weeks alone I've realised that I'm not sharing enough of my work with my senior colleagues, that I'm sometimes too focused on building consensus and not making a decision myself, and that my work satisfaction doesn't depend on simply getting stuff done but also on the working culture.
These are wise things that I hadn't realised on my own. They're difficult to answer using books because they're specific to me and my personal work context.
So that's what I am doing now. Or trying to, because it's a new thing for me and I keep forgetting to do it. My deep-grained habit is to go back to reading a book and shutting myself away to solve it on my own. But although it's taken me about three years to realise this, I'm finally clear that books don't hold all the answers for me.
If you are facing these kinds of problems then you should give this a go too...
Let me know what you think on @myddelton. Thank you to the people who have given up their time to talk things through with me.
“Not everything that is faced can be changed, but nothing can be changed until it is faced.” James Baldwin
I love this quote. For what it tells us about how to approach the world. For what it tells us about how to have relationships with others. And for how it gets at the root of what people struggle most with when it comes to user research.
User research is about starting by facing things as they are.
People worry that the things we learn might be impossible to do anything about. They worry that understanding these things is a waste of time. They worry that these things will mean rejecting the fundamentals behind the things we are working on.
Let’s be honest. All of these things can be true. Are often true.
Facing things as they are turns up things that we can’t do anything to solve. The problems we find are beyond our power. This happens all the time. That’s life.
Facing things as they are requires that we invest time in understanding things. Given that there will be things we can’t do anything to solve, with hindsight it can seem like what we did was a waste of time. Hindsight is a trickster though.
Facing things as they are often leads to a dawning realisation that the things we are working on are the wrong things. You can avoid this truth for a while. But in the long run there is no hiding from this. The things you poured your heart into don’t lead to changes in the world. If you care about change this kills you.
There's a final worry about facing things as they are. This one isn't true though.
People fear that facing things as they are means designing for things as they are, not designing for things as they could be. This is not how research works. It's not how design works. It's not how humans work. Once we face things as they are we are free to imagine new futures. This is our job. As Dan Saffer says, empathy is not enough.
I understand how difficult it is to face things as they are. I struggle with this on all sorts of levels. It’s easier, in the short term at least, to avoid facing things as they are in all areas of our lives. Our work. Our friends. Our selves. Our deaths.
But, like James Baldwin said, nothing can be changed until it is faced.
I heard this quote on an episode of The Long Now called What the dying teach the living. Many of the things in that episode ring true for me and lessons I've learned in my life. Have a listen. And let me know what you think on @myddelton.
I am scared of talking about being a leader and I need to get over it.
There's something inside me that says, when I talk about leadership, that I am getting too big for my boots. That I'm putting myself above other people. That this is not the kind of behaviour that is appropriate for a proper human being.
The thing is, I know that good leadership is essential. I deeply value good leadership. The places where I have enjoyed working the most have been those with brilliant leaders. It transforms the feeling of what it means to be at work. It makes everything better. It's a brilliant thing to want to do and to want to provide.
Yet there's something inside me that winces at the thought of calling myself a leader.
I love working with groups of people
I started being in bands at 16. Writing and playing music together. I tried to lead those bands. Although I was a good leader in some ways, I was pretty awful in others. At worst I tried to lead by command and control. I didn't listen much to others or work on things as a group. I had some really painful experiences when those bands broke up. I learned some hard lessons about myself.
At 28 I stopped being in bands and moved back to London. Since then I've done a succession of jobs. Recently I've noticed a pattern in these jobs. I keep doing new roles where I expect to be going back to doing solo work. But as soon as I join I end up working with groups of people to do things together.
In 2008 I joined an organisation as a web manager where I thought I'd just be sitting doing solo coding and editing tasks. I ended up working with the whole organisation to redesign and migrate a website.
In 2011 I switched to being a user experience designer where I thought I'd be sitting making self-contained designs. Instead I ended up working with my clients' organisations to design and build digital products.
In 2015 I joined GDS as a user researcher with the intention of focusing on the craft of being a user researcher. I wanted to stop worrying about managing people and leading teams. I was dismayed to find, when I arrived, that Leisa and Tara had marked me out to lead the user research on the Government as a Platform programme. I now lead a team of 9 user researchers working across 4 products. I am even leading a multidisciplinary product team through the discovery phase as a product owner.
Even though I struggle to say the word leadership out loud, I love this work. This is the work that I am drawn to. It is impossible to drop me in a situation - any situation - and expect me to focus on a single bounded task that doesn't involve other people.
It's just not how I work.
Instead, I look up. I work out what is going on that makes the task not quite right. I meet and talk to the people around me. I start to have ideas about the task, and the task behind that, and all the tasks behind that, and all the people working on all the tasks. I start to have ideas about how all that could be better. And then I'm out there, talking about these ideas, building a consensus that lets us make things better.
I’m uncomfortable with the word leader
It might sound to you that all this angst around the word leadership is ridiculous. I agree. This is why I'm trying to move past it. Like I said at the start, I think it's something inside me that is holding me back.
It reminds me of when I became a designer. At one point Andrew Travers took me aside and told me that I was a designer, that I should call myself a designer, and that I would easily get a job as a designer (he was right on all three counts). Up until that point I would have never, ever used the word designer to describe myself. There was something in him saying it that switched what I thought about myself. It made it OK.
I wish someone could just flick the switch for the word leadership like Andrew did with the word designer.
People are trying. I was talking about how I feel about this to my colleague Holly. I was saying that my fear is that if I start writing about leadership then people will think I'm arrogant and too big for my boots, and she laughed and said Will, literally no one will think that. And it’s not just her. Leisa and Tara expected me to lead a group of user researchers when I joined GDS. My programme have trusted me with a product team to lead. Close, honest friends are encouraging me to get out there and do it.
The signals are there. But for some reason that's not been enough for me.
Honestly, and slightly weirdly, it goes deeper than that. I've been talking about it on and off in counselling. I've had some 1:1 coaching from someone that I trust where this was pretty much all we talked about over two sessions. It's definitely a hangup.
But...I am a leader
It's come to the point where I am spending too much energy on this hangup. I could be spending this on more useful things. So I'm making a choice to move past this.
I am a leader. My job is to lead groups of people to make great things together.
There. I said it. Now perhaps I can stop agonising over the bloody word and start sharing some of the interesting and painful lessons that I’m learning about this new part of my life. Because, believe me, I have plenty to say...
Let me know what you think on @myddelton