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…

Stop, collaborate!

I just finished an amazing project. The reason it worked so well was that it was the closest I have come to truly creating a collaborative design environment with my client.

I was embedded in their organisation with a small team of people from all sections of their corporate structure and we created a concept prototype that exceeded all their (and, frankly, my own) expectations.

Collaborative design is one of those things that many people talk about but few people do. If you fancy having a go (do it!) here are 12 things I learned about turning a group of non-designers into designers:

Setting the stage
1.  Go where the action is
2.  Frame the problem meticulously
3.  Avoid abstractions at all costs

Creating designers
4.  Force them to draw and draw and draw
5.  Let them come up with the ideas
6.  Explain scary design concepts
7.  Make use of “yes, but we’re not doing that now”
8.  Don’t be afraid to over-rule (but explain why)

Making something new
9.  Design twin (or triplet) prototypes
10. Build the prototypes away from the team
11. Test at least three times
12. Force yourself to move too fast

Warning: this post has turned out to be way longer than expected! If you make it all the way through, tell me you made it on @myddelton.

1. Go where the action is

I spent two days a week for 10 weeks in their offices. We started out in a meeting room and then ended up camped out in a breakout area. I got to know how to use their coffee machines, where all the toilets were and even made some friends with passing people.

This is less comfortable than working from your own desk. It can be annoying to have to commute to a different place. But all you really need is a laptop, pens, post-its, paper and blu-tack to do this.

And being where they were meant that the people I was working with were comfortable. They had access to everything they normally use. It gave me a real sense of what it was like in their organisation.

2. Frame the problem meticulously

They say that 90% of reaching a solution is defining the right problem.

What this means for collaborative design is profound. If you spend a lot of time thinking about what the right problem is, a team of non-designers can start solving problems just as if they were interaction designers very quickly.

The project I worked on was about a system that relied on a lot of data - so we reverse engineered how all the data worked (together) and created a manual for how to interpret the data that was written in plain, simple English (rather than techno-maths). I then made a couple of fake datasets that showed some of the key challenges and interesting points in the data ecosystem. And finally created some worksheets that helped the team calculate what the data meant at different points in the customer journey.

All of this meant that we spent a couple of sessions doing actual maths homework. Looking at the datasets, calculating results and then telling stories about what had happened to these people over time. This work made everyone on the team, none of whom would profess to be that mathsy, completely internalise the structure of the data that was at the heart of the design problem.

Which meant that when it came to designing interfaces they were addressing all of the right issues from the start.

3. Avoid abstractions at all costs

Designers deal in abstractions. Pretty much everything we do is about dealing in abstraction. Normal people are far less comfortable with abstractions - this is why so many people struggle with being presented wireframes, which seem so natural to us.

The way around this is to make things concrete. Use real data. Use real photos. Use real text and real words. Create scenarios that make sense and are believable. If you spend the time doing this, the non-designers you work with will design amazing things.

Also: you should be using a graphic designer on these projects.

We are used to seeing schematics and imposing the future state on them in our mind. Normal people are not. If you work alongside a graphic designer from the start, non-designers will believe in the process much more easily. They will feel like their work has turned into magic. They will show it to colleagues, and their colleagues will get it.

Graphic designers take the logical work and make it emotionally accessible. This is invaluable. I was lucky to work with Luke Jones on this project and his work was amazing.

4. Force them to draw and draw and draw

Everyone can draw. Just like everyone can do maths. People have just been made to be scared of it by terrible teaching experiences in school (“you’re not good at art”).

Fuck that.

Make them sketch. Make it safe. Explain that they can’t get it wrong. Put them in small teams so responsibility is shared (but make sure they all draw). Give them the right tools (sharpies, coloured markers and good A3 paper will do). Introduce the idea of 6-up sketching early on and keep hammering it. Get them to present their work, even though they will hate it at first.

And then do it again. And again. And again and again and again. Trust me, by the third or fourth time they will have completely forgotten about their hangups and will be sketching interfaces like interaction designers. I am serious and I have the evidence to prove it.

5. Let them come up with the ideas

You are (probably) the design expert. But they will come up with all of the ideas you have (and more) if you frame the question right, give them time to experiment, and go through multiple open, friendly critique sessions with them.

This is a much better way to work.

Get them to sketch in small teams as above and then present back to the group. Stick the sketches on a wall. Ask questions constantly about why things are the way they are. Record things that come up on post it notes (partly for afterwards but MOSTLY to show that you are listening and taking it seriously).

Get everyone else to ask questions too, but enforce design critique rules. No design suggestions, only questions. No criticisms, only questions. Questions, questions, questions. (You will have to play the part of ‘translator’ initially - listening to a criticism or a design solution and reframing it as a question - but they will quickly learn). Make this critique really safe for people. Find elements in everyone’s work that are great ideas (they are always there) and talk about them.

