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

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

Eight principles for user researchers on Government as a Platform

Reposted from my original post on the GDS blog.

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

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

1. Start with your team's needs

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

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

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

2. Use research questions

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

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

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

3. Talk to users all the time

It is critical to always be doing research.

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

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

4. Involve the whole team

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

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

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

5. Present one list of problems

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

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

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

6. Maintain a research wall

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

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

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

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

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

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

7. Document the research

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

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

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

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

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

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

8. Manage your contacts

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

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

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

All eight principles are critical

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

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

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

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

My favourite design articles of 2015

The only annual post I actually look forward to is Dan Saffer’s list of his favourite design articles of the year. Go and read his list first and then see what you think of these…

Messaging Is Just Getting Started
On Conversational UIs
Facebook M’s bet and the future of Web interfaces
The radical idea that a simple messaging interface coupled with narrow AI could end up dominating interface design is the most interesting design topic of 2015. I didn’t see it coming and have no idea how to design for it. But it makes total sense and has a weird feeling of inevitability.

The AI Revolution: The Road to Superintelligence
The AI Revolution: Our Immortality or Extinction
A monster two-part article that lays out the terrifying prospect of advancing from the narrow AI we have today to a world-dominating superintelligence. I have doubts whether this is possible, but this is a phenomenal overview.

An Interview with Rochelle King, Global VP of Design at Spotify
Spotify’s design used to be a car crash. But something changed because over the last couple of years they’ve pumped out a slew of user-centred design improvements. So when Rochelle King talks about how to make design and research work together, I listen.

What Is Code?
Be one of the people who read this, rather than one of the people who meant to but didn’t. An amazing story, beautifully told.

How Discover Weekly cracked human curation at internet scale
I loved ThisIsMyJam more than anything but I’ve hardly missed it since Spotify released Discover Weekly. Astonishingly, it turned out that Matthew Ogle was involved in both. This marriage of music with user-centred design and algorithmic data is the most exciting thing I can imagine working on.

4 things I learned from Breaking Smart about the future of work
Treat work as an infinite game. Do whatever is the most interesting thing to do. Stop trying to reach closure and focus on opening things up instead. Interesting, counter-intuitive but strangely liberating ideas.

Harsh Empathy
Not many articles shock you into re-evaluating your own actions. This one, which links empathy with bad behaviour, made me think twice about mine.

I didn’t read as much in 2015 as I would have liked to, so I’m hungry for your recommendations. Send links to @myddelton or point me at your own list.

How to get your client to say yes

7 things to do that hugely increase the chances your client will sign off your designs when they’re supposed to.

Every client-facing designer struggles with sign-off. It doesn’t matter how good you are, how perfect the work is, how watertight the research was. If there was a quick fix you would know it already, but there isn’t.

I’m about to leave client-facing design, but before I go I want to share my list of things you can do if you’re tired of wasting time with wasteful sign-off processes. None of these things are tricks. All of them are based on deep respect for your client. And they all work.

These are my 7 steps to getting your client to say ‘yes’.

1. Research your client’s needs

If you want to get your client to say ‘yes’ then start with understanding what your client needs in the first place. It’s user research, but with clients.

There are two killer client research methods you should be using.

The first is the kickoff meeting. It’s your responsibility to leave with a clear understanding of exactly what the client needs from this project. Prepare in advance by going through any brief or proposal materials and write out that huge list of questions you have. Then do good some detective work and make sure you leave the workshop with your questions answered. You would be amazed how many people fail to do this.

The second is the stakeholder interview. A stakeholder interview is a one on one discussion behind closed doors with someone in your client’s organisation. This privacy gets you to the deep needs of your client, not just the surface-level ones that people talked about at the kickoff meeting. Prepare well. Speak to lots of different people. Make them feel safe. Ask tough questions. Every design project should have stakeholder interviews.

If you pay close attention, this combination of the kickoff meeting and stakeholder interviews will give you a fantastic, nuanced understanding of what your client needs from the project.

