Guerrilla empathy (or why we should probably stop banging on about users all the time)

If you work anywhere near digital design, someone has probably talked at you about empathy recently. Or you’ve talked at people about empathy. Empathy is a buzzword du jour.

Now, you and i know empathy is important but – the reality is, most of the people we work with don’t really believe that. They’d don’t. They think they do real work and they think that we are like tree-huggers but for users.

Banging on about empathy while they are trying to do their ‘real jobs’ doesn’t help get them to care about users more. We need to take a more empathetic approach to empathy.

Guerrilla empathy perhaps.

Here are some things we know.

  1. If we work in multidisciplinary teams where research is done regularly and everyone (including senior stake holders) observe users for at least 2 hours every six weeks, we make better services. Our friends at UIE (thanks Jared) did research to evidence this. Everyone watching users use our stuff regularly helps us make better stuff.
  2. People (say they) love to use evidence to make decisions. They love data. User research provides evidence. If you take a methodical, hypothesis led approach to user research, your team learns about what works and what doesn’t so it can make things work better. (Qualitative evidence is data too).
  3. Businesses care about business outcomes – this might be policy outcomes, compliance rates, fraud reduction, members sign ups or sales. We know that making all of these things work better is always easier if end users understand what you are trying to tell them and can actually do the thing you are wanting them to do. Good usability helps achieve business outcomes.

So, in doing user research (which can build empathy) there are at least three things that business wants that we can supply: better services, evidence for decision making and achieving business outcomes.

We need to talk more about these three things.

And then we need to not let them forget the bit in part 1 that requires them to come observe real users regularly in order for it to work. And we need to make sure that we do the work in a way that really focusses on delivering these benefits for the business. And then you have a much more compelling reason for people to come observe users.

Get people to observe end users regularly in order to meet their business objectives and – unless you have an organisation full of sociopaths – empathy will naturally follow. Without you even mentioning it.

An empathetic team is transformational. But empathy is difficult to sell – especially to the senior stakeholders who need it the most. Business outcomes are not hard to sell.

Do empathy by stealth. Stop talking about empathy. Let empathy be the by-product of helping your organisation meet its objectives through user research and demonstrate this by taking a methodical, collaborative, hypothesis driven approach to your work.

Then stand back and wonder, yet again, at empathy’s power to transform teams and organisations.

Stop your team using technical terms and jargon

Most weeks I am ridiculed by someone for insisting on plain language – avoiding acronyms and technical language / jargon in particular. People tell me that I’m slowing the team down by making them use proper words, and that their end users or stakeholders expect them to use technical language.

These things are both true. You should still use plain language.

Technical language is exclusive.

If you know all the fancy terminology then you’re allowed to fully participate, if not, you’re at least partially excluded. This is unfriendly and can also severely limit the number and type of people who can fully contribute to the work your team is doing.

Recently someone insisted that they needed an incredibly experienced and excellent user researcher who was an expert in all the technologies associated with commercial banking. Do you know how many of those people their are in the entire world… not many.

Do you really want to make hiring that hard for yourself?

If you use plain English in your team, then more smart people can be involved and help you to think about ways that you can improve. That is a good thing.

Technical language bundles assumptions.

If you are in the business of transforming service design, then you are in the business of questioning assumptions. You are constantly asking – what is this really? how does it really work? is it actually the right thing? does it really need to be that way?

One of the best ways we can do this is to keep questioning things until they are broken down into their most basic parts.

We stop calling things by their name (‘we’re working on the registration form‘) and we start talking about what things do (‘we’re working on a way people can to access health benefits more easily‘).

We can recognise opportunities to design things better and differently by describing and understanding the real intent of each component.

Technical terms and jargon almost always bundle up assumptions about the necessity of a thing that – if unchallenged – allow teams to completely miss the real opportunities for transformation.

Plain language is slower.

Yes, switching to using plain language is slower for those who are proficient in the technical terms. It’s not slower for the rest of us. Anyway, there is no advantage in doing the wrong thing faster. (Or, at least, there shouldn’t be).

Plain language is unexpected.

Yes, your colleagues in banking, government, etc. will be surprised and maybe even scornful when you stop doing the linguistic secret handshake and start using plain language. This is no reason to revert to jargon. This is your chance to change culture, one word at a time. Really, it’s the easiest bit of transformation you can do in your organisation ever single day.

Starting now.

Farewell London Drinks

If you fancy one last drink and/or chat before I head back to Australia, I’d be very happy to see you next Wednesday evening, 9 September.

I’m optimistically suggesting the Queen Elizabeth Hall Roof Garden at South Bank sometime between 6pm-8.30pm.

(The weather will turn beautiful once the kids go back to school, right?)

If you fancy coming, add yourself to this Facebook event so I can let you know where we’re going if the weather is not cooperative.

Coming home

I’ve got some news.

I’ve been in London for almost ten years now, but I’m an Australian, and I’m excited to be heading home to Sydney in September to continue the mission to bring great service design and user experience to government by joining the Digital Transformation Office.

I’ll be helping the DTO build a great service design practice, working with user researchers, designers, content designers, accessibility experts and data analysts who will help to make Australian government services simpler, clearer, faster and more humane.

It has been a real privilege to be a part of the team at GDS – I’ve learned a lot from my time working with this talented and dedicated team, and being a part of government in the UK. I’m proud of what we have achieved.

I’m particularly proud to leave behind a government who now has many talented and experienced user researchers working tirelessly to understand user needs and to work with teams to ensure that the services we design meet those needs. Not just in GDS, but in almost every department you can think of.

I’m excited to take what we’ve learned and bring it home to Australia and see if we can’t just do some things even better :)

Thank you GDS, thank you UK UX Community, and thank you London. I’ll miss you a lot.

And, hello Sydney. If you fancy being a part of this next adventure, you should get in touch.