User assistance occurs within an action context (the user doing something with the application) and is almost always delivered in close proximity to the focus of that action, that is, the application it supports. When user assistance is displayed within the application as instructional text on the user interface, conventional principles of good information design must be modified to accommodate certain forces within an interactive user interface.
Consider the following assumptions. If you accept them, they are going to lead to some implications for UA design that might seem counter intuitive to some.
- The flow of focus by which users process information on a computer screen is the same as when they process information on a page. In English, for example, that would be left-to-right and top-to-bottom. In Arabic, for example, that would be right-to-left and top-to-bottom.
- Users within an application are motivated to take action, and their focus is easily drawn to action objects, such as text fields, menus, and buttons.
- Once the user's focus is drawn downstream in the focus flow, it is difficult to redirect it upstream. In other words, if something initially draws the user's attention to the middle of a screen, it is far more likely that they will continue going over and down as opposed to going back up. This is especially true if there are additional action objects downstream.
So let's consider a simple application with a two-button radio button group, and you would like to explain the concepts needed to make the appropriate selection. An example I've used before is a report output dialog box that has the user select HTML or PDF for the output medium.
If you have an instructional design background or have been well-grounded in information mapping, your instinct will be to define the terms and give appropriate selection principles before you present the radio buttons. In other words, you will be inclined to put the instructional text above the radio button group. In a document that is removed from the action focus, it makes a lot of sense to introduce definitions and principles early in the document in order to prepare the reader/learner for what comes later. But if you accept the three assumptions I presented earlier, you will understand that the following scenario is what typically happens in a UI:
- The user's focus is pulled almost immediately to the radio buttons because the user is motivated to act.
- This jumping immediately to the buttons causes the user to leap-frog over the instructional text.
- Once downstream of the text, the user does not go back and read it, even if unsure of what the buttons mean. The user makes a best guess and moves on (attracted by the next action object downstream).
I have seen this scenario played out in countless usability tests of form-based web applications where instructional text is placed at the top of the web page. The problem is exacerbated by the resultant appearance of seemingly a lot of words being presented as a dense block. Much the way that quantum physics says that dense matter bends space, I hold that dense text bends users' "eye rays" rendering dense text invisible. The user tries to read it but at the last second their eye rays get deflected and they see the action object instead. (OK, the physics is a little flaky on that one, but you get the point.)
When putting instructional text on the user interface, apply the following principles:
- Divide dense instruction up by action objects, and put the appropriate text in close proximity to its respective action object.
- Put the text next to the action object (in the downstream direction preferably) or just below it.
- If the text is too long, and this orientation disrupts the screen layout for the action objects, for example disrupting the grouping of a radio button group, provide a link that opens a pop-up or dynamic pane. I have seen links be very effective when phrased like an FAQ.