Why UX research is important

The Why

There’s a story I like to tell and a phrase I like to use. I think the phrase is mine, but I’ve been using it for a while and I can’t really remember. The story was told to me (too close to twenty years ago) by a former colleague, Tom James, who seems to have fallen off the planet (by which I mean he isn’t on LinkedIn or Facebook). I’ll do the story first.

Apparently, in the days before UX was a popular phrase, a call centre company decided to speed up the process of handling calls by building a new piece of software. They did so (without spending any time with the call handlers who would use the system), rolled it out and waited for the improvements. They didn’t arrive.

So, belatedly, they sent someone to observe the system in use and see what was happening. It soon became clear that the system did not allow for real-time use during a call – it was all in the wrong order. To deal with this, call handlers worked through their script and noted the answers on paper, then they opened up the system and populated it. Result: no gains in efficiency.

The phrase I like to use is: “you don’t know your users as well as you think you do”. I didn’t say it was a witty phrase, but it gets to the nub of the problem. If you don’t know your users, and you don’t spend time researching them, you don’t know what they know, you don’t know how they work, you don’t know what they need and you don’t know what frustrates them. In other words, you don’t know a whole bunch of the things you need to know to create a system that they find useful and usable.

A few things happen to systems that aren’t useful and usable; none of them are good. If users have a choice, they’ll probably choose another system – on the web your competition is only a click away. If, as in my story, users don’t have a choice, they may still find ways to avoid using the system. If they can’t avoid using it, they’ll use it badly (we have tested a system where users entered the minimum data, including wrong or meaningless data, just to get through the screens!). If users can’t avoid it or subvert it, then, as in the story, they’ll use the system inefficiently.

UX research is one way to stop this happening. There are a whole range of techniques you can use to make sure you really understand your users before you start designing and building. Let’s look at a couple of examples.

The How

User interviews

Most recently, we helped the University of Liverpool to better understand the users of their research and impact channels. We start our user interview process with a discussion guide that lays out the questions that we will ask and the order that we’ll ask them in. Sometimes we stick to it rigidly, other times we let people talk or get taken off on informative tangents, but it’s important to have some structure and a guide to make sure you don’t miss anything important or ask stupid questions. We shared this discussion guide with the University and they approved it before we started.

We conducted the interviews, as we usually do, by telephone, largely because it makes the logistics much easier. Lining up multiple stakeholders to a strict timetable that requires them to travel to a venue is pretty challenging; a telephone call is much easier to arrange. Two of us carried out each interview – one asked the questions and led the discussion, a second took notes. We also recorded the interview to reference later if we needed to.

As usual, we asked the users some fairly straightforward questions. We like to start the discussion at a point in time before the user starts a process and to keep the discussion as close as possible to real experiences. To this end, for the University, we used one of my favourite approaches:

I’d like you to think of a time when you needed to find information about the work that is being carried out by academics at the University. Talk me through what you did:

While the interviewee talks, we listen, and make sure we get the information we need. If they don’t cover something, we use a list of prompts, such as:

• What were you trying to find out?
• What triggered your need to find that out?

And later in the interview:

• Were you successful?
• What did you do with the answer?

We cover more than this of course, but I hope that gives a flavour. After the interviews are complete we analyse them. We use and present our findings in a few different ways; for University of Liverpool we created personas and a Customer Journey Map. On other projects we might simply analyse themes. Whatever we do with the findings, we are one step closer to avoiding a system or website that no one wants to use.

Interviews are only one approach to enshrining user needs in your products, let’s look at another: collaborative prototyping and usability testing.

Collaborative prototyping and usability testing

Collaborative prototyping is, genuinely, one of my favourite UX techniques. Bringing together a diverse range of stakeholders to design a system that meets all their needs works really well for us and we do it a lot. Your Housing Group (YHG) is a large housing provider with more than 28,000 homes across the North West, Yorkshire and the Midlands. To help them with their ambitious project to deliver a new online self-service portal, we ran Joint Application Design (JAD) workshops for each of the key user journeys they wanted to address.

During these workshops, we bring business stakeholders, developers, designers and user representatives together and, using Axure, we all build a prototype. Working together on a prototype means that everyone present gets to have their say and that misunderstandings are kept to a minimum: we can all see what we are building.

While a Nexer UX designer actually moves the boxes around on the page (and brings UX best practice skills to the table of course!), everyone in the room gets to contribute. Developers can call out functionality that looks great but would be complex to build; business stakeholders can ensure their strategic goals will be met and underlying business processes are followed and, most importantly, user representatives can flag design elements and terminology that may cause issues for users.

Exposing solutions to all these people and to their areas of expertise, helps to make sure that problems that might have been overlooked, or discovered too late, can be found early. Solving these problems together increases the range of possible solutions and avoids limiting the process to the small pool of team members (designers and developers) who might be thought to be “creative” or to “have all the answers”.

We love to run workshops like this with actual users present, but that’s not always feasible: the business discussions that are sometimes necessary can be politically and commercially sensitive. Where this is the case we try to ensure that genuine user representatives are present – people who really understand users and work with them regularly. For the YHG project, we were lucky to have both Housing Officers and call centre staff in the workshops to be the voice of the user.

We didn’t rely on those representatives to be right all the time. After the workshop, we refined the prototype, built out the interactions and carried out usability testing. Tenants of YHG’s properties and other representative users joined us in the YHG offices where we put the prototype through its paces by asking each user to complete a set of representative tasks. We noted the issues (in this case often around microcopy and terminology) and refined the prototype.

In Summary

There are reasons software houses and digital agencies don’t talk to their users (it’s one more thing to do, it takes some organisation, it might cost some money…) and I don’t want to be too hard on anyone who has ever skipped user research: I did for years. But the potential costs associated with building something no one wants to use surely outweigh the costs of doing the research upfront.

If you do nothing else differently after reading this, try some user interviews. Do it as informally as you like. Call some people up. Show some sketches. Start somewhere and see how it goes. And of course, if you think we can help, give us a call.