Client research is always the first step to getting your client to say ‘yes’.

2. Over-communicate like crazy

People hear what they want to hear. If you have 10 people at the same meeting, it’s likely that all 10 of them think something different happened. This is a disaster for getting your client to say ‘yes’ because everyone is working from a different understanding of the problem.

The solution is to over-communicate, to say things more often than you think you need to, and here are my two favourite ways to do it.

The first is to post notes from every meeting into Basecamp (or whatever you use). Write them in plain English and make sure you cover everything you agreed in the meeting. Then say to your client, look, this is what I think happened, and this is your chance to tell me I’m wrong, because after this I’m going to be treating these notes as the binding truth. It takes a bit of extra time but it’s worth it. Clients respond well to these notes because it shows you were listening.

The second is Jared Spool’s short-form brief (go and read his article if you haven’t already). Taking the time to write a short-form brief is good. Signing off the brief with your client is better. But the real magic is the act of reading it aloud at the start of every client meeting, because this brazen act of over-communicating guarantees that everyone has the same understanding of the project, throughout the whole project.

Only one thing matters with over-communicating: are people still saying random things that sound as if they’re talking about a different project? If they’re not, you’re already closer to getting your client to say ‘yes’.

3. Show work before (you think) it’s ready

Take a problem, lock yourself away for weeks to solve it perfectly, and then rock up to your client’s offices asking them to sign it off.

That’s how you get your client to say ‘no’.

You make a million tiny decisions that feel obvious to you but are invisible to the client. It’s fine to make these decisions but you need to find ways to make them visible to the client before you build a super-structure on top of them. Because if they’re wrong your super-structure is coming down.

Instead, show your work before you think it’s ready. I’ve shown sketches, wireframes, comps, prototypes, Word documents, spreadsheets. This is all about framing it well, knowing what to listen to, and knowing what to ignore. It’s a skill you need to learn.

Here are three reasons this helps with getting your client to say ‘yes’:

1. Showing clients things that look real prompts them to give you more information about their real needs. It’s amazing how the quality of the feedback improves when you talk about artefacts and not abstract ideas.
2. Talking through your design patterns lets you work through their objections and fears one by one. This is so much easier and more productive than trying to persuade them in one big final presentation.
3. Sharing work in progress shows your vulnerability. Asking for feedback shows you are listening. Both these things build your client’s trust in you, and in the end sign-off is all about trust.

Showing early work feels dangerous and risky when you first start doing it. But it’s probably the single best tool you have to get your client to say ‘yes’.

4. Build the ultimate sign-off process

None of this matters if you fuck up the actual sign-off process. Over the last five years I have fucked up the sign-off process more times than I can count.

This bitter experience has taught me two truths about sign-off:

• Clients always need more review opportunities than you think they do
• Clients don’t care if their new feedback contradicts their old feedback.

The ultimate sign-off process must live with these two truths if you want to get your clients to say ‘yes’. Here are two ways to do this that work.

First, schedule (many) more reviews than you think are necessary. On a recent project we worked in 3-week design sprints and the client needed 6 reviews in each sprint before they started signing off things in-sprint. Your goal is simple: get to the point where your client isn’t feeling rushed into making decisions about design, because rushed clients don’t say yes. It means you have less time to do design work, but that’s the cost of getting your client to say ‘yes’. No one said it was easy.

Secondly, control your client’s access to review materials like a maniac.When you plan 6 reviews every 3 weeks there is a HUGE risk their feedback will be late, they’ll comment on previous versions, or they’ll reverse their previous decisions. We avoid this with hardcore workflow management:

• upload the designs to InVision two hours before the review
• go through the designs in InVision during the review
• leave the designs open for comments for a few hours after the review
• remove the designs from InVision completely and close comments
• work on the next iteration based on the feedback from the review.

It’s (nearly) impossible for clients to give late feedback, or to give feedback on the wrong versions, with this system. You might think it would be impossible to get your client to work in this way, but it’s how we work.

