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.
While we intuitively expect such behaviors on the part of users, I have, in fact, observed them time and time again in usability testing. However, these user behaviors lead to some implications for user assistance design that might seem counterintuitive, as follows:
Do not introduce required conceptual information before a user engages in activities that require those concepts.
Do not explain business rules or constraints before the user encounters their constraining effects.
The key word in both statements above is before. Although both implications seem to fly in the face of good instructional design, they accommodate the reality of user behavior within an interactive medium. Given a choice between reading and doing, users prefer to be doing. There is another principle at work here as well. Let me tell you a story to illustrate it. As an instructor for a software application that had some annoying gotchas, I found that, as much as I tried to warn students about problem areas before they encountered them in lab exercises, the students still made the very mistakes I had warned them against. When I helped them back out of their mistakes, they would slap their foreheads and say, “Oh yeah, you told us about that!” The principle at work here: Until someone experiences or recognizes a problem, that person has no way of processing information pertaining to that problem. Yet much of what we do in instructional design has to do with giving answers to people who don’t yet have a problem—in the well-meaning, but wrong belief that “forewarned is forearmed.” Instructional text in user interfaces often exhibits this problem.
User Assistance in Context: An Example
Let’s consider a simple Log In form comprising a text field, two radio buttons, and an action button. For this example of user assistance, let’s make the following assumptions:
This form’s designer could have better accommodated some unusual application constraints with a different form design or even an improved application design—for example, a database that would allow more valid entries than just Member or Non-member.
However, as is often the case for technical communicators, we have no control over the design and instead must solve the problem by telling users what the rules are.
The example itself is simplistic, but the scenario it represents is authentic.
If you have a background in instructional design or information mapping, your instinct might be to provide instructions regarding the entry of information and selection of options before requiring a user to take action. In other words, you might be inclined to put the instructional text before the text field and radio buttons, as shown in Figure 1.
However, if you consider the three user behaviors I described earlier, you’ll probably understand that the following scenario is what typically would happen when a user filled out this form:
The user’s focus would be pulled almost immediately to the User Name field, because the user is motivated to act.
Jumping immediately to that field would cause the user to leapfrog over the instructional text.
Once downstream of the instructional text, the user would not likely go back and read it, even if unsure of what the requirements are. Instead, the user would make a best guess and move on—attracted by the radio buttons downstream.
In Figure 2, we see the same login requirements and instructions presented in a way that accommodates users’ natural tendency to leap to an actionable object and the natural flow of focus that follows.
Some might object to this layout, saying that the user might provide an invalid name in the User Name field, then have to go back and correct it once he sees the instructions. My point is that they will probably do the same thing anyway if the instructions are upstream of the text field, because their focus is immediately drawn to the field, so they will never see the instructions. With the layout shown in Figure 2, users have the opportunity to catch and correct their mistakes before clicking Log In, preventing them from getting an error message.
Some Guidelines for Instructional Text
When placing instructional text within a user interface, apply the following guidelines:
Divide dense instructions up for individual action objects.
Put the appropriate instructions in close proximity to their respective action objects.
Place the instructional text next to the corresponding action object—preferably, in the downstream direction, to the right or just below it.
If the instructional text is too long and its recommended placement would disrupt the layout of the action objects—for example, disrupting the grouping of a set of radio buttons—instead provide a link that dynamically displays a pop-up or pane when a user clicks it. These kinds of links can be very effective when phrased like questions in FAQs.
The dynamics of how users interact with interactive elements within a user interface change how we must approach instruction that we deliver within user interfaces. Users skip static elements, such as instructional text, because they focus immediately on downstream actionable objects. Effective user assistance design accommodates users’ natural workflows by providing instruction immediately beside or following interactive elements that constitute points of need for more information.
User Experience Architect at IBM Internet Security Systems
Atlanta, Georgia, USA
In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More