Design: User Assistance Design

Picture this: You’ve just signed up a new customer, and they’re excited to get going. Everything seems great on paper—until their questions start rolling in.

“How does this feature work?”

“Why can’t I customize my dashboard?”

“Why won’t this integration connect properly?”

Despite the best efforts of your support agents and Customer Success team, confusion about your product might be too much for your customers. Without proper guidance, they could become frustrated and eventually decide to leave. This scenario is all too common. Over 90% of customers believe that companies could do a better job of onboarding, and a UserPilot survey shows that only 24.5% of users adopt a core feature, while the rest abandon it because they don’t immediately understand how to derive value from it. 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

In this column, instead of talking about one of my usual topics—tactics to avoid errors—I’ll discuss how to work within constraints and pragmatically address real-world issues. During the software-development process, your team may ask you to design an error message. Annoying edge cases all too often pop up—usually too late in the process to fix the issue in any other way.

For starters, I never write what I’d call error messages. Admittedly, I occasionally use that term—in the same way I might use words such as sitemap—just at the beginning of a conversation to orient everyone to my process. Just as I did in the title of this column. But I then switch to a more meaningful term and get everyone to talk about exception messages. Read More