You may have a vision in your head for how the designs should look. That’s fine. But if you do it right, they will come up with 90% of your vision, one way or another, themselves. It’s so much more powerful if they reach the conclusions themselves without being told what to do.

6. Explain scary design concepts

During the critique you will constantly come up with things that you have internalised as a designer but they have never seen before. Things like the problems of too much choice on one page. Or putting a feature on a page or in the navigation when it can be achieved in a different way.

Don’t be afraid to explain your understanding of what is going on. Take the time to go through the issues of choice and complexity. Outline how the same thing could be achieved in a different way.

They are all intelligent humans. If you take the time to talk it through with them, it might take multiple attempts (old ideas are hard to shake) but they’ll end up thinking like designers.

7. Make use of “yes, but we’re not doing that now”

People are amazing at finding edge cases. Seriously. If you’re in a team of people from your client’s organisation you will find they generate edge case after edge case after edge case.

And however good your non-designers become at design, they are not going to address all the edge cases. That is the kind of detailed work that really is better to leave to a designer on their own later on.

But you need to address the edge cases as they come up.

The way I did this is to clearly isolate the problem we are working on (this type of person, with this goal, with this information) and then put everything else in the “yes, but we’re not doing that now” bucket. This can be a large bucket. It’s a bucket that will get visited and revisited again and again throughout the process. But it’s critical to helping people forget the millions of details and focus on the core problem. We do this naturally as designers, others find it really hard, so make the contents of this bucket highly visible and highly talked about.

There are some edge cases that become so important that you need to address them by talking about how they can be dealt with. Try to keep this to a conversation rather than actual design work. Outline how that case might fit into the design (you might need to do some thinking about this away from the group) and then put the expanded edge case back in the bucket.

This is all assuming you have meticulously framed the problem you are working on. If you haven’t, you’re in real trouble.

8. Don’t be afraid to over-rule (but explain why)

Collaborative design is not about just letting your non-designers do all of the design themselves. You need to end up with something that works, and sometimes this will mean you need to step in and over-rule.

