Books versus people

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. 

Facing things as they are

“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.

My problem with leadership

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

Thinking, talking, writing

Ideas take different shapes when you are thinking about them, talking about them, and writing about them. These shapes, and their transformations, are a useful tool.

This came to my attention at a counselling session. I've been doing this on and off for the last couple of years. In December, on my way out of the door, I remarked off-handedly that I always leave the sessions feeling lighter and more resolved.

The counsellor asked what I thought was behind that.

I paused. I considered what we'd just been talking about. How those things had been going around in my head for ages. How speaking these things out loud had made those same, familiar thoughts feel somehow different. 

My answer to the counsellor was this. Taking things I am thinking about and saying them out loud transforms my thoughts from seeming real into somehow being real. And when thoughts are real I end up having a different relationship to them. This transformation from thinking to talking helps me see things differently. It's helpful.

Talking makes ideas more real

I was shocked at the simplicity of this realisation. What is going on here?

Although things in my head often feel linear, logical, coherent and true, in reality I'm not convinced they are at all. When I say them out loud - forcing them into a linear format where they mean one thing and not another - the coherence often evaporates. I spot gaps and inconsistencies as soon as I start talking.

My ears come into play too because I hear myself talking. The words that were rattling around inside my brain are now in the air as sound waves. My ears can’t help but hear these sound waves as human speech, and I think I perceive human speech differently to how I perceive thoughts in my head. If you've ever struggled with a crossword clue in your head, only to have the answer materialise as soon as you speak the clue out loud, you know this feeling. This difference in perception makes me aware of the contradictions and absurdities in what I am saying. 

Talking out loud - even without the counsellor saying anything in return - allows me to reflect on my thoughts in a different way than when they're in my head. This reflection allows me to resolve thoughts have been looping around for hours, days or weeks. 

That's where the lightness comes from. The resolution of stuck thoughts.

Writing makes ideas more useful

So talking my thoughts out loud lets me resolve my thinking about into something more concrete. But there's another step that pushes this process even further for me.

Writing.

Writing is to talking as talking is to thinking. 

Yes, talking is more linear and more concrete than thinking. But writing is even more linear and concrete than that. Writing has a beginning, a middle and an end. Sentence after sentence. Page after page.

Talking allows others to critique my ideas, in the moment, as I utter the words. Writing is not just about those others or that moment. Writing is available to more people in more locations. Writing can travel into the future in a way that talking can't.

I said that talking lets me spot contradictions and absurdities in my thoughts. Writing forces me go beyond this and confront the technical and logical gaps in the things I’m saying. Anyone who writes knows that it’s much less forgiving than talking.

And talking isn’t just about the words I use. I can use body language, try being charismatic, or simply wave my hands around a bit. These things aren't as misleading as the tricks my brain uses to make me think my thoughts are coherent. But writing removes these physical props entirely. My thoughts are laid bare. Self-supporting. Which means being more truthful and more accurate than when I talk.

Writing is hard. It’s hard to capture ideas that seem coherent in my head. It’s hard to write explanations that I have no trouble explaining when I talk to you. It's another level of discipline and clarity entirely.

Thinking, talking and writing all matter

None of this is to say that any one of thinking, talking or writing is better or worse than any other. They are simply different modes for working through ideas. What happens when you switch between modes is useful and worthy of attention.

For example, I use these different modes to filter out good ideas from bad ones. The first time I talk about an idea out loud is a bold (and necessary) step in questioning whether the idea has merit. Later, trying to commit that idea to writing is an even bolder step in understanding whether the idea is strong enough to live on its own. 

It’s not just about words...

Quick pause.

If you’re a designer you’ll have noticed this is a radical, reductive simplification of what's going on. That’s the thing about writing. Sometimes you need to open with an incomplete idea to lead to a bigger one.

I’m discussing talking and writing because that's my dominant mode of doing things. I’m a words person at heart. If you’re a visual thinker you’ll be doing this same process by going from thinking to sketching to designing. If you’re a maker type you’ll be going from thinking to prototyping to building. 

