A recent Alertbox by Jakob Nielsen, “Thinking Aloud: The #1 Usability Tool,” reinforced the usefulness of the thinking-aloud protocol as a great usability testing approach. I couldn’t agree more. But there is a big difference between someone’s thinking out loud about a task they are doing and someone’s voicing their opinion about a design. The first is very valuable; the second is so-so at best and dangerous at worst.
Here is the kind of data you want to get from a user who is thinking aloud:
“I want to do…”
“I’m looking at the UI, and I think it does…”
‘Hmm, that’s not what I expected; I thought it was going to…”
“That took longer than I expected.”
In short, you want to learn how a user sees her task and how she is making sense of a user interface in terms of that task. Read More
A theme I deal with a lot, both at work and in this column, is organizations’ asking user assistance (UA) developers to support more products with fewer resources. For UA developers who are experiencing a resource crunch, the obvious solution is writing less user assistance for a product than we would have produced in the past. (See my UXmatters column “Hockey Sticks and User Assistance: Writing in Times of Resource Constraints.”) But that still leaves the problem of how to write less and cover users’ information needs adequately.
Everett Rogers’s seminal model of the technology adoption process , charted in Figure 1, suggests an approach that might let us put the proverbial 10 pounds of content into a 5-pound bag of writer capacity. Rogers noted that the phases of technology adoption correspond to its adoption by distinctly different classes of people, who accept new technologies at different paces. Read More
Many applications must gather information from users. At their simplest, such transactions employ dialog boxes or brief forms. Examples include sign-in screens—Who are you and do you have permission to be here?—and printer setups—What is the page size and do you want single-sided or double-sided pages? Others are quite complex, such as helping a user prepare his income tax return. We can measure complexity by the number of questions we ask or the logical branching we use. For example, the question What OS do you use? might have one set of follow-up questions if the answer is Mac and another if it is PC.
When I find myself designing an application that is complex, either in terms of its length or its logical dependencies, my natural instinct is to take a wizard approach. Wizards are cool; forms are dull. Product managers love wizards because they are so Web 2.0. Developers like wizards because they involve more programming expertise than just cranking out forms. Read More