Seven Habits of Effective Usability Testers

While there is no substitute for experience, these seven habits will ensure that you make the best use of your time talking to honest-to-God users.

Mastering the art of usability testing is an exercise in failure-based learning. Many of us who have been in the research field can painfully recall our various screw-ups along the way. Remember the time we didn’t hit the record button until halfway through the session? What about that time when we were nervous and kept peppering the participant with questions instead of giving them time to answer? Or when your product manager walked by and made a funny face to break your concentration? And did I really just share the wrong screen and show the participant my Netflix queue with Sister Act 2: Back in the Habit all the way at the top?

While there is no substitute for experience, I thought I might share some of the tricks I’ve learned along the way. Hopefully with these seven habits in mind, you too can make the best use of your time talking to honest-to-God users.

Learn to walk in the participant’s shoes

User empathy is the active ingredient in an effective usability test. The first fifteen minutes of a usability test are a nice opportunity to build rapport by lending an empathetic ear. Ask participants about a recent experience related to the apps’ use case. The more that you are able to identify the differences in how you and your target users think, the closer you get to building something they will actually need.

Encourage participants to “think aloud”

Observing a user as they perform a task only tells you part of the story. You can see the places they go and boxes they click but you will never know why unless you can read minds. Instead, ask participants to think aloud and narrate the thoughts in their head as they perform a task. In doing so, participants will reveal what they doing and, more importantly, the thoughts and feeling that dictate their onscreen actions.

Ask open ended questions

While the expressed purpose of usability test is one of design validation, the real goal is to get participants talking. So while it may be tempting to ask, “hey, do you like [feature]?” the response is usually going to be one of two words: yes or no. A better way to phrase the question is “hey, what do you think of this [app or feature]” and hear what the participant has to say.

Always ask why

Too often usability testers think their job is done when they have identified what a participant wants. The more illuminating insight to uncover is WHY they want it. So channel your inner 4-year old and ask why, then ask why again.

Enjoy the silence

During a usability test, nothing raises the ol’ blood pressure like an awkward silence that never seems to end. That said, avoid the temptation to interrupt the participant’s thought process by rephrasing your question unnecessarily or prompting them with a few answer choices. The longer we give users to think, the better their answers become. Be patient and let them fill the inaudible void.

Don’t “lead the witness”

At some point during your usability test, the participant is going to struggle a little. They might feel awkward about getting stuck, as if this is a reflection of their own inadequacies and not that of the design. If they ask for your help, answer their question with another question. For example, if they ask where the “BUY” button is, do not point it out. Instead, ask them where they think it should be. What they say next is what you have be trying to get them to articulate all along.

Show and Tell

As the tagline from the modern ’90s sci-fi classic states: no one can tell you what the Matrix is; you have to see it for yourself. The same can be said for usability testing, as far as stakeholder buy-in is concerned. Sometimes, people need to witness a user’s pain firsthand to truly understand it, either by observing a session or watching a recording. Make sure to use screencasting and recording software to show your stakeholders what happened when telling them in a written findings report is not enough.