And it works like a dream in getting your client to say ‘yes’.

5. Bend, but don’t break

How you respond to client feedback in design reviews is critical to getting sign-off later on. You should bend, but not break.

The ‘bend’ part is to concede on the stuff that doesn’t matter. Fighting for every single design decision is exhausting and counter-productive. Here are some reasons why it’s OK to concede stuff:

1. There are many ways to do things. This means there are hundreds of details where it doesn’t matter which way you solve a problem.
2. Your approach is often based on a hunch. Unless you have bottomless pockets it’s impossible to base every single design decision on research. Why go to the wall for a hunch about something that doesn’t matter?
3. Clients are right more than you like to admit. You’re attached to your design because you made it, but often their approach will be just as good if not better. You do not have a monopoly on being right.

You probably hate this advice. But if you concede on stuff that doesn’t matter then your clients not only feel listened to (which builds trust) but when you DO push back, they are much more likely to listen.

The ‘don’t break’ part? Never concede stuff that matters without a fight.Make the case for why it matters and convince your client. Use every tool at your disposal which might include the hairy arm technique, psychology studies, an appeal to ‘Apple does it like this’, crying, pointing out how much extra it will cost, trying to get the client’s boss to overrule them, sneaking it in through the back door. Whatever it takes.

This is a core skill of being a good client-facing designer. Can you judge which parts of your design are really important and which parts are not?

Getting this right is critical to getting your client to say ‘yes’.

6. Kill ambiguity where you can

Design needs ambiguity. We don’t know what the answers are, what they look like, how many there are, how big they will be, what shape they will take, or really anything about the answers at all before we start.

Clients hate ambiguity. It makes them nervous. They worry about paying you a ton of money when you even can’t tell them what they’re going to get.

We must convince clients to live with the ambiguity needed for good design. But in return we should remove ambiguity from everywhere else to stop our clients feeling nervous, because nervous people struggle to say ‘yes’.

Here are some places where you should remove ambiguity:

• Cost. Make sure you are clear about how much things cost. Alert clients to anything that changes cost and make it clear how big the change is. Don’t hide your costs and think you will get away with it. You won’t.
• Scope. Agree a clear scope upfront and keep returning to it. Don’t let the client make it bigger without proper agreement. Don’t ignore it when you come to deliver. Make sure that you deliver what you agreed to deliver.
• Time. Set times for meetings. Set times for sending over work for review. Set times for calls. Set times for milestones. Keep to all the times. If you can’t keep to a time you have set, tell your client well in advance.
• Amendments. Make notes of what the client says and what you agree to do in design reviews. Type up these notes and send them to the client. Address all the points in your notes by the time you do your next review.

You earn the right to ambiguity in the design process, where you need it, by removing ambiguity from everywhere else. Too many design agencies are ambiguous about too many things. Don’t be one of them.

If anything sums up my whole approach to getting your client to say ‘yes’, it’s being clear at every step of the way.

7. Sign it off before the end

This is a short one. It’s a hack really.

If a project ends on a Friday, set the final sign-off for Wednesday. You know there will always be final amends. If you get them on Wednesday, you can get your client to say ‘yes’ on Friday.

Hello weekend.

Good luck!

It’s taken me five years of client-facing design to work a lot of this out. It still amazes me how little of this is common practice, but this bread-and-butter stuff is never as exciting as articles about new design patterns (notice that none of these 7 tips are about doing better design work!).

Why should you care? Why should you bother? Well, designers that get stuff signed-off finish their projects on time, which means happy clients and happy agencies. These two things do not go unnoticed.

I’m off to work at the Government Digital Service now. Good luck!

This is how we ran design projects when I worked at cxpartners.

How to be a good client

10 simple rules to follow that will dramatically increase the quality of work you get from any agency you work with.

Have you ever bought work from a design agency? I’ll bet you weren’t 100% satisfied. I know because I used to buy work from design agencies and was never 100% satisfied with what I got.

