GC Web Usability Resolution 5: Test for failures, not successes.
(part 5 of 5)
When we present usability test results, whether for a new web application, an internal system, or a website, we are often met with grim faces due to low success rates. As usability experts we know that low success rates are actually a sign that we’re doing our job well. Receiving high success rates across the board is usually a sign that those tasks are working well, and the design is successful; however, it should also tell you that you should be testing different tasks.
The goal of usability testing is to identify and provide evidence for user task failures and successes in order to improve a design; not simply to pat yourself on the back for a job well one. Typically when done during an iterative design process, tweaks are frequently made based on low success rates. Low success rates gives us an enormousness amount of data to work with: alternative user paths, alternative labels, content blindness and layout issues, and industry jargon are all problems highlighted through usability testing (and resolved courtesy of usability testing!). It’s not until the very last round of usability testing that we should feel comfortable receiving fairly high success rates for each task.
Another important thing to keep in mind during the beginning testing phases is that the design is in a state of flux and likely should change and evolve several times. Baseline usability testing is a tool to gather and learn from data. If you go in to do usability testing hoping to validate your design and give it a final stamp of approval before hitting the publish button, you’ll likely be sorely disappointed. It’s akin to handing in a paper to be proofread by your TA and having them hand it back saying you need an entirely new thesis statement and the last 2 supporting arguments must be completely rewritten if you want to receive an A.
The lesson here is don’t wait too long before you start testing – go in early and often. Just like receiving feedback on a school paper, it’s usually much easier and far less daunting to restructure an essay outline than it is to completely re-work a final draft. And remember, it’s those red markups that will get you to your A.
We all know the true GC new year starts April 1st, but regardless, we thought we would take this opportunity to take stock of the past year in usability across the NCR and bring you five GC web usability new year resolutions. This blog series tackles the following resolutions:
Usability Resolution 1: Work on governance before you work on anything else.
Usability Resolution 2: Think by topic, not who owns the topic.
Usability Resolution 3: Stop trying to pigeon-hole your IA into action-based tasks.
Usability Resolution 4: If you’re the only one who is going to read it, don’t publish it.
Usability Resolution 5: Test for failures, not successes.