Five Things I’ve Learned From Usability Testing

Getting your Trinity Audio player ready...

I love doing usability testing.

There’s nothing like putting your assumptions to the test in front of users. Not only do you get to see the your work in the wild, you’ll frequently get amazing ideas from users because they use the system everyday.

It’s something you have to make time for. I’m surprised by how many designers don’t. They should spend less time drawing and more time talking to users. You know, get out of the building.

I’ve also learned over time how to get more effective feedback. Humans are very predictable in our unpredictability. If you watch for certain patterns, you can  increase your ability to discover insights that would normally be hidden.

It’s best to do it within the context of their environment

I’ve found it’s best to emulate the environment users are normally in when they use your application.

The first few usability testing sessions I was involved in were the sort of thing that marketing people love doing: one-way mirrors with a moderator and five or six people sitting on the other side of the mirror. We would sit on the other side, take notes, and frequently joke about users while watching them.

A lot of fun to watch. And sometimes completely useless. All usability testing is biased — seriously, if you pay someone, are they really going to be honest — so your goal is to limit the biases as much as possible. We can still learn alot, so that’s why we continue to test, biases or not.

I’ve found it’s best to emulate the environment users are normally in when they use your application. For example, I wouldn’t do a test for a mobile map app where they are sitting down — they should be walking around, looking for the place. I’ve performed that test with someone holding their phone, and the metric was, “did they get to their destination?”

For other applications, I perform a lot of guerilla usability testing with users at their desk. This gives a better understanding of the application they are using in relation to their environment on a day-to-day basis.

I recently did a test with a client where the users had to interact with three to four applications during their daily tasks. I could see what other applications they were using (Salesforce, Excel, and Outlook were three, as well as six other browser windows). We took notes while watching the interactions and came up with a list of workflow suggestions that involved applications other than the one I’m designing for.

Watch what they do, not what they say

When you call it “usability testing,” end users may view it as a test of their knowledge, not the usability of the application.

Most people love to help, so they’ll be positive just about everything you put in front of them, called Social Desirability. I’ve been through a few usability tests where the user was talking about how much they loved the application. “I love it! I could totally see using this,” they would say.

It was obvious they had no idea how to use the application.

When you call it “usability testing,” end users may view it as a test of their knowledge, not the usability of the application. They don’t want to look stupid, so they’ll talk about how they understand how to use the website or  focus on the task more so they won’t make mistakes. Most people love to help, so they’ll be positive just about everything you put in front of them. This alone might be a series of posts I could write.

Watch what they do and how they are reacting to the application on the screen and try to match it up with their comments. Sometimes I record mouse movements so I can get a more accurate representation of what the user was doing, but I usually just take rough notes on the interactions.

Getting people to talk is easier than you would think

Ask them three questions, and they’ll tell you about everything.

When I worked at Jobvite, I extensively interviewed recruiters and hiring managers. There’s no easier group to get feedback from than recruiters.

Ask them three questions, and they’ll tell you about everything. What they had for lunch. Who they last interviewed. What they like about their job. And more importantly, how they use technology — if you guide them. Recruiters talk a lot during the day, but no one really listens to them. When they get the chance, they will gladly talk.

They are not unlike most people — people just want to be heard, because we are a broadcast society. As designers we give them an opportunity for that dialogue, and that gives us the chance to get some real insight into not only how they use the technology you are testing, but how it fits in to the rest of their environment.

All you have to do is ask “Why?”

A lot.

That feedback is crucial to designing great products: understand the user’s pain points in detail, and you will be able to craft solutions to their problems.

The best ideas come from unscripted threads

It’s better to have a loose script, so you can think on your feet.

I’ve seen usability tests where the moderator drilled through an extensive list of questions, took notes, and walked away with almost no feedback of value without even knowing it.

I’ve also seen usability tests where the moderator had a really short list of questions, let the users talk their way through some great ideas, and walked away with product changing feedback.

It’s better to have a loose script, so you can think on your feet. If you can learn how to do that, the tests have more a serendipitous approach which will result into drilling into a particular line of questioning. This is where the real gems come, because you’ll get deeper and deeper into a topic and achieve true user understanding.

A complete prototype isn’t needed to test your concepts

Usability testing isn’t just about testing your current design — it’s about leveraging your users’ collective experience to improve on it.

I cannot tell you how many times I have used half-built prototypes to test ideas.

Before we even start, I tell the users that this is a representation of some of the ideas we are trying. I also tell them it’s a prototype, so some things may not work. The prototypes are usually high fidelity enough that they forget this.

I send them to a link. They click on it. It breaks.

“Why did it break?”

“It’s a prototype, but it’s not complete. We’re trying out some ideas. So, when you click on that link, what do you think should happen? Could you explain that step-by-step?”

Most of the time, they’ll do a decent job describing the next steps. What’s really cool is when you happen on a user that describes something step-by-step, you confirm their thoughts and their eyes light up like Christmas. Even better, they give you a great idea that you would have never thought of.

Usability testing isn’t just about testing your current design — it’s about leveraging your users’ collective experience to improve on it. Those ideas will not only validate what you’re working on now, but also make their way into the roadmap as your product grows.

Are you learning from your users?

Make time.

Ask why.

Listen.

It’s not hard, but you should do it everyday, whenever you can. What you learn may surprise you.

Here’s a template to start with. Go test now.