Column: User Assistance

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

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

One of the more interesting tensions I have observed—since getting into user experience design about five years ago—is the almost sibling-rivalry tension between UX Designers and User Interface (UI) Developers. At the heart of the tension between them is the fact that most UI Developers consider themselves—and sometimes rightfully so—to be UI Designers. The coding part is like Picasso’s having to understand how to mix paint. It’s not the value they add, just the mechanics of delivering the creative concepts.

When I worked on the Body of Knowledge Task Force for the Society for Technical Communication, the interesting question we wrestled with was: What value does a technical communicator add above what an engineer who writes well offers?UX Designers or UX Architects have the same problem to solve: What value do we add that differentiates us from a UI developer who is user focused? This question strikes to the very heart of what differentiates us, as UX professionals, from UI Developers. If we don’t provide a compelling answer, the only one left is that they code and we don’t. Hmm…, not the kind of value proposition I’d be comfortable with in this economy. Read More