In fact even that’s a simplification. We all flip between all of these modes - thinking, talking, sketching, prototyping, designing, building - as we go.

What I'm really discussing here are the stages of things going from being in your head (where they seem to make sense but are inaccessible to anyone), to emerging into the world (where they can escape your mind’s trickery and be exposed to critique), to being permanently in the world (where they are laid bare for others to make use of). 

It’s just that I’m telling that story through my own lens of thinking, talking and writing.

...but it's definitely about balance

Thinking, talking and writing are all important. But given that we all have limited time available, how do you balance the three of them? 

I can’t say what’s right for you. But I can talk what works (and doesn't work) for me. 

Thinking

A big part of thinking is making sure that I have plenty of diverse inputs. I read books, listen to podcasts, interact with other people and get exposed to a huge variety of ideas at work. I’m a curious person and I'm naturally drawn to this part. I love it.

But I've learned, the hard way, that having lots of raw material is not enough. I need to have the time and space and inclination and willpower to do the thinking. When I was working long hours in a high-pressure job my thinking suffered. I burned out. I wasn’t thinking much about either my professional life or my personal life. That's why these days I work my hours and I work a four day week. This is less money but more time away from pressure to think about things. It helps with thinking a lot.

I’ve realised there is something else that's important. I need my mind to be capable of being peaceful and focused. I need to escape those thought loops that consume it all too easily. I found, to my utter surprise, that 10 minutes of meditation each morning works for me. This was after accidentally reading the beautifully-illustrated Quiet the Mind in a bookshop while escaping an unexpected storm in Fishguard.

Talking

OK, I say talking, but in the wider sense this is about bringing my ideas into the world for first critique. I am slowly getting better at doing this but it's been a long road.

At work, everyone knows I’m someone who talks ideas into existence. I endlessly try out new thoughts on people, as much as to see what it feels to say it out loud as to get their feedback (both matter to me). I spend time sketching things for people as a way to bring ideas into a place where we can both look at them. I don't prototype much any more, which is a shame.

In my personal life I have two things that help. 

I write 750 words every morning of whatever is on my mind. This is loosely based on Morning Pages (although I don't do longhand writing!). Although it's technically writing, it's more akin to talking because it puts things I’m thinking into a place where I can reflect on them. It's a conversation with myself. You would not believe how many stuck thought loops I have resolved by simply putting them onto a page as a stream-of-consciousness. It’s like magic.

I also go to counselling these days. Or talking therapy. A lot of the benefit for me is simply verbalising things to someone else and then looking at them together. Turning a chaotic invisible thought process into a linear string of sentences. Again, you wouldn't believe how much clearer things become during this process.

Writing

The thing I'm not paying enough attention to is writing. Or, more widely, putting things I know permanently into the world. I’m not good enough either at work or at home.

At work, I know more about how to do my job than I am able to transmit to the wider community of people that I work with. People who would benefit from me being able to write things down properly. My team get the benefit because we work together and I can talk about things. But that's where it ends. So much knowledge transfer in organisations breaks down at the point where tacit knowledge held by teams through talking isn’t captured in a way that can scale to other teams or future situations. This is my challenge over the next year. It’s in my objectives. Hold me to it if you see me.

At home I kind of feel the same. All this stuff - the meditation, the 750 words, the counselling - is changing my understanding of what it is to be human. To live in the world. But I never write this down, which means no one else can read it. This is a shame given how much I’ve learned from others who have written about their lives.

Feeling lighter is a feeling worth chasing

Like I said at the top, my counsellor asked me about this whole feeling lighter thing.

I told her that going from thinking about things to talking about things made me feel lighter. And I speculated that this might extend further into writing about things.

And she said, good, why don't you try writing about some of the things you are learning about yourself and the world?

So that's what this post is. Even though it's difficult. Even though it makes me feel exposed. Even though I’m basically terrified to tell you these things about myself. Even though there's a little voice telling me that all of this is banal and obvious stuff. 

I’m intrigued to see whether this writing will make me feel lighter. And whether or not sharing these things about myself is useful or helpful for you.

Let me know what you think on @myddelton.

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

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.