Perhaps they didn’t do what they said they would do? The designs looked great in the presentation but terrible at launch? That increase in conversion never happened? Or you got to the end only to find the agency needed more money to finish the work?

All these things happened to me when I was a client.

I always blamed the agency. But while there are some awful charlatans out there, now that I do agency work myself I’ve found another reason why I might not have been 100% satisfied. One that’s a bit closer to home.

It’s not possible to get truly great work out of a user experience agency (no matter how good they are) without being a good client yourself.
 

Be clear about what you want

The first rule is to assume that we, the agency, are utterly stupid. Also that we are terrible mind-readers. Be extremely clear about what it is that you want us to do for you. Write it down in black and white and make sure we understand it.

If you don’t do this, we’ll spend all of your money doing something else, and you’ll be annoyed with us.

Tell us how much money you have

This sounds like a terrible idea to you. But you’re going to have to trust us to get great work and that starts with the money.

Tell us how much you have and we’ll design a project to get you fantastic results. Hide it away and we’ll respond by either scrimping where we don’t need to (compromising quality) or, more likely, by spending way too much early in the project (making it more expensive, lowering the quality, and in some cases even killing the whole project).

Send us the documents we need

What could be easier than emailing some files? It all sounds so simple. We meet, agree which documents we need, and you send them.

But, in a twist (which I find mind-numbingly bizarre) we almost NEVER get all these documents from you when we ask for them! And if we don’t get the things we need to do the job, the job won’t be any good.

Give us access to the people we need

Your people are all busy, we get that. They have a million things to do.

But we need to talk to them, at length, because they’re the ones that understand how everything works in your business. You don’t know how it all works (honestly). We don’t know how it all works (clearly).

And if the people making the new stuff don’t know how everything works, the new stuff won’t work.

Reply to our emails and phonecalls

This one sounds needy. Designer-no-mates waiting for the call back. But you would not believe how often we get ignored by our clients!

Again, we know you and your people are busy, but if you don’t get back to us it simply means we are spending your money working on things we’re not sure we should be working on. It’s a waste of your money.

Call us back. Please.

Review the designs we send you

Reviewing design is tricky. You never feel you have enough time. We always feel you’re taking too long and making too many changes.

There is no getting around this but it helps when we send you the designs on time (hold us to this!) and then you review them as planned. Otherwise we end up with feedback on feedback on feedback and everyone hates everyone.

Make binding decisions

This is my number one rule of being a good client.

Successful projects always have a client with the power to make binding decisions and the gumption to actually make them.

Without binding decisions about scope, direction and signoff projects descend into a spiral of mediocrity, over-runs and appalling compromise.

You will hate this when it happens, so don’t let it happen.

Don’t change your mind too often!

Everyone changes their mind. It’s human and natural.

But on a design project changing your mind leads to a cascade of rework that eats into the project budget and threatens delivery dates. It usually means more money, or less scope, or both.

So although every client has the right to change their mind as often as they like, the best clients rarely do.

Challenge our work and our processes

Good clients make us better designers by challenging our work, our methods, our outputs, our timings, our costs, our designs, our everything (we might grumble, but it’s good for us).

Not-so-good clients leave us to get on with things without ever challenging us and then moan about us afterwards when it’s too late.

Challenge early, challenge often, challenge loudly.

Don’t give us work that’s not important

The sting in the tail: all the rules above are useless if you are giving us work that you don’t care about.

You won’t send the documents, make the people available, review our work, make decisions or challenge us because you just don’t care.

User experience design is expensive. Don’t waste your money on unimportant projects that you don’t care about.

Good clients get great work

That’s it. It’s not hard to be a good client, but it is surprisingly rare. I can count on one hand the clients who have followed all of these rules.

But that handful of clients got incredible work. They saw their businesses improve dramatically. They got promoted, and promoted again, and promoted again.

