Go and visit your users

User testing on the road episode 2

Test where your users are

In my last post, I talked about one problem with traditional, lab based user testing — making the participants travel to you:

And it’s equally hard for participants — requiring them to travel to where the testing takes place often rules out busy, disabled, elderly or geographically isolated users, removing whole demographics from the testing.

There is another problem — sitting down in a clean, quiet meeting room with just a couple of people for an hour is just unnatural. It is simply not an environment where most people would use your website on a desktop or laptop, let alone a mobile device.

More realistic is a noisy office with constant emails and instant messages, offers of tea and coffee and people wandering past with a question or juicy bit of gossip. Or sat at home with a TV on in the background, a child demanding attention and a cat sitting on the keyboard.

Meet your users

There is only one way to really understand how your users actually use your website, and that is to go and see them. Talk to them, watch them using it, and later, carry out tests in the same environment.

I say later, because one of the main advantages of this approach is you can do it before you define the key tasks to use in the testing — in fact because you have the chance to interview and observe the user, you should use this to define and understand their tasks and objectives, and what you should ask users to do in testing at a later date.

This is one aspect of what are often called field studies — or, if you feel like some confusing but impressive sounding jargon, contextual analysis or ethnographic studies. All these things basically involve finding out about your users in real life.

Meet the people who know your users

Although it’s not directly related to this blog, it would be remiss of me to talk about field studies without mentioning another type — observing how users interact with a company or service other than through its website. Visit a call centre, talk to the people on the front line, listen in to the phone calls and watch as they answer emails and live chat. Although you don’t talk directly to users this way, you see at first hand the problems they have, and tap into the expert knowledge of the people dealing with them. And you get an insight into the problems of many, many users — far more than you will ever meet.

Involve the team

A big part of our job as UX professionals is to help teams understand the people we meet, their needs and problems, and it is hard! As I talked about last time, it is vital to expose stakeholders and the people doing the work to the users as often as possible, and this is as true in field visits as traditional user testing — if trickier. But there are a few ways to do it.

Send the team

There is no substitute for actually meeting the people who will use your work. A developer who sees a user struggle wants to help them, and a product owner who watches a user spend 10 minutes doing a simple task, over and over again, can decide how to prioritise improvements against new features with all the information they need.

Ideally, you’d take no more than a couple of people on a field visit. Any more can be uncomfortable for the user. So I usually try and take one team member with me. And once that team member has seen a typical session, they don’t need me next time, they can take someone else with them instead. And so on, until everyone can go out and meet users, and report back with useful findings.

Broadcast it

I also mentioned last time that user testing in a box meant that the testing didn’t have to take place in the same place as the observation. You can just as easily broadcast a field test back to base — and as you’d generally only fit one or two a day in, in this case it’s good to schedule them around lunchtime, so the team can watch without having to plan. Buying them lunch helps…

Record it, then play it back

First of all, record everything that happens when you meet users anyway! Obviously, as well as letting you check back and see things you missed at the time, it lets you play the recording back to people later. The trick is in how you do this. Like user testing, you can put as many videos online as you want for people to watch, but they won’t. Too many videos, not enough time. Instead, schedule a few hours to show the video and talk with your team about what you see, and they go from a forgotten artefact to a key part of the design process that helps everyone understand the user. It’s a good idea to make this a regular part of sprints — part of the show and tell process for instance.

Is it really worth it?

Yes.

First, to go back to the article by Jared Spool I’ve quoted elsewhere, on getting everyone involved:

Our research had a finding that took us by surprise: Teams that excluded non-design personnel didn’t see the same advantages as teams that included those people.

For example, we worked with teams where only the designers and developers were having regular exposure to their users. Stakeholders, such as product managers and executives, along with other non-design folks, like technical support liaisons and quality assurance management, didn’t participate in the field studies or usability tests. While the core design team became very familiar with what users needed and wanted, they were constantly battling with these other individuals who didn’t have the same experiences.

The tipping point came when we found teams where all these other folks were participating in the user research studies. No longer did they assert their own opinions of the design direction above what the research findings were telling the teams. Having the execs, stakeholders, and other non-design folks part of the exposure program produced a more user-focused process overall.

- Jared M. Spool

A second example, of going to see your users at work, comes from a project we did recently that involved using software in busy commercial (and military) canteens.

Testing this in a lab would have sat a user down next to a computer and printer. In real life, the printer in one case was on the other side of a giant warehouse. And a room we’d normally fit 2 people in could contain half a dozen burly squaddies rushing around. And everywhere, noise, bustle, and not enough hours in the day.

By seeing this we had a detailed understanding of the environment, and some solid evidence of the issues with the current system. The result?

The time spent every single day to complete the key tasks was reduced from 3 hours to 3 minutes!

Want to know more? Visit ux.hiveit.co.uk to learn more about Hive IT’s UX research, testing and design services. You can also download our UX Menu, our way of making UX Services easier to digest