Death to ‘it depends’

Lately I find myself on a mission for mass simplification. Possibly over simplification, but I’m not sure it matters.

It’s one of the things I care most about at the moment – how can we simplify what we are asking people to do so that there is nothing else they can do but start doing it, instead of following their natural inclination to make a list, hire a consultant, write a white paper, do anything but doing the thing.

It requires that I stop saying (or even thinking) one of the things I have probably said most in my entire working life – ‘it depends’. That’s hard, but I think it’s the right thing to do.

It depends is paralysing.

It is a stop sign. It tells people they can’t do anything yet. That it is complicated.

And it presents things as  complicated at a time when the person asking the question usually doesn’t have the capability to understand they subtleties you are trying to explain.

Of course, most things are complex and it usually does depend (on context), but knowing what to do in the face of all of that is less important than just doing something now. Ideally something that gets you on the right track to having the ability to ask more nuanced questions, to have a more sophisticated understanding of the thing you’re doing and the context you’re doing it in.

What does this mean? For me, at the moment, this means trying to create a massively simplified message for teams across government about how they should start doing user research.

Lots of different teams, different projects, different audiences – a whole world of it depends.

Forget all of that. What’s something massively simple that all of them can start doing right now.

Here’s an idea.

  1. Start doing some research in every iteration (we’re all doing agile)
  2. Start by getting 5 or 6 people in a lab, give them the thing you’re making and a task and watch them use it. Talk to them about what they find difficult. Maybe also ask them about how they use the internet in real life, what kind of interaction they’ve had with government before. Don’t explain your thing.
  3. Get as many of your team as you can to observe (hence the lab). Aim for 2 hours every 6 weeks for everyone as a minimum.
  4. Capture what you hear and see on post it notes. Do affinity sorting to analyse research. Write down what you learned (your insights) and what you’re going to do about it. Do those things, come back and do the same in two weeks.

Now lets all start saying this to everyone, every chance we get.

It won’t be the best thing for every project to be doing all the time, but it is way better than doing nothing.

As soon as you start doing this, you will start to learn about different and better things that you can do (if for no other reason than because you’ll need a user researcher to do this and they can tell you. Before you start this, you probably won’t have that person).

Now we just need to do this for all the things…

Related: I watched this video from the ever grumpy but rather clever Russell Davies the other day. He’s scaring the pants of people who are studying to become Planners in the advertising industry and telling them that the best strategy is not the most creative one but the one that actually gets anyone to actually do something.

There’s an interesting section on the value (or not) of research as well.

Help Joy help you. On the unusability of internal systems.

 

I am out here for you. You don’t know what it’s like to be ME out here for YOU. It is an up-at-dawn, pride-swallowing siege that I will never fully tell you about, ok? Help me… help you. Help me, help you. - Jerry Macguire

 

This is Joy’s notebook.

At the airport earlier today I had to switch my ticket from one flight to another. Joy was the customer service person who helped me do this.

Joy’s notebook is about two inches thick, she’s created an A-Z index for it, it is packed full of handwritten notes about how to do different tasks in the various system she uses – steps that need following, codes that need inputting. It sits beside her every day, beautifully decorated (with stickers) evidence of the horrendous usability of the software she uses to get her job done.

Joy has been working for this airline for years. She told me that some of the stuff that is in her notebook she doesn’t need anymore – either because they’ve upgraded to a new system or that, after years, she’s finally managed to memorise it.

She told me that each time they upgrade the system it seems to get harder, not easier, to use. Joy told me that all the customer service reps have a notebook like this. You can’t use the systems without one. Joy is digitally literate and confident with the computer, but it is impossible to use without the notebook.

Joy is frontline staff for a major international airline. She is delightful and doing her best to do great work and look after her customers, but this is what she’s got to work with. I wonder if I’d be so cheerful if I was in her seat. No wonder so many others are not.

Internal systems are the tools we give our frontline staff, the people who are in charge of the customer experience for the face to face and telephone channels. If you pay attention to people using these systems (either out of general professional interest or because you’re fortunate enough to work with the on a project), you’ll find that notebooks like Joy’s are not uncommon. They’re everywhere.

They are everywhere because the people who bought or made the system didn’t even think about the experience for internal staff. The internal staff who are stuck using it are so far away from the people who bought that expensive crap that they’ll never know how awful it is (or their jobs are in peril so they don’t dare complain).

Internal systems allow an organisation to deliver great customer experience throughout the customer journey. These systems let people like Joy be fast (or not), accurate (or not), joined up to the rest of the organisation (or not).

And yet, all the time, we say ‘It does’t matter, we’ll sort that out with training’, ‘Call the tech writers, we’ll make a manual for this system’,  ‘Don’t worry, we’ll inflict this piece of crap on our employees, unlike our customers they’re stuck with us’. Except they’re not really, are they.

This might have worked with Joy but as our employees begin to join our workforces as digital natives, familiar with the well designed exteriors of organisations, how well do you think they’ll take to the tools we offer them to book the tickets, create the content, manage the accounts.

I kind of fancy that they’re going to start telling us to lift our game, to stick our crappy internal systems up our jumpers, and to give them so decent tools so that they can be as efficient as we want them to be. So that they can offer the kind of customer service everyone wants to experience.

I really hope they do. I hope that they will demand that we do allow time to work on the usability of the content management system, not just the website. That a company will be able to win on customer service because they actually bothered to hire design team that lets the customer service people offer faster, better service. That the news company that optimises the content management interface wins because their journalists can write more, better content rather than battle the content management system for hours a day (true story).

And I really hope that one day Joy will be able to stop battling the interfaces she uses to give such great customer service and leave her notebook at home.

If you’re going to do this user experience thing properly, you’ve got to look at all the angles. If you respect for your employees and your customers you need to care about the user experience of internal systems. Challenge yourself to solve the often more difficult design problems of internal systems, and know that by doing that, you’re creating a better user experience for all.