What if you’re already doing this stuff and still getting bad work? Then you need a new user experience agency…

Let me know what you think on @myddelton. I wrote this working at cxpartners in London. Great projects are always a partnership between the agency and the client.

The change curve

Let me tell you a story about a thing called the change curve.

It’s a story I can only tell now, months after the events unfolded, because it’s taken that distance to work out what the hell was going on.

And to start we’re going to have to slip back in time…

A time before the fall

Rewind my life one year. I’d just survived the first 12 months of working for a proper UX agency. No one had found me out as an impostor. I’d done some good work and developed more as a user experience designer than I ever expected to in that time. In fact, almost exactly a year ago, I gave a talk at UX Lisbon to a group of designers about my approach to prototyping. It went down really well.

I was on top of the world and hungry for more responsibility.

In short succession I started line managing people for the first time in my life, got promoted to lead the user experience designers in our London office, and began leading a project team of multiple designers on a huge, complicated, high profile, and interesting project.

This sequence of events propelled me onto the change curve. So let’s quickly explain what the change curve is and then we can get on with the story.

The Kübler-Ross model

Elisabeth Kübler-Ross was a Swiss-American psychiatrist who did a lot of influential work related to death and dying in the 1960s. She was all about helping people to confront the reality of terminal illness and death, which is pretty high on my list of worthwhile life missions.

You already know Kübler-Ross’s work because it’s the five stages of grief. Denial. Anger. Bargaining. Depression. Acceptance. She unveiled these stages in 1969, but over time they’ve come to be used for much more than modelling the stages of grief.

These days the five stages have evolved into the change curve below, which is used as a method of helping people understand their reactions to significant change or upheaval.

Riding the curve

Before I dropped into the change curve I’d spent five years improving my design and research skills with tangible results. As my performance increased over time, so did my confidence in my skills and my future ability to keep improving. A year ago I was confident, happy and hopeful about the future. 

But that was all about to change.

First came the shock, a major change that sent me hurtling into the change curve. In my case this was taking responsibility for other people’s output, their happiness at work, and their development as designers. Up until that point I’d only ever had to focus on my own output, happiness and development - but when I started focusing on supporting other people, the tools and methods I had used on myself were clearly insufficient and I had very little idea what to do.

The denial came next. The honest truth is I never even registered the shock at the time. For months and months I thought I was doing a wonderful job when in fact the quality of my project work was slipping and I was treating my colleagues like children. The thing about denial is that it’s incredibly, invisibly powerful - you would think you’d spot it in yourself but you don’t. In the end it took some very direct feedback from my colleagues and my girlfriend to help me realise just how much I was struggling.

Then flowed the anger. And boy did I get angry. With the job. With the project. With my colleagues. With my girlfriend. With the prototype I was building. And, on one unforgettable late night, with a web font that simply would not work when I uploaded it to the server. The thing about the angry stage is it’s happening right when your performance is falling off a cliff, so it’s a powerful front to avoid taking responsibility for the way things are going wrong. It’s the part of the change curve that I am most ashamed of when I look back.

The depression quickly followed. For me this set in once the crunch project was over, and it sat with me for a while because I went away to New Zealand for a month. It was not my happiest holiday ever. During that time I started to glimpse what had really been going on: I was out of my depth and didn’t know what to do about it. They say that the depression stage is a kind of early-acceptance but one where you are still emotionally attached to the things you are accepting, which is what makes it so fucking difficult. I kind of feel like I don’t need to tell you about depression. It’s the very bottom of the change curve for a reason.

And, eventually, the acceptance. After New Zealand, and after another painful four weeks on the project, I started to privately and publicly accept the scale of my failure and own up to the many things I had done wrong. Honestly, this all started from some brave, direct feedback from my colleagues in a sprint retrospective. I gradually saw the scale of the task ahead of me, which was that taking responsibility for more than my own work required a radical rethink about how I approach the act of work in general. I stopped being in denial. I stopped being angry. And although it sounds like this would make you more depressed, actually holding my hands up and saying these things are my fault was a huge relief, so I left the depression behind as well.

