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

User assistance occurs within an action context—the user doing something with an application—and should appear in close proximity to the focus of that action—that is, the application it supports. The optimal placement of user assistance, space permitting, is in the user interface itself. We typically call that kind of user assistance instructional text. But when placing user assistance within an application as instructional text, we must modify conventional principles of good information design to accommodate certain forces within an interactive user interface. This column, User Assistance, talks about how the rules for effective instruction change when creating instructional text for display within the context of a user interface.

User Behaviors and Their Implications for Instructional Text

When designing user assistance—particularly instructional text within the context of an application—we should keep the following typical user behaviors in mind:

• When users are processing information on a computer screen, their flow of focus is the same as when they process information on a printed page. For example, in English, readers scan from the upper left to the lower right and read from left to right and top to bottom; in Arabic, people read from right to left and top to bottom.
• When using an application, users are motivated to take action, and their focus is easily drawn to action objects such as menus, buttons, and text fields.
• Once an action object or other visual element on a page has drawn a user’s focus downstream in the focus flow, it is difficult to redirect it back upstream. In other words, if something initially draws a user’s attention to the middle of a page, it is far more likely that the user will continue across and down as opposed to going back up the page. This is especially true if there are additional action objects downstream.

Read More