Guidelines for Dialog and User Interface Design
This section is based on Ben Shneidermanís (1992) research and writings. He has developed some underlying principles of design that he argues are applicable in most interactive systems. These underlying principles of interface design are derived heuristically from experience.
Strive for consistency. This principle is the most frequently violated one, and yet is the easiest one to correct and avoid. Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout. Exceptions should be comprehensible and limited in number. A system should look, act, and feel the same throughout.
Provide frequent users shortcuts. As the frequency of use increase, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Frequent knowledgeable users appreciate abbreviations, special keys, hidden commands, and macro facilities. Shorter response times and faster display rates are other attractions for frequent users. A system must respond to the differing needs of its users.
Provide informative feedback. For every user action, there should be some system feedback. For frequent and minor actions, the response can be modest, whereas for infrequent and major actions, the response should be more substantial.
Design dialogs to create closure. Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the user the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions. The power of the dialog and commands should be appropriate to the capabilities of the users. Power is a measure of the amount of work accomplished by a given instruction to a system (cf., Galitz, 1985, p. 21).
Provide simple error recovery. Design the system so the user cannot make a serious error. If an error is made, the system should detect the error and offer simple, comprehensible mechanisms for handling the error. The user should not have to retype the entire command, but rather should need to repair only the faulty part. Erroneous commands should leave the System State unchanged, or the system should give instructions about restoring the state.
Permit easy reversal of actions. A userís actions should be reversible. This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
Support internal locus of control. Experienced users want to feel that they are in charge of the system and that the system responds to their actions. Surprising system actions, tedious sequences of data entries, incapacity or difficulty in obtaining necessary information and the inability to produce the action desired all build anxiety and dissatisfaction.
Reduce information load. Information load is a measure of the degree to which a user's memory is being used to process information on the display screens. It is a function of the task being performed, a person's familiarity with the task, and the design of the user interface itself. The limitation of human information processing in short-term memory requires that displays be kept simple and that sufficient training time be allotted for learning commands and sequences of actions. Where appropriate, online access to command-syntax forms, abbreviations, codes, and other information should be provided. Designers can reduce information load by providing graphic rather than alphanumeric displays, format displays to correspond to users' immediate information requirements, use words that are easy to understand, provide simple dialogues (cf., Galitz, 1985, p. 21).
|DSSResources.COMsm is maintained and all its pages are copyrighted (c) 1995-2002 by D. J. Power (see home page). Please contact firstname.lastname@example.org. This page was last modified Wednesday, May 30, 2007. See disclaimer and privacy statement.|