Finally, integration. This is where you experiment with new approaches and then adopt the ones that help you raise your performance in your new, changed, situation. I’ve been doing a lot of thinking, reading, training, and experimenting in the art of leading teams. I’ve been doing a lot of listening too. Some of it works, some of it doesn’t, but my future feels interesting and hopeful again. It’s not the same future that I envisaged a year ago - lots more about working effectively with other people and lots less about interaction design patterns and research methods - but that’s the thing about change: it does involve making changes.

Mental models for mental problems

It’s been a rough year if I’m honest.

But I can pinpoint exactly when things turned around. At about 4.00pm on Thursday 16 April someone that I trust scribbled this change curve down on a piece of paper and said, look, Will, this is what you have been going through.

In an instant, my whole year made sense. I saw my life on that curve - shock, denial, anger, depression, acceptance - and it gave me a sudden burst of hope that there was a way forward.

I love a simple model that helps us understand a messy situation. I love being able to put the right words on complicated things in a way that brings a sudden clarity.

That’s why I wanted to share this story. Maybe it’ll do the same for you.

Thanks to everyone who went on this journey with me, but in particular to those who gave me the feedback I needed. You know who you are.

Scientists, designers and The Truth

This feels heretical for a user experience designer to say, but it’s been bugging the hell out of me for a couple of years, so here goes…

Design research is not about uncovering The Truth.

We are not getting at The Truth when we do user interviews, usability tests and contextual enquiries. What we’re doing is trying to learn enough to Make Something Better. This is a slightly more ambitious version of making something happen, something I've written about before, a couple of times.

This doesn’t mean I don’t value design research. It’s hands-down the most important part of my job and will continue to be. It’s just that it’s not scientific research, or hard evidence, or proof, or reflective of some kind of universal truth.

And I’m tired of hearing people talk about it as if it is.

The difference between science and business data

Jaron Lanier has a great passage in his otherwise-flawed book Who Owns The Future? where he talks about the differences between the use of data in the scientific/academic world and in business.

I am going to grossly oversimplify here, but his point is that scientific research and business research seem superficially similar because they have attributes that you can easily map from one to the other:

1. They are both done by ‘researchers’
2. They both involve a methodology to eliminate biases
3. They both involve collecting data, statistical and/or qualitative
4. They end with a statement of truth.

But these superficial similarities mask two vastly different realities.

Scientists search for The Truth

Scientific research is concerned with uncovering The Truth.

Scientists, the people searching for The Truth, spend decades working on incredibly specific problems. It is not unusual for them to throw away years of research because of a tiny error in their methodology.

Their methodologies are designed to carefully isolate single variables (if they’re lucky enough to be physicists) or to compare small groups of variables (if they’re lucky enough to be biologists) or to attempt comparisons between huge groups of variables (if they have the misfortune to be economists). Go and read how Daniel Kahneman set up the experiments to find out the truths we all misrepresent fromThinking Fast and Slow. Meticulous.

Their collection of evidence is even more painstaking. I don’t know what you know about statistics, but statistical significance is only the tip of the iceberg. Scientists deal in measures of statistical validity that we have never heard of. Every measurement is understood in terms of error bars. When did you last see an error bar?

Finally, it comes to stating The Truth. This cannot happen without publishing everything - the hypotheses, the meticulous details of the methodologies, the raw data collected during all the experiments, even the calculations used to process the data.

Only then can this research claim to be The Truth.

And still it will be attacked and probed and questioned by experts from all over world. In fact, the very premise of being The Truth requires you to accept it always remains a hypothesis waiting to be 'falsified’ by another, better-designed experiment.

That’s how scientific research finds The Truth. It literally takes centuries of painstaking specific detail being added to painstaking specific detail. Standing on the shoulders of giants and all that.

Now, let’s compare that to design research…

Designers fight to make something better