Now it’s much much better to not have to do this. Framing the problem meticulously gets you a long way to good solutions. Well-facilitated critique sessions and iterations with clear instructions ('think this time about restricting the number of choices on this page’) get you most of the rest of the way.

But sometimes you need to intervene and change things.

When you do this, flag it up and acknowledge that this is what you are doing (do NOT try and do it by stealth, or behind their backs). And most importantly, explain really clearly WHY you are doing the things you are doing (hint: if you can’t explain it clearly, maybe you shouldn’t be doing it). It might be that there’s not enough time to build the interaction before the test. It might be that it introduces a logical inconsistency that you know will compromise other aspects of the design. It might be that it’s against decades of good practice in human-computer interaction.

Whatever it is, explain why you are making the decision.

9. Design twin (or triplet) prototypes

There are always too many design ideas for a single prototype. In fact, like Leisa says, if you haven’t got multiple solutions to the problem in your pocket as a designer, you’re not really doing your job right.

So build at least two, preferably three, prototypes for the first round of user testing. Let people put their pet features in. Go deliberately wild with different approaches. Don’t be afraid to test things that bomb - people learn loads from seeing an idea they have held onto throughout the process come into contact with the user. In fact I would say you should preserve some of the most strongly held ideas until they see the light of day in testing (not least because often we are dead wrong about what will work and what won’t).

Make sure you explain that it’s not prototype A versus prototype B - but that the different prototypes are simply vehicles for testing different hypotheses. Like is it better to show all items, or just the most important items? Or does it work better to give the user control over setting goals or to set the goals for them?

But make sure that each prototype is internally consistent. Each concept needs to work in its own skin. This is tricky. And where your expertise really counts.

10. Build the prototypes away from the team

Make sure the whole team knows what is going into the prototype. Post-it out all the pages and flows you will be testing. Show them which of their design ideas from the sketching sessions are going into which areas of the prototypes (and which aren’t - but explain why).

But then go away and build the prototype yourself.

This work is not collaborative in the same way that generating ideas and critiquing approaches is. You need the time to push pixels around. And it’s also a chance to impose some of your expertise on the ideas from the sketching sessions, to iron out some of the kinks.

Then come back and show the prototypes to the team, pointing out where all their ideas are incorporated and how they have been implemented. Suddenly seeing their sketched ideas stitched up into a beautiful, working mini-version of a website will be one of the best moments of the whole process. Savour it.

11. Test at least three times

I would go so far as to say that this whole process won’t work if you don’t have at least three rounds of testing. You may JUST be able to get away with two, but you won’t have the freedom to let your team experiment with their own ideas in the first round of testing and you’ll end up doing so much over-ruling that you destroy the whole thing.

It’s also really really really really important that the whole team comes along to all of the tests. It’s the feedback loop of designing things and seeing how people react to them that turns non-designers into designers quicker than almost anything else (except maybe sketching).

On this project there was one non-designer in particular who seemed really interested in the testing work. So, in the spirit of collaboration, she stepped in and moderated some of the testing sessions in the final round herself. And she was amazing. Treat your team like designers and they end up acting like designers.

And don’t document the testing sessions formally. Get all of your team to watch, take notes and give them the opportunity to ask their own questions at the end of each session. Then the next day run a full debrief (multiple hours) where you put printouts of the prototype screens up on the wall and work through all the insights and observations. Make sure you discuss the reasons and possible solutions and bring your designer insight into these conversations too. This is a supercharged environment for learning to be a designer - seeing your own work interact with real users, and then talking about what you all saw together as a group.

End these debrief sessions with a high level plan of what you are going to do in the next session.

12. Force yourself to move too fast

The thing that always comes out of this process is that iteration is what makes the difference. Iteration in sketching sessions - do one, present, critique, do another, present, critique, do yet another, present, critique. And iteration in testing - design two protoypes, test, debrief, design a single prototype, test, debrief, redesign the prototype, test, debrief.

You need a tool to force yourself to iterate. That tool is the calendar. If you don’t force yourself, your time will slip and you’ll lose iterations.

Set user testing sessions at the start of the project at two week intervals. Any longer and you will be navel gazing. You WANT it to feel rushed, because when it feels rushed you only ever concentrate on the most important stuff. It might not FEEL right, but it definitely IS right. Too much time between iterations is a killer.

The same applies to sketching - cut people off when they are still asking for more time - they’ll get better and quicker as time goes on.

Establish a routine around these testing sessions, including:

• time to plan yourself (away from team)
• sketching sessions to design and critique things (collaborative)
• planning the prototype structure and flows  (collaborative)
• building prototype and discussion guide (away from team)
• testing session (collaborative)
• prototype debrief session (collaborative)

We did two week sprints and we had the non-designers for 2 days each week. That’s two days of sketching and planning week one, and two days of reviewing and testing and debriefing in week two. 

Final word of warning: don’t dive straight into sprints. You need time up front for discovery and bonding as a team and framing the questions. A couple of weeks at least. But make sure you set the dates for the testing at the start of the project as this will hold you to them.

A better way?

I thought this was going to be a quick post. I didn’t realise how much I had to say about it.

The thing is, working like this is talked about a lot, but rarely done in practice. Having actually done it myself, in the flesh, with all the glory and all the pain, I can safely say that it was an amazing experience. It’s how I want to do design as a consultant - at least for those early stages of helping an organisation completely rethink the future of its product.

We built a prototype that no one thought was remotely possible at the start. It tested well to start with, then better and better as we went on. It addressed some hideously complex problems but we found answers.

And while the users loved it, that’s nothing compared to the organisation. It’s been going viral - partly because it’s a clickable believable prototype, partly because it’s high fidelity and looks like the real thing, but mostly because the people that worked on it are pushing it on everyone they know or come across in their own organisation.

I’ve written before (a lot!) about how the biggest problem with user experience consultancy is that so much of the time our work doesn’t get built, mostly because the organisation doesn’t 'own’ it or 'know’ what to do with it.

This is the opposite. It ended with something good and tangible. I’ve left a team of people who have internalised all sorts of critical design concepts. The organisation is excited. I had a great time doing it.

But I think the thing that I learned most was - if you trust people and take the time to give them the tools they need to design, the output will be miles better than if you had done it alone. I started thinking this was about buy in, but I ended thinking this is simply about good design.

Go, collaborate…

Conceptual integrity

I was listening to an interesting off-topic podcast when a charming philosopher called Peter Hacker popped up and said this:

If the conceptual framework is awry then incoherence ensues. Questions that make no sense will be asked. Experiments will be designed to answer questions that make no sense. And the results of experiments will be misunderstood and misinterpreted. These are serious matters.

He was attacking the foundations of modern neuroscience. But it rang so many bells for me that I stopped in the middle of St James’s Park to rewind and write it down.

Because I see this in businesses I work with all the time - smart, motivated people working really hard to find answers to questions that just don’t make sense. It’s maddening.

In fact, user experience designers get so frustrated with this that we often end up blaming the visible tools used to get these answers (web analytics, A/B testing, focus groups) rather than the invisible assumptions that led to the questions.

So where do these assumptions come from?

They come from what Peter Hacker calls the conceptual framework. Or what Dorian Taylor, in one of my current favourite posts on user experience design, calls ‘conceptual integrity’:

The chief export of the principal user experience professional on the scene is conceptual integrity—a term I see and hear far too scarcely in this line of work. To borrow from Brooks again, who, by the way, coined the term in the 1970s, conceptual integrity is the state when the mental model of both the user and application is unified across the whole team, lest there otherwise be a different mental model for every person on the team.

Developing and communicating conceptual integrity is a lovely way to think about the user experience work we already do in organisations.

And if it channels the energy of all of the smart, motivated people working in organisation in a more productive direction, then it’s a challenge that I like the sound of…

5 levels

I’ve been a user experience consultant for a few years now and I’ve noticed there are 5 Levels of success for consulting projects.

I’ve outlined the 5 Levels below from the most fundamental to the most advanced. The idea is that the further up the 5 Levels you can push your projects the more successful they will be.

Just remember this is all from the perspective of an external user experience consultant, not an in-house designer.

Level 1. Get paid

The first and most basic level of success is getting paid.

Money might be a blunt measure of success but it’s important for consultants. Unless you are getting paid, specifically getting paid what you agreed (and not taking longer than you planned for), your project is not a even a Level 1 success.

Working for free is not success. Billing for 10 days and working for 30 days is not success. Billing for 10 days and working for 10 days and then failing to chase the invoice is not success.

This is why I love project managers and finance people. They help us stick to the timelines we set and make sure we get paid. And it’s why I hate it when someone declares they will ‘overdeliver’ on a project midway through because someone didn’t plan things or manage scope.

Your project is a Level 1 success when you see the right money in the bank. The skills you need for this are about pitching, planning, managing time and being honest with clients about scope.

Level 2. Make the client happy

It’s perfectly possible to get paid without making your client happy. If you’ve got a strong contract (you should have) you’ll get paid anyway.

But in the long run getting paid by unhappy clients is pretty close to selling snake oil. You won’t get invited back. You’ll need to move on and dupe new clients. And you’ll feel terrible if you have a heart.

Happy clients are essential for success beyond simply making money. They lead to repeat business and spread your reputation.

So your project is a Level 2 success when your client wants to work with you again. The skills you need for this are listening to, collaborating with and empathising with clients.

Level 3. Do yourself proud

Happy clients are not enough though. This is because it’s possible for consultants to make clients happy without doing great work. 

Maybe your involvement pushed them towards a promotion. Perhaps you helped them spend their end of year budget. Sometimes a client may not know enough to tell a success from a failure (that’s why they hired you). Or maybe you just got on with them really well. 

If you want Level 3 success you need to hold yourself to a higher standard about what constitutes a good job.

This is a gut feeling. I’m not going to define what it means as it’s different for everyone. But you know when you’ve done a good job and when you’ve cut corners.

There’s another dimension too. For me, and probably for you, being a consultant isn’t just about the money. This is about how you spend the finite time you have available on this planet. You want to do good work.

Which means your project is a Level 3 success when it stands a chance of going into your own portfolio. The skills you need for this are your design education (however you came by it), the technical and creative skills you’ve honed, and old-fashioned professional integrity.

Level 4. Get it built

Ha! Now we come to the sharp end. It’s relatively easy, given the right conditions and experience, to get paid, make the client happy and feel like you’ve done a good job.

Many consulting projects end at this point.

These projects can make you feel good. You can talk about the great research you did, and the amazing process you went through to get to the final designs. You can present at conferences and blog about it.

But is it a success if nothing happens next? I don’t think so.

When you are an external consultant, getting things built is about way more than research and design. You need to understand your client and their business so you can deliver appropriate work. You might have to take the risk of developing a vision of the future, pitching it to your client’s business, and helping them transform their organisation.

In many ways it’s easier to never build anything. While things stay on the drawing board they can seem like the best ideas ever, whereas putting them in the world runs the risk of personal failure.

However it happens, your project is a Level 4 success when you can point to it out in the wild. The skills you need are about prioritising, co-ordinating, politicking and sometimes inspiring others.

Level 5. Change the world

Finally, the ultimate arbiter. Did your project make a difference? To a company’s bottom line? To somebody’s life? To anything?

After three years of consulting I haven’t changed the world nearly as much as I expected to through user experience design. I can count on one hand the number of projects that have made a truly meaningful impact to people’s lives or a company’s bottom line.

Yet to all intents and purposes I’m a successful consultant. Billed a lot of money. Made loads of clients happy. Done plenty of projects that I’m proud of. Even got a bunch of designs live in the world.

And that’s why these 5 Levels matter. They help me see that many things that look like successes are not successes at all. 

Your project is a Level 5 success when it changes the world in ways that are clearly and unambiguously obvious. The skills you need for this are a combination of everything already mentioned plus, frankly, a healthy dose of luck.

The 5 levels revisited

• Level 1 - Get Paid
  Indicator: money in the bank for the time spent
  Skills: pitching, planning, managing time and handling scope creep
• Level 2 - Make Clients Happy
  Indicator: repeat business from clients
  Skills: listening to, collaborating with and empathising with your clients
• Level 3 - Do Yourself Proud
  Indicator: personal satisfaction with the project
  Skills: design education, technical/creative skills and integrity
• Level 4 - Get It Built
  Indicator: seeing your designs in the world
  Skills: prioritising, co-ordinating, politicking, inspiring others
• Level 5 - Change The World
  Indicator: obvious evidence of real change
  Skills: everything listed so far plus a dollop of luck

One more thing. The 5 Levels are cumulative. Your design project can’t get to Level 3 without reaching both Level 1 and Level 2.

This means you can’t feel smug and successful for doing a great job (Level 3) if you didn’t get paid what was agreed (failed Level 1) or if you didn’t make the client happy (failed Level 2).

It means you can’t claim success for getting any old rubbish built (Level 4), because if you know in your heart it’s rubbish then you know you didn’t do a good job (failed Level 3). I love the 'good designers ship’ philosophy but only up to a point. Garbage is still garbage, no matter how quickly you release it.

OK. But so what?

Thinking about the 5 Levels leads to two inescapable conclusions.

First, the foundations of successful projects are consulting skills (not design skills). Planning your work, having tough conversations about scope and listening to your client are critical to success. Unless you can do these it simply doesn’t matter how good your design skills are. And I suspect that many of us in user experience spend too much time on design skills and too little on consulting skills.

Secondly, truly successful projects must change the world. Clients are not paying us hard cash to do interesting stuff for its own sake. Unless you can get stuff built that makes a difference it doesn’t matter how good your design skills are. And, again, I suspect many of us in user experience spend too much time on design skills and too little on working out what skills it really takes to make things happen.

Or put another way. If you are a user experience consultant, the design and research is only half the story. At most.

Nothing's your fault *

I’ve been working as a user experience consultant for large clients for about eighteen months. One thing bugs me more than anything else.

So much of the time, nothing gets done.

You start user experience consulting with lofty ideas about matching business goals against user needs to uncover a holy grail for your clients. And it feels like that at the start - doing research, interviewing stakeholders, sketching ideas, writing scenarios, creating prototypes, testing with real users, iterating, and packaging it up ready to build.

The kind of user experience design you read about in books.

But as the projects stacked up I couldn’t avoid noticing how much of my work went nowhere - or worse, limped along with pieces getting hacked off along the way. At first I shrugged it off. Probably blamed the client. Then I wondered whether my work was good enough. But I slowly saw that I hadn’t yet grasped the true nature of my job.

Which is that even the best user experience design is totally irrelevant if your client does nothing with it. 

It’s always easy to do nothing

There’s all sorts of reasons why clients do nothing. Here are a few.

Sometimes their priorities change. Mike Monteiro says never work on a project that isn’t the organisation’s top priority. That’s golden advice. 

Sometimes they can’t do what you propose - maybe they’re shackled to legacy IT systems, maybe they’re so heavily regulated your suggestions are illegal, maybe the employees simply don’t have the skills to make your plans real. 

An awful lot of the time, they do nothing because they don’t know what to do next. The project sounds fine when you’re presenting, but when you leave there’s a lot of head scratching. No one wants to admit they didn’t understand what the consultant said.

It may sound like I’m blaming clients. But I’m not.

Nothing is my responsibility

These days, when nothing happens, I take the blame. (Yes, sometimes clients may be at fault, but this is a more productive starting point).

Easy to say. But what does this really mean for a UX consultant?

It’s your responsibility to decide whether or not the client is serious about the project. Don’t take it on if they’re not (OK, this is totally impractical for me right now but a man can dream!).

It’s your responsibility to assess what capacities and appetites the client has before designing anything - if they’re using Sharepoint, it better work in Sharepoint; if they’re heavily regulated, run every iteration past the legal guys; if they lack core skills, convince them to hire or avoid that area entirely; and if they have no appetite to do new things, don’t do new things!

But most of all it’s your responsibility to make sure your client ‘gets’ your work. This kind of communication is really hard. We’re so close to projects we forget how complex they are. It means involving clients at every step. Continuing to explain things way past the point when you are bored with your own ideas. And spending more time on communicating the design than you expect to. Much, much more.

Since taking responsibility for nothing happening has everything gone smoothly? No, of course not. But several projects that once seemed doomed are now on the verge of success. And I sleep better.

This is not a universal truth of UX

This side of UX design - consulting for large organisations - is not for everyone. User experience design is a broad church. This verges on organisational change and the pace can be glacial.

More specialist designers and Agile UXers will be rolling their eyes right now. That’s fine. It’s a big world. You have your problems, I have mine. (In fact, we need each other, but that’s another story).

And many consultants don’t care. They get paid whether the project gets implemented or not, and there’s plenty more fish in the barrel.

I do care though. Partly because I’m selfish and I hate wasting my time. But mostly because I remember what it was like to be a client, baffled and confused by consultants. And I remember looking at their bills, and then at their work, and wondering why nothing was happening…

Say hello on @myddelton. A huge thank you to all my clients who’ve helped me understand what this job is all about. And the same to Leisa Reichelt and Mike Monteiro who basically said all of this already…

* Or is it?

The year of ThisIsMyJam

My love affair with music died sometime after I gave up trying to be a musician, left Manchester and stopped living with DJs. Without a constant supply of personal recommendations I just got bored.

ThisIsMyJam totally changed that this year. Overnight I had a constant stream of amazing back music in my life.

In a world where too much is thrown at you to pay attention to, the focus on a single song at a time is not only refreshing, it’s the reason it works. Sometimes quality is simply the opposite of quantity.

And in an age where ‘social’ is a dirty word, ThisIsMyJam somehow resurrects the spirit of the mixtapes that I grew up with. Listening to other people’s choices is deep, while putting my own jams out theremakes me feel like I’m 17 again…

2012: a jam odyssey

They saved the best until last though. It’s a hackday present from ThisIsMyJam and myself - the design is theirs, the content mine.

• Myddelton’s 2012 Jam Odyssey

Why can’t all web products be this wonderful?

These are your jams

Of the 1016 jams people gave me in 2012, 199 made it into my Spotify favourites (Spotify link). Did I mention quality? 19.5% is some hit rate…

Shouts to Michelle Adams, Pete Williams, Lucy Hughes, Lisa Drake, Kate Saner, Sophie Scott, Karl Sabino, James Weiner and - of course - Hannah Donovan.

See what I'm listening to right now on ThisIsMyJam…

A pattern library for writing

I don’t know about you, but no one taught me grammar at school.

It’s a massive shame, because grammar is really useful. These days I use it as a pattern library for writing. Like a stencil set, it gives you a collection of predetermined shapes to use when you’re floundering.

Which is helpful, because writing is hard.

Three of my favourite grammar patterns - statements, imperatives and gerunds - come direct from Ginny Redish’s incredible book Letting Go of the Words. It’s up there with Steve Krug. Seriously.

And don’t worry, this stuff’s easy. Trust me!

Statements make great subheadings

Let’s start with the statement pattern. Subheadings are critical on the web and it’s easy to write great ones - avoid nouns and use statements:

• A statement says something. The subheading of this section, ‘Statements make better subheadings than nouns’, is a statement.
• Nouns say very little.  A noun doesn’t say anything, it just gives something a name. Noun equivalents for this subheading might be 'Statements’, or 'Statement subheadings’. Boring.

Look carefully at the subheadings you write. Most of them are nouns, guaranteed. Statements are harder to write but more compelling to read. They force you to commit to actually saying something.

And saying something is always a good thing when you’re writing.

Recommendations start with a verb

The classic research report is a list of insights and recommendations. I use two patterns here: all insights are written as statements (just like subheadings) and all recommendations start with a verb.

• Insights as statements
  'Doctors want practical information, not scientific advice’ 
  'Users are unlikely to register for the site’
  'The customer relationship is with the drug, not your company’
• Recommendations starting with verbs
  'Create materials that focus on practical information’
  'Remove the registration requirement’
  'Build individual sites for products, not a portal’

In fact, the recommendations start with a particular type of verb. This is the imperative pattern. If it can be spoken like the word of god, with an exclamation, it’s an imperative verb. Create! Remember! Fornicate!

(Incidentally, starting with a verb makes for good subheadings too).

Different verb types add depth

Sometimes you need two levels, like when you’re writing instructions. One level to describe the task ('sending an email’) and the other to describe each step ('open your email client’, 'click on new mail’, etc).

This is where I use the gerund pattern. Gerund sounds fancy (it’s Latin!) but it’s just a normal verb which ends with 'ing’.

You can always take an imperative verb (create, remember, fornicate) and turn it into a gerund verb (creating, remembering, fornicating). This gives two levels - tasks are gerunds ('sending an email’, 'logging into the site’, 'resetting your password’) but instructions are imperatives ('open your email’, 'click the login button’, 'enter your address’).

You’ve seen this all over the web.

Go forth and multiply

(See? The word of god loves an imperative or two).

I use these grammar patterns every single day. They are the lines and shapes, the boxes and arrows, of written language.

My favourite grammar pattern of all time is the active voice. It’s the best writing tip you will ever learn. Especially if you’ve had any kind of academic education which involved writing.

But it’s tricky to explain. When I’ve cracked it I’ll let you know…

Say hello on @myddelton. This is my second post about language and design - if you liked it you should read The 'Can’ versus 'Will’ Hack too. Oh, and buy the new edition of Letting Go of the Words by Ginny Redish.

The ‘can’ versus 'will’ hack

There are a million ways you can hack your brain into better habits using language. Changing your words, grammar or how you write sentences will have a huge impact on your behaviour.

This post is about just one - the difference between ‘can’ and 'will’.

There are two areas of user experience design where this can make a big difference - avoiding edge cases and getting things built.

Avoiding edge cases

If you listen carefully to the language of software developers, marketers in large companies, and even some designers, you often hear them talking about designs in terms of what people 'can’ do with them:

• ‘The user can navigate this video using four different control sets’
• ‘People can send this page to a friend or share it on Facebook’
• ‘Users can get to this content by registering with the site’

This is design by wishful thinking. And it leads to wasting time on edge cases. When discussing whether users ‘can’ do something it’s difficult to rule anything out. Like your mum said, just because userscan jump off a cliff doesn’t mean we should design for it…

The opposite? Make sure everyone talks about what users 'will’ do:

• ‘Our primary persona will use the chapter navigation for this video’
• ‘Customers will rarely share content and will copy the URL if they do’
• ‘Users will not see this content because they will not register’

These are stronger claims and they are screaming out for evidence. As soon as you start talking like this, everyone in the room wants to see the research. Which is perfect, because we all want to be making design decisions as a result of research. Right?

So that’s my first language hack. Talk about the user, or persona, or customer, in terms of what they ‘will’ do.

Getting things built

I do lots of strategy work. It’s immensely frustrating because you do great work, come up with a beautiful solution and then tell the client how they 'can’ implement your shiny ideas.

But guess what? Most strategy work sits on the shelf.

Lots of designers moan about clients at this point. But if designers talked more about what clients 'will’ do, not what they 'can’ do, we’d see more progress. Here are some starting points…

Clients will do things they can understand. It’s amazing how many designers, me included, provide work that makes no sense without the designer in the room. Communicating your work is as important as doing the work in the first place. (Honestly, I always forget this!).

Clients will do things that suit them. It’s up to designers to understand the client and offer appropriate solutions. There’s no future in understanding the solution and offering appropriate clients. Which means the best solution is not always the right solution. Seriously.

Clients will do things that are their idea. This is my favourite. Get your client involved in the whole design process, from watching user research to sketching design ideas. They will never stop you being a designer, but you’ll learn loads about what they want and you can trace their ideas in the final output. And they'll glow with pride.

So my second language hack is to talk about what clients 'will’ do, not what they 'can’ do. Take responsibility for action!

Final words

The difference between ‘can’ and ‘will’ is tiny. But it will make a huge difference when talking about design. Let me know how you get on.

Say hello on @myddelton. And yes, this post is an oversimplification to make a point - there are some instances where talking about what people 'can’ do is a good thing. Just not mostly. 

A symbolic victory

America elected Barack Obama again today. It’s some achievement, considering how bad their economy is. But then Mitt Romney never looked like he could win. I was surprised he was the Republican candidate after losing the race to John McCain last time around.

There are plenty of people who are going to talk about the problems with Obama. The fact that he’s not really liberal. His drone attacks. His failure to address the economic problems of his first four years. His attempt to be bi-partisan which pretty much failed.

But I love him.

I love him because he’s a black man, leading the most diverse country on earth. I love him because he’s a great speaker. I love him because he stood up for gay rights. I love him because he’s a Democrat, whatever that means.

And I hate what stood against him.

I hate anyone who oppresses women, or supports anyone who oppresses women, or shares a platform with anyone who oppresses women. I respect your opinion about abortion, but it’s every woman’s right to choose. 

I hate rich, American capitalists who watch the stock market as an indicator of success. 

I hate people who talk about socialised medicine. I’ve met them, and they don’t even know what they are talking about. They can’t even define the thing. 

I hate people who hate gays, blacks, immigrants. Who hate non-believers. Who hate the people that their favourite talk show host hates.

I very, very rarely talk about hate, but in this situation it seems apt.

Symbolism, not real change

Anyway, either way, it feels more like a symbolic victory than a real turning point. America’s political system seems to be, as far as I can tell from listening to American radio and speaking to friends who work there, fucked. Special interests rule. Senators and congresswomen are spending four, five, six hours a day raising money - literally calling up people themselves to ask for money - rather than legislating for the people. And the legislation reflects this reality. Acts that have no special interest get no time.

Obama and the Democrats are as bad as the Republicans for this. Apparently, if you’re on his email list, you got an email every day for six months in the run-up to the election asking you for money. Every single day. Now I know that mathematically that probably works out, but what the fuck is the experience of that? What happens when that stops, and the same old same old continues? How do you feel about politics when your political cycle is two years campaigning followed by two years of failing to get anything of any real meaning done? Seriously.

Apparently the Democrats raised, and spent, a billion dollars. To Romney’s $800 million. And another billion from the super PACs. So you could say that Obama bought the election. Is this a democracy?

The real change is in the demographics

The demographic changes are interesting though. For older people, 81% are white. For people a little younger than me, that drops to 61%. For the age group of 0-8, less than half of Americans are white. Less. Than. Half. That’s pretty staggering.

Latino voters are being added at a rate of 50,000 per month. That’s 50,000 new hispanic voters turning 18 every month. 600,000 each year. Two and a half million in a presidential term. That means that since George Bush Junior won that election in 2000 there are ten million new hispanic votes.

And they won’t necessarily vote Democrat. Like the Eritrean cab driver I had in Indianapolis, who shocked me by saying that he liked Obama, but not as much as he had liked Bush. (Indiana, incidentally, was one of only two states to go from Democrat to Republican last night).

When politics fails, symbolism is enough

But let’s go back to the symbolic victory. A black man, with a black family and a hugely diverse crowd celebrating the diversity of America. You can argue all you want about the policies and the actions. But symbols matter too, and that is a fucking powerful symbol. More powerful than anything we have in the UK, where the dominant symbolism is all Eton and Oxford.

And the women. The women who carried the marginal states. The women who were told they had no control, not only over their pregnancies, but perhaps even over the possibility of pregnancies. Who were told that God wanted them to have the babies they conceived during rape. Mitt Romney, in what was a pretty gracious concession, even managed to thank those who had helped on his campaign ‘and their wives’. Jesus.

Even the symbolic victory rang true there. Obama, surrounded by Michelle and his daughters. Romney, commiserating with his sons, oh, and their wives.

As Mike Monteiro said, never ever underestimate the women.

Hillary up next?

This is my personal, non-American view of what happened last night. If you want to add anything, or berate me, reach out to @myddelton.

Designers don't like user-centred design

I read an article recently that blew my mind. It lamented that three principles of user-centred design – focusing on users, measuring the effect of your designs and using an iterative approach – were being ignored by most designers.

What blew my mind was it was written in 1985. 1985! I thought, from the way everyone talks about them, that these were modern ideas. Yet here were two academics describing the same problems we face today, right down to a passionate call for more prototyping, five years before the web was even invented.

How utterly depressing.

Which got me thinking. What if something else is going on? What if these are still problems because designers never wanted to do them in the first place? That despite all the talking and writing and speaking and podcasting and tweeting about user-centred design, when it comes down to it, designers avoid user-centred design like the plague.

It sounds crazy. So I wondered whether there could be any truth in it.

Why don’t designers like user-centred design?

Let’s start with focusing on users. It’s a gospel that every user experience designer preaches, yet often when you speak to them, and dig around a bit, it turns out that everyone has a different excuse for why they don’t do actually do it very much. Often revolving around time, or money, or difficult clients.

To me the truth seems far more stark. Talking to users means taking their views into account when you design, and actually designers would rather not do that. It’s much easier to throw up your hands and say, well, there’s no budget for that, so let’s just do the best we can in the circumstances. Which turns out to be very close to, let me just design this as I think it should work.

And don’t get me started on measuring your designs. It seems designers love anything that means they can avoid measuring things. Whether it’s the pervasive idea that you only need to test with five random passers-by or yet another UX missionary saying that analytics can only tell us the what, not the why, designers latch on to anti-measurement ideas like a pitbull with lockjaw.*

Why? Because measuring the effect of designs risks that the numbers will show the designs don’t work. So if designers want to just design things like they think they should work, measurement is a threat.

See? There’s a theme developing. Designers avoid principles that clash with their own interest in just making things like they want to.

So finally to iterative design. Seen from the perspective of a designer who only wants to make things like he wants to make them, iterative design is the biggest threat of all. While talking to users and measuring the effect of designs have an indirect impact on your work, using an iterative approach means explicitly acknowledging that the designs are wrong before you start. And worse still, you probably have to listen to someone else telling you exactly what’s wrong with your work.

So the little fantasy world where your design is great, and perfect, and right, comes crashing down.

OK, so what am I saying?

Basically that a lot of designers want to design things as they want them to be, that these three principles of user-centred design are a direct threat to that vision, and so consciously or not they avoid using these principles.

Because let’s face it, designers are persuasive. When we want something to happen, or something to be included in a project, or a process, we’re good at getting it. Look at how much time and money has been wasted on pixel-perfect wireframes over the last decade!

Ergo, if user-centred design principles are missing from projects, it must be because designers don’t want them there in the first place.

* And we wonder why no one gives us a seat at the strategy table…

Let me know what you think on @myddelton. If you want to blow your mind with some history read Designing for Usability (1985) and Myth of the Intuitive (1990).