Users should be able to interact with the computer and feel that they are in control of their tasks. The following design principles address user control:
For example, instead of providing fixed steps in which the user can choose only from a set series of choices and consequences, let the user move throughout the interface, choosing from a range of choices that can lead to numerous subsequent choices and consequences.
Let the user take alternative courses of action; do not limit a user's capabilities by imposing any preconceived notions of the "correct" sequence for accomplishing a task.
Use informational messages or help information to represent errors as application limitations. Avoid representing events as errors that could be attributed to the user.
Effective design starts with adopting the user's point of view. Application developers tend to see an application as the implementation of functions; users see an application in terms of the tasks they need to perform.
Good design is rooted in an understanding of the user's tasks. Well-designed applications solve users' problems, make their work easier, and offer them new capabilities. The following design principles address the user's perspective:
Input from users can help determine both appropriate functions and the methods for presenting them. Involve users as early as possible in the design process because as the design progresses, the possibilities for change decrease.
You do not need a working prototype to involve users. You can involve users while you write specifications. At this stage, you can watch users work in order to understand the environment in which your application will be used. Talk to users about their work, their current tools, and their goals for new tools. For example, if you are designing an application to create and display charts and graphs during meetings, attend meetings at customer sites, see how charts and graphs are used, and interview meeting participants to learn what they would like in a new tool. Once you have a working prototype of your application, invite users to test it to see if your interface meets the goals you established for it.
Using an application provides critical insights into user interface problems. Before you create the interface for your application, use similar applications, even competitive applications, to help you understand the user's tasks. Observing the user's reaction to various interfaces will also provide important feedback. Acquiring experience with the application may be difficult and time consuming, but it is a worthwhile exercise.
When you use your own application, you become a user yourself. However, be aware that not all users think like you. You may not represent the user for which the application was designed.
A mode is a state of the application in which only certain actions are available to the user. That is, modes restrict the user's options and limit an application's response to the user's actions.
Modes require additional learning, slow down users, and create confusion when the same user action causes different results in different modes. However, modes are useful in a number of situations. Modes extend the capabilities of input devices by letting several actions be accomplished with the same technique, key, or button; and they help an experienced user perform a series of actions quickly. Modes are also useful when there are a set of steps that must be performed in sequence, or if the user does not have permission to perform certain actions.
Provide modes when:
The following sections contain more information about using modes.
You can establish a mode to take effect when the user makes a choice. A tool can represent that choice.
Tools are especially useful in drawing or imaging programs. For example, when a user chooses an eraser tool (activating eraser mode), presses the SELECT button, and moves the pointer within the drawing area, the area of the drawing over which the pointer passes is erased.
The following design principles address mode choice:
Usually, applications change the pointer or cursor within the control to indicate the current mode. Consider the following when designing visual cues:
Remember that users may be unaware of the mode they are in unless there is a clear visual cue. Without such a cue, users may be upset when an action leads to an unintended result or no result at all.
Note that users can exit from a mode in two ways: automatically after completing some action or by picking another mode. For example, in a drawing program, the user may choose rectangle mode to draw a rectangle. If the application exits from the rectangle mode automatically, the user must choose the rectangle mode again to draw another rectangle. If the application does not exit automatically, the user can draw another rectangle immediately or choose another mode.
Whether to have your application exit from modes automatically depends on the function of the application. Consider basing your decision on a thorough task analysis. In many cases, users appreciate the opportunity to configure the exit mode themselves. Whatever your decision, design all of the tools in a toolbox to exit in the same manner.
When the application does not exit from a tool mode automatically, design the first tool in a toolbox to display a pointer graphic and establish a standard selection-based mode (that is, one in which the SELECT button is used for selection). For example, in a drawing program, the standard mode could be used to select part of a drawing.
For example, when the user chooses an eraser tool within the drawing area of a drawing program, interactions with the remainder of the interface should behave as usual.
For example, do not define a delete mode that automatically deletes every file the user chooses from a list until the user exits from the mode. Instead, avoid using a mode entirely by allowing the user to first select the files from the list and then choose a delete action.
For example, do not design a text control that assigns standard printing characters to navigation and editing functions while in an edit mode, such as D for deleting the next character or B for moving the cursor back one character. Instead, use standard nonprinting characters, such as < to go back one character or Delete to delete the next character; or, use a modifier key with a character key such as Ctrl B to go back a character.
Within a control, pressing a modifier key can have different effects. For example, in a scope of selection that uses an extended selection policy, augmentation with Ctrl switches the scope from select mode to toggle mode. That is, ordinarily, pressing the SELECT button and then moving the pointer selects a group of elements, deselecting the remaining elements in the scope. If Ctrl is held down, however, the selection state of the elements is toggled, and the remaining elements in the scope are unaffected.
The following design principles address using augmentation with modifier keys to define a mode:
For example, when using the keyboard for navigating or for changing values, the user can press Ctrl to increase the appropriate increment, such as changing the scrolling increment from a paragraph to a page.
For example, in a drawing program, once the user chooses a tool, provide a modifier key that determines whether to fill a drawn shape or to switch colors. Users often find it easier, however, to have additional tools rather than to use augmentation with tools.
Providing a visual cue with modifier keys is not as important as when users choose a mode because users usually remember when they are pressing modifier keys. However, if combinations of modifier keys have different effects, a visual cue might help convey this information.
The results of a user's actions should be reversible. The following design principles address reversible actions:
For example, if a user merges two lists, then decides that the merged list is not appropriate, the user should be able to choose Undo (or press Undo) to return the two lists to their original format.
An action should not cause irreversible consequences. Thus, continuing the previous example, if the user that just undid the work done to the lists needed the merged and sorted lists after all, choosing Redo to restore the previous work is preferable to re-creating the work.
Your application might display a message describing the outcome of a particular action and indicating alternative actions. For example, if the user attempts to erase a diskette, your application should display a message that tells the user that if the action continues, the user will not be able to retrieve the information on the diskette. Always inform the user before the action takes place, not after. The message should also indicate alternative actions that the user can take, such as stopping the action or replacing the diskette in question with another diskette.
Determine which actions can or cannot be undone. For example, consider which interface actions users might need to undo and provide them as reversible actions whenever possible. Also, provide support to undo as many actions in a series of actions as possible.
For more information on making actions reversible, see the Undo, Redo, Repeat (Action Choices) reference page.
Immediate feedback lets the user assess whether an action has resulted in the desired response. Feedback elements include in-progress messages, information messages, status area, and pointer shape. The following design principles address feedback:
For example, when a user is using a group selection technique such as area technique, show selected emphasis on each element as it becomes included in the selection area. Do not make the user wait until the entire selection operation has completed to see whether the intended elements were included.
If the user's action cannot be processed immediately, let the user continue to interact with the application, if possible. If the user's action must be processed before the user can continue within the application, provide feedback and let the user continue to interact with other parts of the interface.
For information on feedback elements, see the In-Progress Message, Information Message, Pointer (Predefined), and Status Area (Area) reference pages.
If an interface is complicated, users become confused. Flexibility within an interface can accommodate different levels of experience, different styles of interaction, and different user needs. The following design principles address interface flexibility:
For example, provide access to a function through a pull-down menu, direct manipulation of an element, a mnemonic key press, or a shortcut key. However, keep in mind that too much variety can cause confusion.
For example, allow users to reformat the interface by moving elements such as push buttons and menu items, defining macros, and changing input device bindings.
Letting users change settings and select personal preferences enhances their sense of control and encourages them to take an active role in understanding an application's functions.
For example, allow the user to access related help topics on text modes while working in a text-entry field.
For example, let the user expand windows by choosing the More choice for additional choices and elements.
For example, the application might initially display simplified menus that contain only those choices that a novice or casual user would use. As the user becomes more experienced, provide a mechanism for allowing the user to display complete menus of all the application's choices.
For example, an experienced user should be able to turn off the display of certain kinds of information that are not required.
For additional information about designing for users with disabilities, see "Designing for Accessibility".