|
This article was originally published in the May 2005 issue (Vol 11, No. 4)
|
The World is Ready for Usability. Is Usability Ready for the World? By Kathy Straub, Ph.D., CUA It's time for the world to be usable. People are ready. Users are no longer passively frustrated when things don't work. They regularly suggest improvements. They use the words like “usable” and “citizen-friendly” and even “task flow.” They don't just crib about time lost to inefficient products anymore. They do the math, but not on their cell phones. Today we know that consumers evaluate and select both products and services based on the user-friendliness of an interface. Blink, Usability Matters But it gets even better. Executives have discovered the value of usability. You hear the word “usability” in elevators all the time. It's clear from those overheard conversations that executives who understand that usability can be a strategic differentiator don't always grow the practical details of what is involved. But that's not important. All the gurus agree (!) that the first step in making usability routine is getting the support of an executive champion. If the executives will back it -- blink! -- Usability matters. Practitioners, No gurus User-centered design is being systematically integrated into the Web, application and product development process. It's the tipping point usability specialists have been waiting for. But are we ready? Does the field have the tools, and resources -- or for that matter the people -- to keep up with the need? To keep up with the need, usability needs to do two things:
This means that the industry needs to agree upon both what it is we are doing when we “do usability” and how we should go about doing it. User-centered methods should guide practitioners in collecting and analyzing user data to support informed design decisions. The methodologies need to be robust and replicable. Applying the same method in the same environment should yield a similar (though not necessarily identical) result. Let's make it concrete. If usability is to scale, our understanding of what usability IS and how to do it has to be consistent enough so that different organizations asked to evaluate the same application, will return roughly the same list of challenges and recommendations. Usability is at least that evolved, right? There are variations on the methodological theme, but does the output vary that much? None of these things is just like the others...You may be surprised. Even a task as (seemingly) transparent as usability testing Microsoft's hotmail.com elicited different data based on different approaches to usability testing. Molich, Ede, Kaasgaard and Karyukin (2004) reports on the findings of the Comparative Usability Evaluation Study (CUE-2). This meta-analysis describes the usability testing approaches and results across nine independent usability groups asked to conduct a “standard” usability test of hotmail.com. The teams included six industry labs, two university-based teams with commercial activities and two student teams. Each team was provided the same project background information and access to a “Marketing Liaison” for further clarification or feedback on their proposed methods. Molich and colleagues compared and contrasted the usability testing approach, usability problems discovered, and reporting of findings across the teams. Their finding is jarring: “...our simple assumption that we are all doing the same and getting the same results in a usability test is plainly wrong” (p. 65). The details—particularly if you think of usability testing as a process-driven task—are equally jarring:
Despite this client-based direction, the overlap in tested tasks was limited: 51 different tasks appeared on the testing protocols. Only two usability testing tasks were common across all of the teams (Register, send someone e-mail). 25 (49%) of the tasks tested were proposed by only one team. Leading the witness... Eight of the nine testing teams used leading questions on their testing protocols. Leading questions are questions that contained hidden instructions or cues, such as “Create a personal signature” in a context where the user needs to click on a link with the word “signature” in it. Leading questions test participants' ability to recognize keywords rather than their ability to complete the task. Usability problems uncoveredThe usability teams reported from 10 to 149 problems. No single usability problem was reported by all nine testing teams. One problem was reported by 7 of the nine teams. For the two tasks that were tested by all teams, 232 unique problems were reported. Seventy-five percent of the problems identified were identified by only one of the teams. Reporting the findings
Quality of findings Two interesting findings emerge.
The indirect testing team reported far fewer problems than the direct observation teams. This group also failed to observe the one serious problem that was identified by 7 of the 8 remaining teams. Molich observes, “Unattended testing didn't lead to any more (in fact, quite a bit less) reported problems and didn't provide insights that other methods [missed].” (p. 73). Ask five witnesses...get five stories Just as in interface design, consistency is critical to the success of usability as a field. If the task of usability testing is this inconsistent, what can that mean for user-centered analysis and design projects? Molich' and colleagues' findings suggest there is significant variability in execution and findings across the task of usability testing. These were (mostly) professional level groups. They proactively volunteered to be evaluated. One would only assume they set out to present their best work in this very public venue. ConclusionThe world may be ready for usability. Molich's study indicates that there is still a lot of art in the science of usability testing. But if usability is an art, can that art be made routine? References and charts for this article are posted at www.humanfactors.com/downloads/feb05.asp
|
|||||
| All articles are property of the author or publication providing reprint permission. Reprinting this content in part or in whole requires permission from the source. | ||||||
|