Clients sometimes ask if we engage in user testing as part of our research. We usually reply “No, but we are happy to engage in usability testing.”
“Isn’t that the same thing?”
Not really. This is a case where semantics matter, and we prefer to say “usability testing.” Here’s why: you’re not testing your users—or at least you shouldn’t be. They haven’t done anything wrong. If they cannot find a certain link or are not able to finish a specific task, it’s not their fault—it’s poor site, product or app design. If a company enters into a testing scenario thinking that its users could be the ones to blame, they have missed the opportunity to see things through their customers’ eyes.
What we should and do test are designs, code and products. We are on the lookout for how learnable a system is, how usable it is and how enjoyable it is to existing and potential users. These are the hallmarks of usability testing, a tried-and-true evaluative method in the user researcher’s toolbox.
Businesses should want to know exactly where their product causes users to experience frustration or joy—to know where they lose productivity or gain efficiencies. It’s not possible for users to click the wrong button, but it is possible for companies to put the button in wrong the place, making it susceptible to undue clicking! Uncovering such an important finding in a usability test allows client teams to consider relocating the button, making its call-to-action clearer through enhanced visual design, or increasing the size and spacing of the button relative to items around it for reduced clicking errors.
We want to know all of these things early in the design process so that we can tweak the product accordingly, find a handful of more users, and then test everything again. And again. And again.
When collecting feedback from users, it’s important to always remember: you aren’t taking your users for a driving test. You are test-driving your product with your users.
Illustration by Kayla Velocci