Design research is about fighting to Make Something Better. Because if we don’t fight, nothing will happen, and it’s all a waste of time.

Designers, the people fighting to Make Something Better, do not just work on one incredibly specific thing. We definitely do not have years and decades to Make Something Better. If you’re lucky you’ll have months, but usually it’s weeks or days.

Our methodologies are designed to fit inside a few months (if you’ve got an enormous budget), a few weeks (if you work at a user-centred design consultancy) or wherever the hell they can among the chaos that is working in a business (most of the rest of the world). They are not designed to isolate variables beyond cursory attempts to eliminate the biggest biases and leading questions. When was the last time you threw away your research because of a methodological error?

Our collection of evidence is haphazard. Where statistics are used, the sample sizes are incredibly small, there is almost never any use of error bars or confidence intervals. Where we go qualitative, interesting quotes are cherry picked to make specific points. Patterns are detected and amplified into stories because that’s what you need to Make Something Happen. In all honesty, our research is rarely subjected to even socialscience levels of rigour.

Finally it comes time to Make Something Better. We might summarise our goals (changed many times throughout the project), show a high level outline of methodologies (usually in bullet points), publish a tiny fraction of the raw data to a tiny audience (some quotes and video clips) and make some massive generalisations (like design principles).

Only then can this research start to Make Something Better.

And still the likelihood is it will be glanced over, forgotten and nothing will happen. Because it’s a messy world and there are people.

That’s how design research gets to Make Something Better. It’s a desperate search for answers to too many questions followed by a headlong dash to assemble them into something as convincing as you can possibly muster.

They’re different, and that’s OK

So, scientific research and design research sound similar when you talk about the nouns (researchers, methodology, evidence, data, analysis, conclusion) but they are actually very different when you fill in all the verbs (share/summarise, publish/present, prove/convince).

None of this is to say that one method is better or worse than the other. They are different. They have different goals.

If you want to find The Truth, don’t use design research because it will be falsified by a high school student in minutes. She’ll tear apart your methodology ruthlessly.

If you want to Make Something Better, don’t use the scientific method because you’ll still be working on the first premise long after your company goes bust.

The correct response to this is NOT to try and make design research 'more scientific’. Yes, we should attempt to eliminate biases but we must never lost sight of the fact that we are here to Make Something Better. Finding The Truth just takes more time than we have available, and is mostly unnecessary in any case.

If you want a stark reminder of the differences between our two different worlds, remember that it’s OK for scientists to use Comic Sans. When physicists at CERN found the Higgs’ Boson their choice of typeface was mocked in the design world, but it didn’t invalidate their work. Because they had found The Truth and history doesn’t care about the typeface that the The Truth is written in.

Try doing that as a designer.

Making things better is hard enough

I’m not saying we shouldn’t do research. I’m definitely not saying we shouldn’t try to avoid biases. I’m just saying we need to be aware of the differences between these two superficially-similar methods. They are both types of 'research’, yes, but you shouldn’t be using language from one method if you’re actually deploying the other.

For example, I get sick of hearing designers saying they have 'proved’ something with user research. For designers, research is about action, not proof. Tell me how your design research led to something better happening in the world, not what you think you 'proved’. All our proofs are subject to change. Times change. Contexts change.

This kind of lazy talk leads to something else that I am growing weary of, which is hearing clients demand that we find out The Truth. We should come clean: we don’t have access to The Truth and we should stop talking as if we do.

Because our truth is we don’t need The Truth to do great design work.

What we need is a bunch of design research tools to Make Something Better. Because design is usually a wicked problem, not a simple equation, and 'better’ is the best you can do with wicked problems. There is never a 'right’ answer. The Truth is an expensive mirage.

And actually, for most businesses (and charities, and governments, and in fact nearly everyone) even just being able to Make Something Happen is the most precious thing imaginable, because it’s in the doing of new things that people learn how to do newer and better things themselves in the future. Teach a woman to fish and all that…