|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
|
GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
|
| by Sidney L. Smith and Jane N. Mosier |
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
User guidance refers to error messages, alarms, prompts, and labels, as well as to more formal instructional material provided to help guide a user's interaction with a computer. The fundamental objectives of user guidance are to promote efficient system use (i.e., quick and accurate use of full capabilities), with minimal memory load on the user and hence minimal time required to learn system use, and with flexibility for supporting users of different skill levels.
User guidance should be regarded as a pervasive and integral part of interface design that contributes significantly to effective system operation. User guidance cannot be merely a decoration added at the end, like frosting on a cake. A study by Magers (1983) has demonstrated convincingly that good user guidance can result in faster task performance, fewer errors, greater user satisfaction, and will permit accomplishment of information handling tasks otherwise impossible for novice users.
A narrow view of user guidance deals with preventing and correcting user errors. But minimizing user errors may require improvements in broad aspects of interface design -- in techniques for data display, in procedures for data entry and sequence control -- as well as provision of user guidance. Moreover, any general consideration of user guidance functions must include provision of status information, job aids, and routine feedback, as well as feedback for error correction.
Many user interface design features contribute directly or indirectly to guide a user's interaction with an on-line computer system. The primary principle governing this aspect of interface design is to maintain consistency. With consistent interface design, users can learn to apply computer tools more quickly, more accurately, and with more confidence.
Design consistency implies predictability of system response to user inputs. A fundamental principle is that some response be received. For every action (input) by the user there should be a noticeable reaction (output) from the computer. It is this feedback linking action to reaction that defines each discrete transaction and maintains user orientation in interaction with the system.
The importance of feedback information for guiding the user has been emphasized by Engel and Granda (1975, page 13) in their recommendations for user interface design: Feedback to user action covers keeping the user informed of where he is, what he has done, and whether it was successful. . . . In an interactive computing situation, immediate feedback by the system is important in establishing the user's confidence and satisfaction with the system. One of the more frustrating aspects of any interactive system is sitting at the terminal after entering something and waiting for a response. Questions arise such as, 'Is the system still going?', 'Is the terminal still connected to the system?', 'Did the computer lose my input?', 'Is the system in a loop?'. A message that indicates that the system is still working on the problem or a signal that appears while the system is processing the user's input provides the user with the necessary assurance that everything is all right.
Predictability of computer response is related to system response time. Timely response can be critical in maintaining user orientation to the task. If a response is received only after a long delay, the user's attention may have wandered. Indeed, the user may forget just which action the machine is responding to. Frequent user actions, generally those involving simple inputs such as function key or menu selections, should be acknowledged immediately. In transactions where output must be deferred pending the results of computer search and/or calculation, the expected delay should be indicated to the user in a quick interim message.
Some experts argue that consistency of system response time may be more important in preserving user orientation than the absolute value of the delay, even suggesting that designers should delay fast responses deliberately in order to make them more consistent with occasional slow responses. Perhaps such a reduction in response time variability may be desirable. If system response time is always slow, a user can adapt to the situation and find something else useful to do while waiting. But surely a better solution is to make all responses uniformly fast, or, where that is not possible, to provide a quick interim message to warn the user that a response will be delayed, as suggested above. In that way, a slow response is made predictable even though it is not consistent with other responses.
Ensuring fast response is probably a greater problem in the design of general-purpose, multi-user, time-shared systems than for dedicated information system applications. Where an information system is designed to accomplish defined tasks in a specified manner, data processing loads can usually be anticipated sufficiently well in user interface design to provide adequately fast response for all transactions.
Consistency is important in all aspects of user interface design. Anyone who has tried to learn a foreign language knows the difficulty of learning irregular verbs, whose conjugation does not follow any consistent rule. In the same way it is difficult to learn (and remember) irregular features of user interface design.
Data entry can be guided by consistent formatting of entry fields on the display, including consistent wording of labels, consistent placement of labels with respect to entry fields, and consistent demarcation of the fields themselves. Some kind of highlighting is frequently recommended for field delineation, displaying field location and boundaries clearly to a user. Even more guidance could be provided by consistent use of different field marking to indicate different types of data entry.
For data display, formats should be consistent from one frame to another, always including a title at the top, labels to indicate page numbers in related displays, standard labeling of control options, standard positioning of guidance messages, etc. Messages indicating user errors should be carefully worded to be both concise and informative. They should also be consistently worded from one message to the next, and consistently located in the display format. Even such a subtle feature as cursor positioning should receive consistent treatment in the software logic of user interface design.
For sequence control, consistent user interface design is even more important. One design feature that can help guide the user is consistent provision of a general OPTIONS display, a "home base" to which the user can return from any point in a transaction sequence in order to select a different transaction. As a basic principle of user guidance, the interface designer should not rely on a user to remember what prior actions have been taken, or even what action is currently being taken. Users may be distracted by competing job demands. For control actions whose consequences are contingent on context, an indication of context should always be displayed, even when that context was defined initially by the user.
Although consistent interface design will provide much inherent guidance, it is often desirable to include in computer-generated displays some explicit instructions or prompts for the user. Such instructions should be consistently located in display formatting, perhaps always at the bottom where they can be ignored by experienced users. For novice users it may be desirable to provide supplementary guidance or job instruction, available in response to user requests for help. Such optional guidance will adapt the interface to different user capabilities, supporting the novice user without hindering the expert.
The concern here is with on-line user instruction, as opposed to off-line system documentation. The need for on-line instruction has been emphasized by Brown, Brown, Burkleo, Mangelsdorf, Olsen and Perkins (1983, page 6-1) in their user interface guidelines developed as an in-house design standard at Lockheed: Much of the information commonly provided in paper documentation, such as user manuals, should also be available on line. A manual may not be available when it is needed. Some users may never receive the relevant documentation. They may not know what documents are available, which ones are relevant, or how to procure them. Even users who possess the appropriate documentation will not necessarily have it with them when it is needed.
One might add that even if users have the appropriate documentation on hand, they may not be able to find answers to their questions, especially when the documentation is bulky. Effective on-line instruction and other forms of user guidance can reduce the need for off-line training courses based on system documentation.
Certainly there is a strong trend in current system design toward on-line documentation for user instruction. This trend reflects the decreasing cost of computer memory, and also the increasing use of computers by people with little understanding of computer function. The novelty of early pioneering efforts to program computers to teach their own use (Morrill, 1967; Morrill, Goodwin and Smith, 1968; Goodwin, 1974) has now become almost commonplace, as we have learned more about the techniques of on-line aiding.
One of the principal arguments for on-line documentation is economic. Limanowski (1983) estimates a potential cost saving of 70 to 80 percent if on-line documentation can be provided as an alternative to more traditional paper documentation. If that is true, we can expect to see increasing recourse to on-line documentation for that reason alone.
People who are responsible for writing instructional material may be the first to note inconsistencies in user interface design. In the documentation of user guidance, whether intended for on-line display or printed handbooks, every special feature and smart shortcut provided by software designers will add an extra paragraph, or sentence, or footnote to the instructional material. As special features proliferate, instructions to the user must expand accordingly. On-line guidance will require more display space, and printed manuals will grow fatter.
From this reasoning, we may conclude that interface design may be improved if its documentation begins early, when changes are still relatively easy to make. On-line documentation can certainly be prepared (and changed) more quickly than printed user manuals, which suggests that early on-line documentation may help interface designers as well as the eventual system users.
Preparation of user guidance material will serve to indicate the point of diminishing returns in further elaboration of user interface software. If it takes ten minutes for a user to learn a special procedure that might save ten seconds in a seldom-used transaction, then design elaboration has outpaced user needs. Considering questions of user guidance throughout interface design will ensure that a sensible balance is struck between efficiency of operation and ease of learning, between functionality and usability. This practical trade-off has been noted by others concerned with user interface design (e.g., Goodwin, 1982), but requires continuing emphasis.
There is clearly an intimate relation between user guidance and interface design. The argument presented above that preparation of user guidance might help improve interface design can also be reversed. That is to say, interface designers can often help to improve user guidance. Preparation of user guidance should not be left solely the separate responsibility of technical writers who were not involved in the design process. Interface designers should participate as well.
In the course of design, a designer must sometimes make decisions that favor one group of users at the expense of another. As an example, for a system that will be used frequently by most of its users, a designer might choose to emphasize flexibility over simplicity when those two design goals conflict, while understanding that this priority could handicap some people who will use the system only occasionally. This priority would be reflected in the designer's choice of dialogue type, in the availability of control options, in display layouts, etc. A thoughtful designer can sometimes predict that users will have difficulty with particular design features. When that is the case, the designer's insight can contribute to the development of effective user guidance material.
In considering guidelines for design of user guidance functions, we must recognize that user guidance is a pervasive concern in interface design. Many of the guidelines proposed for data entry, data display, and sequence control functions have the implicit objective of making a system easier to learn and easier to understand during its use. From general recommendations for design consistency, through more detailed guidelines to help distinguish different aspects of information handling transactions, there must be an underlying concern for guiding the user's interaction with the computer. Thus almost any guideline for user guidance could be cross-referenced to a wide range of other design recommendations. Of the many possible cross references, a number of specific interest are cited in the guidelines proposed here.
Consistency of operational procedures Efficient use of full system capabilities Minimal memory load on user Minimal learning time Flexibility in supporting different users
User guidance refers to error messages, alarms, prompts, and labels, as well as to more formal instructional material.
Design standard procedures for accomplishing similar, logically related transactions.
Standard procedures will facilitate user learning and efficient system operation.
A designer might argue that for one particular transaction a standard procedure does not seem efficient. Perhaps the standard procedure requires one or two more keystrokes than some special procedure that might be devised. But every special feature of interface design will put a small added burden on the user's memory, and where special procedures are not remembered they may not be used properly. Standard procedures will increase overall operational efficiency.
Require users to take explicit actions to specify computer data processing; the computer should not take extra (and possibly unrecognized) actions beyond those specified by a user.
Automatic cross file updating following data change might be considered an exception to this rule.
Explicit actions, even though they may require an extra keystroke or two, will help a user to learn procedures and to understand better what is happening in any transaction. In effect, requiring the user to take action to accomplish something can be regarded as a form of guidance.
An interface designer, with expert knowledge of the system and its internal workings, is sometimes tempted to provide the user with "smart shortcuts", where the computer will execute automatically some action that the user would surely need to take. Incorporating such smart shortcuts in interface design, though done with the intention of helping the user, will risk confusing any but the most expert users.
1.0/9 | 1.7/4 | 3.0/5 | 3.1.4/9 | 3.2/1 | 6.0/9
In applications where users must log on to the system, design LOG-ON as a separate procedure that is completed before a user is required to select among any operational options.
Separate LOG-ON will focus user attention on the required input(s), without the distraction of having to anticipate other decisions, and will help reduce initial confusion, particularly for novice users.
In general, follow recommendations for the design of data displays when designing user guidance displays.
Some of the specific guidelines for data display are restated for convenient reference in this section, as particularly appropriate for display of user guidance. Many other applicable data display guidelines are cited by cross reference.
Tailor the display for any transaction to the current information requirements of the user, so that only relevant data are displayed.
When this can be done successfully, so that only relevant data are displayed, the display itself provides implicit guidance, showing what data should be considered. Conversely, display of irrelevant data will tend to confuse the user.
Create display formats with a consistent structure evident to the user, so that any particular type of data is always presented in the same place and in the same way.
Consistent display formats will help new users learn to interact efficiently with the system.
1.4/24 | 1.4/25 | 2.0/6 | 2.5/1 | 2.7.1/4 | 3.0/8 | 3.1.3/8 | 3.1.3/32 | 3.1.5/2 | 3.4/7 | 4.4/8
Format each different type of user guidance consistently across displays.
Display titles might be centered at the top of the display, with display identification codes at the upper left corner. The bottom line of the display should be reserved for command entries, where needed, in which case the line just above it could be used for prompts and advisory messages.
Types of user guidance include display titles, labeling of data entry fields, prompts for data/command entry, error messages, alarms, status and other advisory messages, as well as on-line instructional material.
Consistent allocation of particular areas of a display for user guidance may be sufficient. Certain types of guidance, however, such as alarms and error messages, may require auxiliary coding to help attract user attention.
Design display formats so that user guidance material is readily distinguishable from displayed data.
Consistent location of user guidance on the display will usually suffice, but other formatting conventions may help distinguish particular categories of user guidance, such as labels, prompts, etc., as recommended in other guidelines.
1.4/16 | 1.5/2 | 2.2/8 | 2.5/2 | 3.1.3/20 | 3.1.4/17
Design cursors (in terms of shape, blink, or other means of highlighting) so that they are readily distinguished from other displayed items.
When a cursor is automatically positioned under computer control, it can serve to direct the user's attention to a particular point on a display, and so it should be designed to catch the eye. Even when the cursor has been positioned by a user, if the user is momentarily distracted then a distinctive format may help locate the cursor.
A cursor is the most immediate and continuously available form of user guidance, since it will generally mark the current focus of user attention. With this in mind, the interface designer may decide to use different cursor formats to denote different operational conditions. If that is done, each of those different cursors should be distinctive from other displayed items, and from each other.
Label function keys and other controls clearly to indicate their function.
Label all displayed data clearly.
Labels for individual data fields can be omitted only where display format and labeling of grouped data clearly identify subordinate items, as in row/column labeling of tabular data.
1.4/5 | 1.4/19 | 1.4/20 | 1.4/21 | 1.4/23 | 1.5/3 | 2.2/3
Whatever methods are used to highlight critical items in data display, adopt similar methods to highlight the display of critical user guidance information.
Alarms and warning messages may require output of auxiliary auditory signals as well as display highlighting, to help assure that they attract the user's attention.
Ensure that symbols and other codes have consistent meanings from one display to another.
This practice will aid user learning of new codes, so that they will gain familiarity. Where codes have special meanings, those should be defined in the display.
2.6/7 | 2.6/16 | 2.6/32 | 3.1.3/13 | 4.4/21
Ensure that codes and abbreviations for data entry/display conform to conventional usage and user expectations.
Conventional usage will aid user learning of codes, and reduce the likelihood of user error in code generation (entry) and code interpretation (display).
Deviation from familiar meanings, such as using an aircraft symbol to denote artillery and vice versa, would almost certainly confuse users.
Ensure that the names for function keys, command names, etc., are consistent for similar or identical functions in different transaction sequences.
As a negative example, do not call the same function EDIT in one place, MODIFY in another, UPDATE in a third.
Consistency in interface design is the fundamental basis of effective user guidance.
3.0/10 | 3.1.3/12 | 3.1.3/14 | 3.1.3/19 | 3.1.5/7
When wording labels, prompts and user guidance messages, adopt terminology familiar to users.
(Good)
| Data requires special access code; | | call Data Base Admin, X 9999. |
(Bad)
| IMS/VS DBMS private data; see DBSA, 0/99-99. |
User testing and iterative design will often be needed to eliminate difficult words, abbreviations and acronyms that are not generally familiar to all users.
Adopt task-oriented wording for labels, prompts and user guidance messages, incorporating whatever special terms and technical jargon may be customarily employed in the users' tasks.
Jargon terms may be helpful, if they represent the jargon of the user and not of the designer or programmer. The rule here should be to know the users and adapt interface design to their vocabulary instead of forcing them to learn new wording.
1.4/22 | 2.0/12 | 3.1.5/6 | 3.1.5/7 | 3.2/9
Choose wording for user guidance that is consistent with the words used for control entries.
(Good)
| To delete a paragraph, press DELETE and then PARAGRAPH. |
(Bad)
| To erase a paragraph, press DELETE and then PARAGRAPH. |
If a user must complete a control form to specify printer settings, the words used as labels on that form should also be used in any error messages and HELP displays which may guide that process.
When selecting or composing control entries, a user will tend to mimic the vocabulary, format, and word order used in computer displays, including labels, error messages, HELP displays, etc. If displayed wording is consistent with required entries, a user will be more likely to make a correct entry on the first try.
Consistent wording of user guidance will be particularly helpful for dialogues based on constrained natural language. If a designer begins by determining which words and formats users are likely to choose naturally, and then reinforces that usage by incorporating such wording in user guidance, much of a user's interaction with the computer will be predictable. Therefore, the "natural language" need not accommodate the full range of possible entries, but only those entries which users are likely to make.
Choose wording for user guidance that speaks directly to a user, rather than talking about users.
(Good)
| Press ENTER to continue. |
(Bad)
| The user should press ENTER to continue. |
Adopt affirmative rather than negative wording for user guidance messages.
(Good)
| Clear the screen before entering data. |
(Bad)
| Do not enter data before clearing the screen. |
Affirmative statements are easier to understand. Tell the user what to do rather than what to avoid.
Adopt active rather than passive voice in user guidance messages.
(Good)
| Clear the screen by pressing RESET. |
(Bad)
| The screen is cleared by pressing RESET. |
Sentences in active voice are easier to understand.
When user guidance describes a sequence of steps, follow that same sequence in the wording of user guidance.
(Good)
| Enter LOG-ON sequence before running programs. |
(Bad)
| Before running programs, enter LOG-ON sequence. |
Be consistent in grammatical construction when wording user guidance.
(Good) (Bad) | Options: | | Options: | | s = Select data | | s = Select data | | e = Erase display | | e = Erasure function | | w = Write file | | w = Write file |
Even minor inconsistencies can distract a user, and delay comprehension as the user wonders momentarily whether some apparent difference represents a real difference.
Consistent grammatical construction may help a user resolve an ambiguous message (e.g., | Numeric entry |) to understand whether it recommends an action (e.g., "You should enter a number") or indicates an error condition (e.g., "You entered a number when you shouldn't have").
When techniques adopted for user guidance (display of option lists, command prompting, etc.) may slow an experienced user, provide alternative paths or modes permitting a user to by-pass standard guidance procedures.
Multiple paths, such as command entry to by-pass a menu, or use of abbreviated rather than complete commands, can speed the performance of an experienced user. The interface designer, however, should take care that such shortcuts supplement rather than supplant the standard, fully guided procedures provided for novice users.
Allow users to switch easily between any information handling transaction and its associated guidance material.
Guidance might be displayed as a temporary "window" overlay on the working display, which a user could request or suppress at will.
If user guidance is difficult to obtain, and/or if asking for guidance will disrupt a current transaction (e.g., erase a working display), then users will prefer to guess at proper procedures rather than seeking help.
Consider computer-generated speech output for user guidance messages in environments with low ambient noise, when a user's attention may not be directed toward a visual display or when providing a visual display is impractical.
Computer-generated speech might be used to provide prompts or status messages, including warnings. A familiar example of the use of computer-generated speech for warnings is the "talking dashboard", which tells a car driver when a door is open, or when the car requires service.
A noisy environment, particularly noise from other voices, will make it difficult for a user to hear computer-generated speech.
Auditory signals such as computer-generated speech are useful for notifying a user of important information when his/her attention is focused somewhere other than a visual display, such as when a touch-typist transcribes data from a paper form.
Speech output might also help a user who must access a computer from a remote location, by telephone.
When considering speech output for user guidance, remember that people other than the user might hear those spoken messages. Speech output may prove distracting to other people trying to work nearby. Or the user of a system may not wish others to hear his/her messages, as might be the case if spoken messages were provided for an automated banking application.
Limit computer-generated speech to provide only a few messages.
As negative examples, computer-generated speech would not be useful if many messages might be given at one time, or for conveying a lengthy list of menu options.
When messages are spoken, the user must remember each message. If many different messages are given one after another, then a user would probably not remember them all, and might only remember one or two.
When using computer-generated speech to provide messages, ensure that those messages are short and simple.
If a user does not understand a written message, s/he can reread it. That is not the case with spoken messages. Though a REPEAT function might be provided, a better solution is to restrict use of speech outputs for short and simple messages.
If a user who may not be watching a display must be given long or complex messages, it is probably better to provide a simple auditory signal such as a chime, and then display the messages visually for the user to read. In general, users will understand complex messages better when they see them displayed than when they hear them.
If computer-generated speech is used to provide warnings as well as other forms of user guidance, ensure that spoken warnings are easily distinguishable from routine messages.
Speech output used to identify dangerous conditions might use some distinctive voice (perhaps female rather than male, or vice versa) and/or preface each warning message with some other distinctive auditory signal.
In some applications, computer-generated speech might be useful for providing a few short and simple warnings. However, if speech output is also used for other purposes, then the warning messages must be distinctive.
Status information on current data processing should be available at all times, automatically or by request.
Provide some indication of system status to users at all times.
In some applications, system status may be continuously displayed. Status display can be explicit (e.g., by message), or can be implicit (e.g., by a displayed clock whose regular time change offers assurance that the computer link is still operating). Alternatively, system status information might be provided only on user request, following a general or specific query.
Status information is particularly needed, of course, when system operation is unreliable for any reason. Under those conditions, if status information is not provided by design, users will often devise their own repertoire of harmless but time-wasting inputs to test system performance.
When system status changes, it may be desirable for the computer to generate an advisory message to draw users' attention to that change.
When users must log on to a system, display appropriate prompts for LOG-ON procedures automatically at a user's terminal; do not require users to take any special action to obtain a LOG-ON display, other than turning on the terminal.
An automatic LOG-ON display will signal the operational availability of a terminal, as well as prompting the user to make necessary initial inputs.
If a user tries to log onto a system and LOG-ON is denied because of system unavailability, display an advisory message to tell the user what the system status is and when the system will become available.
| System is down for maintenance until 9:30 AM. |
Avoid "as soon as possible" messages. Make an estimate of system availability, and update the estimate later if that becomes necessary.
If at any time the keyboard is locked, or the terminal is otherwise disabled, notify the user.
Control lockout might be signaled by disappearance of the cursor from the display, or by a notable change in the shape of the cursor, accompanied by an auditory signal.
An auditory signal will be especially helpful to touch-typists, who may be looking at source documents for data entry rather than at the display or keyboard.
When the results of user action are contingent upon different operational modes, then clearly indicate the currently selected mode.
A change in display caption and/or cursor shape might suffice to alert users to changing modes.
When task performance requires data exchange and/or interaction with other users, allow a user to obtain status information concerning other people currently using the system.
If there are many other users, it might be helpful to allow a user to ask whether any particular individual is a current user.
When task performance is affected by operational load (e.g., number of on-line users), allow a user to obtain status information indicating current system performance, expressed in terms of computer response time.
It may be necessary to define a "standard" function for which computer response time is predicted on a normalized basis.
Such load information is primarily helpful, of course, when system use is optional, i.e., when a user can choose to defer work until low-load periods. But load status information may help in any case by establishing realistic user expectations for system performance.
When task performance requires data exchange and/or interaction with other systems, allow a user to obtain relevant status information for external systems.
When task performance requires or implies the need to assess currency of information, annotate displays with date-time signals.
Depending on the application date-time status might be displayed continuously or periodically on displays that are automatically updated, or by user request.
When alarm signals are established on the basis of logic defined by users, permit users to obtain status information concerning current alarm settings, in terms of dimensions (variables) covered and values (categories) established as critical.
Alarm status information will be particularly helpful in monitoring situations where responsibility may be shifted from one user to another ("change of watch").
Routine feedback should be provided by a computer to its users as transactions are processed.
Ensure that every input by a user will consistently produce some perceptible response output from the computer; when a terminal is in use, its display screen should never be blank.
A user might choose to blank a display screen temporarily, perhaps to protect data from casual onlookers, but even then some acknowledging message should probably appear, e.g.,
| Display temporarily suppressed. |
Keyed entries should appear immediately on the display. Function key activation or command entries should be acknowledged either by evident performance of the requested action, or else by an advisory message indicating an action in process or accomplished. Inputs that are not recognized by the computer should be acknowledged by an error message.
Absence of system response is not an effective means of signaling acceptable entry. At best, a dialogue without feedback will be disconcerting to the user, as when we talk to an unresponsive human listener. At worst, the user may suspect system failure, with consequent disruption and/or termination of the interaction sequence.
1.0/3 | 1.0/12 | 1.0/13 | 3.0/14 | 3.0/16 | 3.1.3/9 | 3.1.4/10 | 6.2/6
Ensure that computer response to user entries will be rapid, with consistent timing as appropriate for different types of transactions.
1.1/5 | 2.7.1/6 | 3.0/18 | 3.1/2
Provide some indication of transaction status whenever the complete response to a user entry will be delayed.
After making an entry to the computer, the user needs feedback to know whether that entry is being processed properly. Delays in computer response longer than a few seconds can be disturbing to the user, especially for a transaction that is usually processed immediately. In such a case some intermediate feedback should be provided, perhaps as an advisory message that processing has been initiated, and ideally with an estimate of how long it will take to complete.
Indicating the progress of computer processing is particularly important when response time is inconsistent and may be lengthy, which is often the case when users perform complex functions on time-shared systems. Displaying time-to-completion or some other indication of progress will permit users to plan their time more effectively, and perhaps to perform other tasks while waiting.
Note that a routine advisory (e.g., | Wait for processing |) displayed before every computer response, whether fast or slow, is not an effective indication of transaction status. Users will come to ignore routine messages that are sometimes true but sometimes just false alarms.
When computer processing of a user entry has been delayed, inform the user when processing is completed, and provide appropriate guidance for further user actions.
For long delays, interim feedback on processing status before completion may be reassuring to a user. Such follow-up messages, however, should not interfere with current user activities. It may be desirable to reserve a special display window for prompts and advisory messages.
When user requests for printed output will be handled by a remote printer, give the user an advisory message confirming that a print request is being processed.
Provide a unique identification for each display in a consistent location at the top of the display frame.
As a possible exception, interface designers may sometimes provide unlabeled displays as "free-form" screens for text entry and other tasks involving display composition by users.
A displayed title may suffice, although a shorter identification code may be helpful for some purposes. The objective is to help the user recognize a display when it appears, to learn interactive sequences stepping from one display to another, and (in some system applications) to request a particular display directly. Display identification will also help both users and interface designers to refer to individual displays in discussion and documentation.
In applications involving menu selection, it may prove helpful to code each display with the string of option selections (letter codes) used to reach that display. This practice is particularly useful in situations where a user can learn to by-pass the menu selection sequence by entering option string codes as a single command to request a familiar data display.
2.5/10 | 2.7.1/2 | 2.7.1/3 | 2.7.1/4
When lists or data tables extend beyond the capacity of a single display frame, inform the user that the display is continued in multiple frames.
Incomplete lists might be annotated at the bottom as
| Continued on next page |
For extended data tables, the display title might be annotated as
| Page ____ of ____ |
For scrolled data, displays might be annotated with the current and concluding locations
| Line ____ of ____ |
In special formats such as spreadsheets the partial nature of a display may be self-evident.
As a complementary recommendation, it may also be desirable to conclude completed lists with the annotation
| End of list |
unless the list is so short that it obviously does not fill available display space.
When a user (or computer) action establishes a change in operational mode that will affect subsequent user actions, display some continuing indication of current mode.
Selection of a DELETE mode in text editing should produce some kind of warning signal on the display, perhaps by a distinctive change in cursor shape.
This practice is particularly helpful when the mode selected is one seldom used.
Display of mode selection will help prevent unintended data loss when the mode is potentially destructive (e.g., DELETE). For destructive modes, it may help if the mode indication is implemented as some sort of distinctive change in the appearance of the cursor, since the cursor is probably the one display feature most surely seen by a user.
3.4/4 | 3.4/5 | 4.1/5 | 4.4/13 | 6.0/15 | 6.0/16
When previously selected options are still operative, display those options either automatically or on user request.
Displaying a cumulative sequence of option selections may help a novice user learn transaction sequences, and may help any user deal with complex transactions.
When a user selects a displayed item in order to perform some operation on it, highlight that item on the display.
This practice will provide a routine natural feedback that item selection has been accomplished, and will provide a continuing reminder to the user of just what selection has been made.
Highlighting might be accomplished in different ways. Reverse video is commonly employed for this purpose. For a selection among displayed options, the selected option might be brightened.
Following user interrupt of data processing, display an advisory message assuring the user that the system has returned to its previous status.
Error feedback should be provided if an error or other unexpected event prevents routine processing.
When the computer detects an entry error, display an error message to the user stating what is wrong and what can be done about it.
(Good)
| Code format not recognized; enter two letters, | | then three digits. |
(Bad)
| Invalid input. |
Users should not have to search through reference information to translate error messages.
Error messages can be regarded as the most important form of system documentation. Well designed error messages will give help to users automatically, at the point where help is most needed.
Make the wording of error messages as specific as possible.
(Good)
| No record for Loan 6342; check number. |
(Bad)
| No record for inquiry. |
Specificity will require computer analysis of data processing transactions in context.
Adopt wording for error messages which is appropriate to a user's task.
(Good)
| Contract number not recognized; check | | the file and enter a current number. |
(Bad)
| Entry blocked. Status Flag 4. |
Error messages that can be understood only by experienced programmers (and interface designers) will have no value for ordinary users.
If a data entry or (more often) a control entry must be made from a small set of alternatives, an error message that is displayed in response to a wrong entry should indicate the correct alternatives.
Make error messages brief but informative.
(Good)
| Entry must be a number. |
(Bad)
| Alphabetic entries are not acceptable because | | this entry will be processed automatically. |
Often a user will recognize that an error has been made, and the message will serve merely as a confirming reminder. In such instances, short error messages will be scanned and recognized more quickly.
For a user who is truly puzzled, and who needs more information than a short error message can provide, auxiliary HELP can be provided either on-line or by reference to system documentation.
If an on-line HELP explanation is not available, a user may have to refer to system documentation for a coded listing of possible errors. Under those circumstances, some designers display each error message with an identifying code, to facilitate rapid reference to documentation. That practice might help experienced users, who would gradually come to recognize the codes.
Adopt neutral wording for error messages; do not imply blame to the user, or personalize the computer, or attempt to make a message humorous.
(Good)
| Entry must be a number. |
(Bad)
| Illegal entry. |
(Bad)
| I need some digits. |
(Bad)
| Don't be dumber, use a number. |
Error messages should reflect a consistent view that the computer is a tool, with certain limitations that a user must take into account in order to make the tool work properly. If error messages reflect an attitude that the computer (or its programmer) imposes rules, or establishes "legality", the user may feel resentful. If error messages reflect personalization of the computer, as if it were a friendly colleague, a naive user may be misled to expect human abilities the machine does not actually possess. If error messages are worded humorously, any joke will surely wear thin with repetition, and come to seem an intrusion on a user's concern with efficient task performance.
The same considerations apply for the wording of computer-generated prompts and other instructional material.
Following the output of a simple error message, permit users to request a more detailed explanation of the error.
A more complete discussion of each error could be made available on-line, perhaps at several levels of increasing detail, supplemented by reference to off-line system documentation if necessary. Successively deeper levels of explanation might then be provided in response to repeated user requests for HELP.
When multiple errors are detected in a combined user entry, notify the user, even though complete messages for all errors cannot be displayed together.
| DATE should be numeric. | | + 2 other errors |
The computer should place the cursor in the data field referred to by the displayed error message, with other error fields highlighted in some way, e.g., by reverse video. There should also be some means for the user to request sequential display of the other error messages if needed.
If a user repeats an entry error, there should be some noticeable change in the displayed error message.
A simple expedient might be to display the same verbal message but with changing annotation, perhaps marked with either one asterisk or two.
If an error message is repeated identically, so that displayed feedback seems unchanged, the user may be uncertain whether the computer has processed the revised entry.
The computer should display an error message only after a user has completed an entry.
An error message should not be generated as wrong data are keyed, but only after an explicit ENTER action has been taken.
In general, the display of error messages should be timed so as to minimize disruption of the user's thought process and task performance.
Display an error message approximately 2-4 seconds after the user entry in which the error is detected.
For type-ahead systems with experienced users, error messages should be displayed as quickly as possible.
Longer delays in error feedback may cause user uncertainty or confusion. Longer delays may also cause frustration if the user is already aware of the error, which is often the case.
Shorter delays in error feedback can pose problems of a different sort. An error message following immediately upon a user entry can be disconcerting. Immediate error feedback can also be irritating. User expectations are conditioned by human conversation, where an immediate contradiction is considered rude, and where a polite listener will pause for a few moments before saying that you are wrong.
If error messages take somewhat longer to appear than the routine computer response, then that additional delay may cue the user to expect an error message and pay attention to it.
As a supplement to on-line guidance, include in the system documentation a listing and explanation of all error messages.
Developing good error messages may require review by both designers and users. Documentation of the complete set of error messages will facilitate such review.
Documentation of error messages will permit users to reference particular messages for fuller explanation, and to review all messages as a means of understanding data processing requirements and limitations.
In addition to providing an error message, mark the location of a detected error by positioning the cursor at that point on the display, i.e., at that data field or command word.
Displaying the cursor at a non-routine position will help emphasize that an error has occurred, and direct the user's attention to the faulty entry.
When an entry error has been detected, continue to display the erroneous entry, as well as an error message, until corrections are made.
The error itself may provide useful information, in conjunction with the error message, helping a user understand the specific nature of the error.
Following error detection, require the user to re-enter only that portion of a data/command entry which is not correct.
The user should not have to rekey an entire command string or data set just to correct one wrong item.
3.1.5/23 | 3.5/3 | 6.0/10 | 6.3/10
Ensure that a displayed error message is removed after the error has been corrected; do not continue to display a message that is no longer applicable.
The immediate removal of an error message upon error correction will serve as feedback to a user that the corrected entry is indeed correct.
When a data or command entry seems doubtful, in terms of defined validation logic, display a cautionary message asking the user to confirm that entry.
| Blood pH of 6.6 is outside the normal range; | | confirm or change entry. |
Feedback to the user can be worded to deal with a range of intermediate categories between a seemingly correct entry and an outright error.
Require the user to take some explicit action to confirm a potentially destructive data/command entry before the computer will execute it.
A requirement to take an explicit CONFIRM action will direct user attention to questionable entries and help the user avoid the consequences of thoughtless errors.
What constitutes "potentially destructive" requires definition in the context of each system application.
3.5/7 | 6.0/18 | 6.0/20 | 6.3/19
For conditions requiring (or implying the need for) special user attention, code the alarms (or warning messages) distinctively.
Alarm messages might be marked with a blinking symbol and/or displayed in red, and be accompanied by an auditory signal; warnings and error messages might be marked with a different special symbol and/or displayed in yellow.
This practice will help ensure appropriate attention, even when a user is busy at routine tasks.
2.6/12 | 2.6/32 | 2.6/35 | 2.6/40 | 3.6/2 | 6.0/17
Job aids should provide users with specific task-oriented guidance for every transaction.
Ensure that specific user guidance information is available for display at any point in a transaction sequence.
Do not require a user to remember information not currently displayed. The user should not have to remember what actions are available, or what action to take next. Human memory is unreliable, and without guidance users can be expected to make errors.
2.0/3 | 2.7.2/1 | 3.1.3/17 | 3.1.3/18 | 3.2/4 | 3.2/5
Provide a general list (menu) of control options that is always available to serve as a "home base" or consistent starting point to begin a transaction sequence.
Display menu options in logical groups.
Logical grouping of menu options will aid user learning and selection among displayed alternatives. It may be necessary to test proposed menus to determine just what structural groupings will seem logical to their intended users.
When hierarchic menus are used, organize and label them to guide users within the hierarchic structure.
Users will learn menus more quickly if a map of the menu structure is provided as HELP.
3.1.3/24 | 3.1.3/25 | 3.1.3/30
At every point in a transaction sequence, provide guidance telling the user how to continue.
(Good)
| Data are current through March 1986. | | Press STEP key to continue. |
(Bad)
| Data are current through March 1986. |
If there are control options that are specifically appropriate to the current transaction, indicate those options on the display.
Treat control options that are generally available at every step in a transaction sequence (PRINT, perhaps) as implicit options that need not be included in a display of specific current options.
Usually space can be found on a working display to remind users of several specific control options that are appropriate to the current transaction. A list of all available options, however, may well exceed display capacity. A user may be expected to remember general options, once they have been learned, without their specific inclusion in a display of guidance information. Perhaps the best design approach is to implement general options on appropriately labeled function keys, which will aid user learning and provide a continuing reminder of their availability.
Provide advisory messages and other prompts to guide users in entering required data and/or control parameters.
Prompting in advance of data/control entry will help reduce errors, particularly for inexperienced users. Prompting might be provided as an optional feature for skilled users.
If a default value has been defined for null entry, that value should be included in the prompting information.
1.0/24 | 1.8/4 | 3.1.5/11 | 3.2/11 | 3.5/5
Display prompts for data/command entry in a standard location, next to the command entry area at the bottom of the display.
As an alternative, prompts might be provided in a window overlay added to a working display at user request.
Use consistent phrasing and punctuation in all prompts.
(Good)
| Save as new file or Overwrite old file (S/O): |
and
| Create new file or Edit old file (C/E): |
(Bad)
| (S)ave as new file or (O)verwrite old file: |
and
| Would you like to create a new | | file or edit an old file (C/E): |
Choose a standard symbol for prompts indicating that an entry is required, and reserve that symbol only for that purpose.
(Good)
| Enter completion code: |
(Bad)
| Enter completion code |
Some standard prompting symbol in data entry forms, in menus, in command entry lines, etc., will help to cue users that an input is required. That standard symbol, used along with other formatting cues, will help to alert a user to differences between advisory messages and messages requiring an input.
Use concise wording for prompts; eliminate extraneous words.
(Good)
| Delete what: |
(Bad)
| What text would you like to delete: |
When users vary in experience, which is often the case, provide prompting as an optional guidance feature that can be selected by novice users but can be omitted by experienced users.
Flexibility in prompting can also be provided by multilevel HELP options, so that additional guidance information can be obtained if the simple prompt is not adequate.
When the results of a user entry depend upon context established by previous entries, display some indication of that context to the user.
When the effects of user entries are contingent upon different operational modes, indicate the current mode.
If the user is editing a data file, display both the file name and an indication of EDIT mode.
2.7.3/6 | 2.7.3/7 | 3.0/9 | 3.1.4/5 | 3.1.4/11 | 3.4/1 | 3.4/4 | 3.4/5 | 4.1/5 | 4.2/8
In a transaction involving extended data entry, display a cumulative record of any previous inputs that are relevant to the current input.
In a multipage data entry display, do not rely on the user to remember data accurately from one page to the next.
Provide cues for data entry by formatting data fields consistently and distinctively.
A colon might be used consistently to indicate that an entry can be made, followed by an underscored data field to indicate item size, such as
| Enter part code: __ __ __-__ __ |
or perhaps just simply
| Part code: __ __ __-__ __ |
Consistent use of prompting cues can sometimes provide sufficient guidance to eliminate the need for more explicit advisory messages.
1.4/10 | 1.4/11 | 1.4/12 | 1.4/18
As the last step in generating a display output, ensure that the computer will automatically position the cursor so that it appears in a consistent display location for each type of transaction.
For data entry displays, the cursor should be placed initially at the first data field, or else at the first wrong entry if an error has been detected; in other displays, the cursor might be placed at a consistent HOME position, or at the first control option for menu selection, or else in a general command entry area, depending upon the type of display.
Consistent cursor positioning will provide an implicit cue for user guidance.
1.1/20 | 1.1/21 | 1.4/28 | 3.2/6 | 3.2/7 | 4.3/13
Provide reference material describing system capabilities and procedures available to users for on-line display.
Many systems are not utilized effectively because users do not fully understand system capabilities. On-line access to a description of system structure, components and options will aid user understanding.
On-line guidance can supplement or in some instances substitute for off-line training. An investment in designing user aids may be repaid by reduced costs of formal training as well as by improved operational performance.
In applications where the user can choose what stored data to display, provide an on-line data index to guide user selection.
The data index should indicate file names, objects, properties, and other aspects of file structure that might be used to access different categories of data. It may help to allow users to specify what they require in this index. Some users might wish information on file size, currency (time of latest update), etc. Other users might wish to add a short description of each data file to remind themselves of its contents.
In applications where a user can employ command entry, provide an on-line command index to guide user selection and composition of commands.
Such a command index may help a user to phrase a particular command, and will also be generally helpful as a reference for discovering related commands and learning the overall command language.
Provide a complete dictionary of abbreviations used for data entry, data display, and command entry, both for on-line user reference and in design documentation.
In applications where users can create their own abbreviations, as in the naming of command "macros", it will be helpful to provide aids for users to create their own individual on-line dictionaries.
When codes are assigned special meaning in a particular display, include a definition of those codes in the display.
This practice will aid user assimilation of information, especially for display codes that are not already familiar.
Allow users to request a displayed record of past transactions in order to review prior actions.
In addition to explicit aids (labels, prompts, advisory messages) and implicit aids (cueing), permit users to obtain further on-line guidance by requesting HELP.
It is difficult for an interface designer to anticipate the degree of prompting that may be required to guide all users. Moreover, even when prompting needs are known, it may be difficult to fit all needed guidance information on a display page. One possibility would be to provide user guidance in a window overlay added to a working display when a user requests HELP. If more extensive user guidance is needed, then a separate, full-screen HELP display might be provided.
Provide a simple, standard action that is always available to request HELP.
HELP might be requested by an appropriately labeled function key, or perhaps by keying a question mark into a displayed entry area.
A user should be able to request HELP at any point in a transaction sequence. The procedure should always be the same, whether the user wants an explanation of a particular data entry, a displayed data item, or a command option.
Tailor the response to a HELP request to task context and the current transaction.
If a data entry error has just been made, HELP should display information concerning entry requirements for that particular data item.
If an error in command entry has just been made, HELP should display information concerning that command, its function, its proper structure and wording, required and optional parameters, etc.
When a request for HELP is ambiguous in context, the computer should initiate a dialogue in which the user can specify what data, message or command requires explanation.
The computer might ask a user to point at a displayed item about which HELP is requested.
When a user requests HELP on a particular topic, the computer should accept synonyms for standard system terminology.
If a DELETE command exists, then an explanation of that command might be displayed when a user requests HELP for ERASE.
Users will often attempt to get HELP for a function they know exists, but cannot remember its correct name.
Likely synonyms can be identified by compiling a list of function names used in other similar systems. Other synonyms can be discovered through user testing. It might be desirable to let HELP facilities grow to meet user needs by allowing a system administrator to add synonyms to the system.
When an initial HELP display provides only summary information, provide more detailed explanations in response to repeated user requests for HELP.
It is necessarily a matter of judgment just what information should be provided in response to a HELP request. Designing the HELP function to provide different levels of increasing detail permits users to exercise some judgment themselves as to just how much information they want.
Permit users to browse through on-line HELP displays, just as they would through a printed manual, to gain familiarity with system functions and operating procedures.
Where appropriate, provide an on-line training capability to introduce new users to system capabilities and to permit simulated "hands on" experience in data handling tasks.
On-line simulation, using the same hardware, user interface software and data processing logic as for the real job, can prove an efficient means of user training. Care must be taken, however, to separate the processing of simulated data from actual system operations.
Anticipate the needs of different users, and offer different levels of training for on-line job support.
In systems supporting different user jobs, on-line instruction might describe the procedures for each different data handling task.
Instruction on keyboard use and lightpen selection of menu options might be provided for novice users, while a tutorial on command language might be provided for more experienced users.
3.0/3 | 3.1/1 | 3.1.3/35 | 3.1.5/4 | 4.0/24
In applications where a user must learn complex tasks, design computer-mediated training to adapt automatically to current user abilities.
Adaptive training will require some means for computer assessment of appropriate components of user performance.
User records will permit assessment of performance and improvement of user interface design.
In applications where skilled user performance is critical to system operation, provide automatic computer recording and assessment of appropriate user abilities.
Recording individual performance may be constrained by other considerations, as noted elsewhere in this section.
Inform users of any records kept of individual performance.
Informing users concerning the nature and purpose of performance records is required by ethical principle, and in some situations may be required by law.
Recording individual performance is potentially subject to abuse, and requires careful scrutiny to ensure essential protection of user privacy. Designers must conform to whatever legal (or otherwise agreed) restrictions may be imposed in this regard.
Ensure that the computer can maintain records of user transactions.
Record keeping might include duration, sequencing and frequency of different transactions. Such transaction records will aid task analysis, particularly in developing systems where data handling requirements are not yet fully defined.
A buffered store of current transactions may be required for user guidance, and for other purposes such as supporting an UNDO capability.
In some applications, transaction recording might be made optional, under control of a system administrator.
Ensure that the computer can maintain records of data access, i.e., which data files, categories, or items have been called out for display.
Records of data use may help software designers improve file structure, reduce data access time, and manage multiple use of shared data files.
Data access records may also be required for purposes of data protection/security.
Ensure that the computer can maintain records of use for different portions of application software.
In some cases "program calls" can be derived from transaction records rather than having to be measured directly.
Records of software use may not affect user interface design directly, but can help detect and correct programming inefficiencies and improve system response, particularly during early stages of system development.
Provide a capability for recording user errors.
Error recording might be done continuously, or by periodic sampling under the control of a system administrator.
Error records can be used to indicate supplemental instruction needed by different users, if individual user errors are identified. In that case, ethical considerations (and in some instances legal considerations) dictate that users be informed that such records will be kept.
Error records can be used to indicate whether particular transactions are giving trouble to many users, in which case design improvements to the user interface may be needed, including changes to user guidance.
For an individual user, the computer might be programmed to generate a special on-line HELP sequence to guide the correction of repeated errors.
Provide a capability for recording user requests for HELP.
There is probably no need to record user browsing of HELP information, if such a capability is provided.
HELP records can be used to detect deficiencies in in early system development, and can be used to improve user guidance in later system operation. In effect, user requests for HELP might be regarded as a possible symptom of poor interface design. If HELP requests are frequent for a particular transaction, then some design improvement may be needed, in procedures, or prompting for user guidance, or both.
Design change of software supporting user guidance functions may be needed to meet changing operational requirements.
When user guidance requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to user guidance functions.
User guidance functions that may need to be changed include those represented in these guidelines, namely, changes in status information, routine and error feedback, job aids, and user records.
Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below.
In some applications, it may prove helpful to allow individual users to reword and/or add their own notes to on-line guidance material, just as they might annotate paper documentation.
4.3/12 | 4.4/3 | 4.4/20 | 4.4/27 | 4.5/3 | 4.5/4 | 4.5/5 | 4.5/6 | 4.5/7
When changes are made to interface design, including changes to user guidance functions and on-line documentation, inform users of those changes.
An on-line "message board" appearing at LOG-ON may suffice to notify users of current changes. But more extensive measures may be needed, including corresponding changes to user guidance information, e.g., prompts, error messages, HELP displays, etc.
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top< |