Column: User Assistance

Tables get a bad rap—especially in the Web world where, once upon a time, Web developers misused them for HTML layout. But tables are still very useful for the purpose for which they were originally intended—a way to show relationships among discrete data points. From a user assistance perspective, we deal with tables in two contexts:

1. user assistance—Tables can present information or instructions in our documentation.
2. user interfaces—Tables can display information within a user interface itself.

In this column, I’ll review some of the basic principles of good table design from an information developer’s perspective, then discuss their visual design and interactivity. These principles and my examples provide the bare essentials of table design. When designing tables, a key information design objective is keeping them simple, so if you start needing more than this column provides, you might be making things unnecessarily complicated for your users. 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