Simple and Natural Dialogue

The ideal is to present exactly the information the user needs - and no more - at exactly the time and place where it is needed. Information that will be used together should be displayed close together, and at a minimum on the same screen. Also, both information objects and operations should be accessed in a sequence that matches the way users will most effectively and productively do things. Sometimes such sequences are enforced by the user interface, but it is normally better to allow the user to control the dialogue as much as possible such that the sequence can be adjusted by the individual user to suit that user's task and preferences. Even so, the system may ease the user's understanding of the dialogue by indicating a suggested or preferred sequence, such as the sequence implied by the listing of fields in a dialog box from top to bottom.

Graphic Design and Color

Figure 1 Mumble screen layout for a hypertext system. The actual system is described in (Nielsen 1990a, 1990i). The screen could be made to abstract even further from the information content in the full system by replacing the icons with generic shapes.

Screen layouts should use the gestalt rules for human perception to increase the users' understanding of relationships between the dialogue elements. These rules say that things are seen as belonging together, as a group, or as a unit, if they are close together, are enclosed by lines or boxes, move or change together, or look alike with respect to shape, color, size, or typography. For example, in Figure 2, most people will perceive two major groups of objects due to the closeness of the objects within the groups compared with the distance between the groups. Then, most people would think that the left set of objects contained two sets of objects that were even more closely related, due to the enclosure of the six objects in the upper right corner and the highlighting of the four objects in the lower left corner. Also, the right set of objects will be perceived as containing three groups, and the middle one will be seen as standing out from the background since it is smaller.

Figure 2 Example of objects structured according to the gestalt principles of closeness, closure, and similarity.

These principles of graphic structure should be used to help the user understand the structure of the interface. For example, menus can use a dividing line or color coding (McDonald et al. 1988) to split options into related groups, each of which will be easier to understand because each option will be seen in a relevant context. Similarly, dialog boxes can group related features and enclose them in boxes or separate them by lines or white space. Also, since users will perceive structure based on these principles, care should be taken not to separate out unrelated objects in ways that make them seem as belonging together. For example, consider a bank statement with the following layout:

What is the balance? One or two thousand dollars? The closeness rule will make many people perceive the label Balance as being matched with the number $ 2,000, even though it may have been intended as a label for the line containing the number $1,000.

Principles of graphic design can also help users prioritize their attention to a screen by making the most important dialogue elements stand out. As shown by the right part of Figure 2, a small delineated area will stand out from the background, and one can also make objects stand out by highlighting them in various ways, including the use of bolder colors or typefaces, and by making them larger. Also, information that is presented "first," given the usual reading direction (that is, at the top and to the left in many cultures) normally gets more attention. It is even possible to attract the users' attention by using blinking objects, but blinking is so distracting and annoying that it should only be used in extreme cases. On alphanumeric terminals, UPPERCASE TEXT CAN ALSO BE USED TO GET THE USERS' ATTENTION, but upper case should be used sparingly as it is about 10% slower to read than mixed-case text.

With respect to the use of color in screen designs (Rice 1991; Travis 1991), the three most important guidelines are

• Don't over-do it. An interface should not look like an angry fruit salad of wildly contrasting, highly saturated colors. It is better to limit the design to a small number of consistently applied colors. Color-coding should be limited to no more than 5 to 7 different colors since it is difficult to remember and distinguish larger numbers, even though highly trained users can cope with about 11 colors (Durrett and Trezona 1982). Also, light grays and muted pastel colors are often better as background colors than screaming colors are.

• Make sure that the interface can be used without the colors. Remember that many people (about 8% of males) are colorblind, so any color-coding of information should be supplemented by redundant cues that make it possible to interpret the screens even without being able to differentiate the colors. For example, icons that are about to be deleted could be turned red for fast identification by users with full color vision and they could also be marked with an ×. The best test would be to have a selection of colorblind users try out the system, but it would be difficult to do so comprehensively as there are many different types of color blindness. (Being "colorblind" normally does not mean than one cannot distinguish any colors at all, so the expression is somewhat inaccurate. About 6% of males and 0.4% of females are partially red-green colorblind (and so can distinguish yellows and blues as well as some shades of green and red), 2% of males and 0.03% of females are fully red-green colorblind, and only 0.005% of males and 0.003% of females are yellow-blue or completely colorblind (Silverstein 1987). Therefore, a test with a single colorblind user (while much better than no such test) will not guarantee that all types of users with color-deficient vision will be able to use the interface without problems.) In addition to having at least some colorblind test users, one can also check how the interface looks on a monochrome screen. In many cases, some users will be limited to monochrome displays anyway.

• Try to use color only to categorize, differentiate, and highlight, not to give information, especially quantitative information.

It is true that some colors and color combinations are more visible than others (Durrett 1987), and you certainly would not want to present your help screens in light blue text on a bright yellow background. ( Detailed guidelines for choosing screen colors can be found in part 8 of ISO 9241 (an international standard for user interface issues). The content of this standard is discussed further by Smith (1988).) If the most obviously horrible color combinations are avoided, however, there is normally only a small additional benefit to be gained from searching out the absolutely optimal choice of colors.

Less Is More

Based on a proper task analysis, it is often possible to identify the information that is truly important to users and which will enable them to perform almost all of their tasks. It will then normally be better to design a single screen with this information and relegate less important information to auxiliary screens than to cram all the information that might possibly be useful into a set of screens that will require the user to switch screens for even the most simple tasks.

Other information may not even be necessary at all. For example, many programs follow the example of King Harald and dedicate large amounts of screen space to a display of the name of the program, the vendor's logo, the version number, and other similar information. Even though this information is potentially important and should be available for users making bug reports, it normally only takes up screen space that could have been used for other purposes (maybe even as white space to make for a better layout). And of course, any piece of information is something users will have to look at when they search the screen, and it will therefore slow down their performance by some fraction of a second. It is better to provide identifying information as part of a startup screen that can be extravagantly eye-catching and serve as feedback to the user that the appropriate program is being entered. Also, of course, identifying information about the program, its version, and its status should be accessible through the help system. As another example, headers with address and message routing information can be eliminated from displays of electronic mail and network news (Andersen et al. 1989) to be shown only in the rare case when a user actually needs this system-oriented information.

Extraneous information not only risks confusing the novice user, but also slows down the expert user. For example, a study of experienced telephone company directory assistance operators showed that finding a target that appeared in the top quarter of the screen took 5.3 seconds when the screen was half full of information and 6.2 seconds when the screen was full of information (Springer 1987). Saving 0.9 seconds may not seem like a lot, but for this specific application, it was estimated to reduce call processing costs by more than 40 million dollars per year.

The "less is more" rule does not just apply to the information contents of screens but also to the choice of features and interaction mechanisms for a program. A common design pitfall is to believe that "by providing lots of options and several ways of doing things, we can satisfy everybody." Unfortunately, you do have to make the hard choices yourself. Every time you add a feature to a system, there is one more thing for users to learn (and possibly use erroneously) and the manual gets bigger, more intimidating, and harder to search. One study found that the users' planning time for formula entry was 2.9 seconds in one spreadsheet and 4.6 in another (Olson and Nilsen 1987-88). The first spreadsheet was faster because it only provided a single method for formula entry and therefore did not require users to think about which method to use. In contrast, the second spreadsheet provided multiple methods, with the result that the users were slowed down more by having to choose between methods than the amount of time they sometimes gained from being able to use a "faster" method for certain formulas.

This does not mean that one should never provide alternative interaction techniques. Alternatives can be provided if users can easily recognize the conditions under which each one is optimal so that they can consistently choose the optimal interaction technique without additional planning. For training, users should at first be taught only the single, general method that is preferable in most common situations. Other methods can be taught later but should not be introduced at a stage when they will only confuse the novice user.

Sometimes, one can design an especially simple interface for novice users and shield them from any necessary complexity that may be needed by advanced users. Most systems doing this have only two levels of interface complexity: novice mode and expert mode, but in principle it might be possible to provide multiple nested levels of increased complexity. This nested design strategy is sometimes referred to as training wheels (Carroll 1990a).

Since novice users are often observed spending too much time recovering from errors, the training wheels approach can give them a system where they are blocked from even entering potential error situations. Of course, this limits the available functionality, but novice users probably do not need the advanced features anyway. In one experiment, novice users were able to learn basic use of a word processor and type a letter in 116 minutes when they were faced with the full system and in 92 minutes when they were given the training wheels system where actions leading to the most common errors were not available (Carroll and Carrithers 1984). Not only did the training wheels users get started faster, but they also liked the system better and scored slightly higher on a comprehension exam after the study. Even better, the initial use of the training wheels interface did not impair users when they later graduated to the full system. On the contrary, users who had learned the basics of the system with the training wheels interface learned advanced features faster than users who had been using the full system all the time (Catrambone and Carroll 1987).

Speak the Users' Language

As far as possible, dialogues should be in the users' native language and not in a foreign language. Of course, concerns for the users' "language" should not be limited to the words in the interface but should include nonverbal elements like icons.

As part of the general principle of speaking the users' language, one should take care not to use words in nonstandard meanings, unless, of course, a word meaning that would be nonstandard in the general population happens to be the standard use of the word in the user community. Special dictionaries exist to help distinguish common meanings of words from less common meanings. For example, (Dale and O'Rourke 1981) lists 44,000 English word meanings and provides statistics on how many Americans know each meaning. Even though such statistics are only valid in the country where they were collected, one can normally assume that the avoidance of unusual word meanings will also be a way to improve international understandability of an interface.

To speak the users' language does not always imply limiting the interface vocabulary to a small set of commonly used words. On the contrary, when the user population has its own specialized terminology for its domain, the interface had better use those specialized terms rather than more commonly used, but less precise, everyday language. Even for the general population, specific, distinguishing words are better than bland words.

Speaking the users' language also involves viewing interactions from the users' perspective. For example, a security transactions statement should read, "You have bought 100 shares of XYZ Corp." and not, "We have sold you 100 shares of XYZ Corp." As another example, consider a computer utility, such as a virus guard, that is continuously active, running in the background, but which might periodically need to be deactivated for whatever reason. One approach might be to introduce an "override mode" with a command that could be activated whenever the user needed to perform a task that conflicted with the background utility. Unfortunately, the override would be on when the user wanted the utility to be off, so using this model would conflict with the user-oriented perspective, even though it might in fact be a perfect reflection of the internal workings of the operating system. A better choice would be a reverse model using a dialog box with a checkbox for This design also simplifies the interface since it has no concept of a special override mode.

The system should not force naming conventions or restrictions on objects named by the user. For example, users should be allowed to use as long names as they want, even though the system may not always be able to show very long names without scrolling. If the system for some reason cannot handle names longer than a certain number of characters, it should not just truncate without warning the user's input after that number of characters. Instead, it should offer a constructive error message and allow the user to edit the name to be as meaningful as possible within the limitations imposed by the system.

Given the advice to speak the users' language, an obvious idea is simply to ask users what words and concepts they would like to see in the interface. Unfortunately, the verbal disagreement phenomenon guarantees the failure of that approach: There are so many different words in common use for the same things that the probability is very low that a user will mention the most appropriate name when asked. Furnas et al. (1987) found that the probability that two users would mention the same name was no more than 7-18%, depending on the phenomenon being named. Even if one asked several users and then picked the name mentioned by most of them, one would still only match 15-36% of the users. In other words, the majority of users will be dissatisfied anyway, even if words are chosen by asking the users themselves.

A much better alternative is to let the users vote on the names, based on a shortlist of possible names. This list can be generated by several means, including suggestions from the developers, from usability specialists, and from asking a few users. In one experiment (Bloom 1987-88) names for the features in a mail merge facility were chosen in three different ways:

• Technical terms as suggested by the original developers of the system: variable field, token character, record, delimiter, etc.

• The terms suggested by the most users when they were given a short description of the concepts: part, marker, unit, period, etc.

• The winners when users were given a list of several alternative terms and asked to vote: component, placeholder, information package, separator, etc.

Given that there are so many ways to refer to the same concepts, computers should allow for rich use of synonyms in interpreting command languages and in documentation indexes. It should also be possible for the users to define aliases (user-defined terms that are translated by the system). Not only may an alias be easier to remember for the user who defined it, but it can also serve as a shortcut for complex sequences such as commands with multiple parameters or electronic mail addresses. For some applications, such as the searching of online documentation or database queries, the system itself may build up a list of aliases over time through the use of adaptive indexing (Furnas 1985), where new names for objects are added every time a user tries a query term that is not known by the system, but where the user eventually succeeds in finding the relevant information anyway.

Mappings and Metaphors

Unfortunately, the world is round, and the map is flat, leading to all kinds of geographical distortions and the need to select a mapping projection suitable for the user's task.

To discover such mappings, the first step is to perform a task analysis and build up an understanding of the users and their domain. In addition to talking with users and observing them, it is also possible to use more complex methods to build an understanding of the users' knowledge representation and the way they model their domain. Typically, users are asked to list or group concepts in the domain, and the orderings or groupings are assumed to correspond to the users' model of the domain. Some commonly used techniques include ordered recall (users are allowed to freely associate and mention as many concepts as they can think of, with concepts that are mentioned close together assumed to be associated in the user's mind), card sorting (each concept is written on a card, and the user sorts the cards into piles), and paired similarity ratings (users are given a questionnaire listing all possible pairs of concepts and asked to rate their similarity) (McDonald and Schvaneveldt 1988). The outcome of these tests can either be used directly or be subjected to multidimensional scaling or cluster analysis, using a statistics program. For example, Loshe et al. (1991) used card sorting to elicit the users' mental models of a set of graphics and charts. Subjects who were graphic artists were found to structure the graphics significantly differently than other subjects, indicating the need to structure user interfaces to graphics and charting software differently for these two categories of users.

User interface metaphors (Carroll et al. 1988; Wozny 1989) are a possible way to achieve a mapping between the computer system and some reference system known to the users in the real world. For example, consider the task of installing or updating new software on a personal computer. The traditional user interface to this task is very system-oriented, listing files, features, disks, etc., from which the user has to choose. Alternatively, a mail-order catalog could be used as a metaphor to structure the interface and allow the users to utilize their existing knowledge about how one selects and previews options (Card and Henderson 1987).

Unfortunately, metaphors may mislead users, or users' understanding of the computer may be limited to those aspects that can be inferred from the metaphor (Halasz and Moran 1982). For example, the metaphor "a word processor is like a typewriter" will help users discover features like backspace and scrolling, but may prevent them from looking for a global replace feature.

As another example, the operation "delete file" has often been metaphorized in graphical user interfaces, with icons like a trash can, a paper shredder, and even a black hole used to represent deletion. Even though the black hole cannot be said to be very user-oriented, all these icons represent ways to draw upon the users' non-computer-related experience and knowledge and they thus serve as good metaphors for the concept of file deletion. A problem arises when considering data security. Most current operating systems do not delete the contents of a file from the disk when the file is deleted. Often, the only result of a file deletion is to make the storage space occupied by the file available for use by other files at a later date. This means that as long as no other files have overwritten the ostensibly deleted storage blocks, it will be possible to read the contents of the deleted file. Users with sensitive data on their disks can therefore not rely on file deletion to safeguard their data in cases where others have access to the disk - for example because it is sold or sent in for repair. The paper-shredder icon may give users a false sense of security due to the connotations of physical paper shredders with respect to the destruction of confidential paper documents. In contrast, the trash-can icon at least implicitly suggests that others might look through the discarded documents.

The lesson from these examples is that one should take care when "speaking the users' language" not to inadvertently imply more than one intended. Specifically, discussions of interface metaphors in manuals should be supplemented with explanations of the differences between the real-world reference system and the computer system. Care should be taken to present the metaphor as a simplified model of a more detailed conceptual model of the system (Nielsen 1990c) and not as a direct representation of the system.

Metaphors also present potential problems with respect to internationalization, since not all metaphors are meaningful to all cultures. For example, a Danish interface designer might choose to use the pause signal as a metaphor for delayed system response, drawing upon the common knowledge that radio stations play a special endless tune of the same 13 notes repeated over and over when one show finishes before the scheduled starting time of the next. However, the concept of a pause signal would be quite foreign to users in many other countries, such as the United States, where radio stations fill every available moment with commercials and would never put on a special signal just to fill up time.

Minimize User Memory Load

The computer should therefore display dialogue elements to the users and allow them to choose from items generated by the computer or to edit them. Menus are a typical technology to achieve this goal. It is also much easier for the user to modify information displayed by the computer than to have to generate all of the desired result from scratch. For example, when users want to rename an information object, it is very likely that they will want the new name to be similar to the old one, so the text edit field in which the user is supposed to enter the new name should be prepopulated with the old name, allowing users to make modifications instead of typing everything.

Interfaces based on recognition rely to a great extent on the visibility of the objects of interest to the user. Unfortunately, displaying too many objects and attributes will result in a relative loss of salience for the ones of interest to the user, so care should be taken to match object visibility as much as possible with the user's needs (Gilmore 1991). As usual we find that "less is more."

Whenever users are asked to provide input, the system should describe the required format and, if possible, provide an example of legal and sensible input, such as a default value. For example, a system asking the user to enter a date could do it as follows:

• Enter date (DD-Mmm-YY, e.q., 2-Aug-93):

There is no need for the user to have to remember or guess at the range of legal input and the unit of measurement that will be used to interpret it. Instead, the system can supply that information as part of the dialogue, such as, for example:

• Left margin: 10 points (0-128)

To minimize the users' memory load, the system should be based on a small number of pervasive rules that apply throughout the user interface. If a very large number of rules is needed to determine the behavior of the system, then the user will have to learn and remember all those rules, making them a burden. On the other hand, if the system is not governed by any rules at all, then the user will have to learn every single dialogue element on its own, and it is impossible to predict the behavior of a dialogue element without already knowing (and remembering) how it works.

The use of generic commands (Rosenberg and Moran 1984) is one way to let a few rules govern a complex system. As shown in Figure 3, generic commands make similar things happen in different circumstances, making it sufficient for the user to learn a few commands in order to work with many different types of data. One of the main advantages of generic commands is that they support transfer of learning from one application to the next, since users do not need to relearn those commands they already know (Ziegler et al. 1986).

Figure 3 A generic command: "Paste" can be used to insert a line of C's (text) as well as a striped square (graphics) at the insertion point.

Generic commands need not perform exactly the same function in all circumstances, as long as the user can think of the command as a single unified concept, such as "insert the object from the clipboard" in the case of a paste command. As shown by Figure 3, this generic command may actually insert the clipboard and move some old objects out of the way, when it operates on text, but perform the insert operation without moving anything when it operates on graphics. The designer of a generic command will need to determine what "naturally" feels like the same command to users, even if some details will differ due to the requirements of the different parts of the system.

Consistency

The same information should be presented in the same location on all screens and dialog boxes and it should be formatted in the same way to facilitate recognition. For example, my heating bill contains a comparison between my current heating use and my use in the same month in the previous year, listed as a table with the current year in the left column and the previous year in the right. To facilitate my interpretation of these numbers, a footnote on the bill furthermore contains information about the average temperature in each of the two years. Unfortunately, the footnote mentions the previous year before (that is, to the left of) the current year, thus inverting the relation compared to that used in the table. Consistency considerations would have implied a design of this printout with the same spatial relation between the two periods for both kinds of information. An order where the previous year was mentioned before the current year might be preferred as being consistent with the way timelines work, but unfortunately one can also argue that the reverse order achieves a better match with the user's task of assessing current heat usage. As is often the case in user interface design, one would have to decide which of these two considerations was most important; once this decision had been made, one should follow it consistently and not mix the two layout rules.

Many aspects of consistency become easier to achieve to the extent that one is following a user interface standard in the design, since the standard will then have specified many details of the dialogue, such as, for example, how to indicate a pop-up menu or which typeface to use in a list of font sizes. Unfortunately, standards compliance is not sufficient to ensure consistency, since the standards leave a fair amount of leeway for the designers.

Consistency is not just a question of screen design, but includes considerations of the task and functionality structure of the system (Kellogg 1987, 1989). For example, Eberts and MacMillan (1987) found that subjects were more confused when they switched between using a command-line mainframe and a command-line personal computer than when they switched between the command-line personal computer and a graphical personal computer. From a screen design perspective, the two command-line interfaces were very similar, but the underlying operating systems were in fact very different. And the two personal computer interfaces were built on top of systems with the same basic philosophy and features.

A study of a popular spreadsheet program found 10 consistency problems causing common errors for novice users (Doyle 1990). Seven of these problems were due to inconsistencies between the spreadsheet and the users' task expectations, three were due to inconsistencies between the spreadsheet and other user interfaces, and only two problems were due to inconsistencies within the spreadsheet itself. The spreadsheet's menu navigation method was classified as being inconsistent in all three ways and was therefore counted in all three categories. Of course, other systems may have different distributions of their consistency problems, but it is probably quite representative that the larger scopes of consistency are the most difficult to get right.

Feedback

System feedback should not be expressed in abstract and general terms but should restate and rephrase the user's input to indicate what is being done with it. For example, it is a good idea to give a warning message in case the user is about to perform an irreversible action, such as overwriting a file. Assume that the user is about to copy a file to another disk and that the copy operation would overwrite a file with the same name. The worst feedback (except none, of course) would be to state that a file was about to be overwritten, without giving its name. Better feedback would include the name of the file, and even better feedback would include attributes of the two files, such as file type and modification date, to help the user understand whether the copy operation was just replacing an old copy with a newer copy of the same file or whether the file being overwritten was in fact a completely different file that happened to have the same name.

Different types of feedback may need different degrees of persistence in the interface (Nielsen 1987c). Some feedback is only relevant for the duration of a certain phenomenon, and can thus have low persistence, going away when it is no longer needed. For example a message stating that the printer is out of paper should be removed automatically once the problem has been fixed. Other feedback needs to have medium persistence and stay on the screen until the user explicitly acknowledges it. An example in this category would be a message stating that the user's output had been rerouted to another printer because of some problem with the printer specified by the user. Finally, a few types of feedback may be so important that they require high persistence, remaining a permanent part of the interface. An example might be the indication of remaining free space on a hard disk.

Response Time

• 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

• 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

In cases where the computer cannot provide fairly immediate response, continuous feedback should be provided to the user in form of a percent-done indicator like the one shown in Figure 4 (Myers 1985). As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. Progress indicators have three main advantages: They reassure the user that the system has not crashed but is working on his or her problem; they indicate approximately how long the user can be expected to wait, thus allowing the user to do other activities during long waits; and they finally provide something for the user to look at, thus making the wait less painful. This latter advantage should not be underestimated and is one reason for recommending a graphic progress bar instead of just stating the expected remaining time in numbers.

Figure 4 Percent-done indicator for a hypothetical file-transfer program. The design not only provides feedback expressed in the user's terms (the name of the file) and with respect to the progress of the transfer, it also provides an easy way out in case the user gets tired of waiting or discovers that the wrong file is being transferred.

For operations where it is unknown in advance how much work has to be done, it may not be possible to use a percent-done indicator, but it is still possible to provide running progress feedback in terms of the absolute amount of work done. For example, a system searching an unknown number of remote databases could print the name of each database as it is processed. If this is not possible either, a last resort would be to use a less specific progress indicator in the form of a spinning ball, a busy bee flying over the screen, dots printed on a status line, or any such mechanism that at least indicates that the system is working, even if it does not indicate what it is doing.

For reasonably fast operations, taking between 2 and 10 seconds, a true percent-done indicator may be overkill and, in fact, putting one up would violate the principle of display inertia (avoiding flash changes on the screen so rapidly that the user cannot keep pace or feels stressed). One could still give less conspicuous progress feedback. A common solution is to combine a "busy" cursor with a rapidly changing number in small field in the bottom of the screen to indicate how much has been done.

System Failure

As an example, consider feedback to users of an automated teller machine (ATM). On February 13, 1993, all 1,200 ATMs belonging to a major bank in New York City refused to perform any user transactions for a period of four hours due to a bug in a software upgrade installed at the data center. According to newspaper reports, customers "crisscrossed the city on futile scavenger hunts for an operating cash machine" ("At a bank, automatic frustration machines," New York Times February 14, 1993, p.45.) since they did not know what was going on and hoped that other machines might be working. Since it would be unrealistic to expect a 1,200 node distributed computer system to function perfectly all the time without any software, hardware, or network failures, the user interface at the individual ATMs should be designed to provide information to customers in case of any such downtime. Different messages should be given, depending on whether the error is due to the central system (in which case customers need not waste time finding another machine) or whether the error is local. In order to inform customers correctly, the ATM needs to be able to perform rudimentary diagnostics, and the entire system needs to be built with such diagnostics in mind. Assuming that the system is designed for it, it should be feasible to give users meaningful information about the likely cause and/or location of any system failures.

Clearly Marked Exits

In many cases, exits can be provided in the form of an undo facility that reverts to the previous system state (Abowd and Dix 1992; Yang 1992). Users quickly learn to rely on the existence of undo, so it should be made pervasively available throughout the system as a generic command that undoes any state changes rather than being restricted to only undoing a special category of user actions. Given that undo and escape facilities are generally available, users will feel encouraged to rely on exploratory learning since they can always try out unknown options, trusting in their ability to get out of any trouble without ill effects. A basic principle for user interface design should be to acknowledge that users will make errors no matter what else is done to improve the interface, and one should therefore make it as easy as possible to recover from these errors.

As mentioned above, system response times should be as fast as possible. In cases where the computer cannot finish its processing within the 10-second limit for keeping the user's attention, it should always be possible for the user to interrupt the computer and cancel the operation. In general, interfaces should show a high degree of responsiveness (Duis and Johnson 1990), to the extent that paying attention to the user's new actions should get higher priority than finishing the user's old actions. For example, if a graphics program takes a fair amount of time to repaint the screen, it should allow the user to scroll or to change the zoom level even before the screen has been completely redrawn.

The various exit and undo mechanisms should be made visible in the interface and should not depend on the user's ability to remember some special code or obscure combination of keys. Visibility is of course a general user interface design principle, with the possible exception of some dialogue accelerators, but visibility is especially crucial for exit support since users will need these mechanisms in cases where they are in unfamiliar territory and may be afraid to lose data if they do the wrong thing.

Shortcuts

A good example of a shortcut to make a frequent operation faster is the use of a structure generator in a hypertext authoring system (Jordan et al. 1989). Since hypertext authors may often want to generate large numbers of similar hypertext structures with a given pattern of typed nodes and links (for example, each of the courses in an online course catalog might have nodes for course content, prerequisites, instructor, textbooks, and location), they can work faster if the system allows them to define templates of these structures and to generate sets of nodes and links based on a template in a single operation. Macro and scripting facilities can be used to achieve similar effects in traditional command languages, and similar facilities are also being introduced to graphical user interfaces.

Type-ahead (typing the next input before the computer is ready to accept it) is not really a shortcut as such since it still requires the user to generate a complete sequence of input, but it can speed up the interaction by allowing the user to get ahead of the computer and not have to pay attention to all the steps in the dialogue. Similarly, in telephone-based interfaces and other speech-based interfaces, users should be allowed to interrupt the voice prompts as soon as they know what to say. Graphical user interfaces can support a feature similar to type-ahead, in what might be called click-ahead: Users can click on the spot where the "OK" button will appear to dismiss dialog boxes before they have even appeared, and they can click in partly obscured windows before they have been made active. It is dangerous to allow type-ahead and click-ahead in all circumstances, however. For example, a critical alert message should not go away without having been visible, and the type-ahead buffer should be cleared in case there is an error in the execution of a prior command which would tend to make the rest of the user's input invalid.

Users should be allowed to jump directly to the desired location in large information spaces, such as a file or menu hierarchy. Often, a hypertext-like approach (Nielsen 1990a) can be used with links between information elements that are likely to be used together. In file systems, such links are often called aliases, since they provide a way to name an information object (file) without having to specify the full pathname. Alternatively, popular locations may be given easy-to-remember names that have to be typed in by the user. This approach is popular on many videotex services. Finally, users may be allowed to give their own names to those locations they find especially important. By doing so, users can build up a list of bookmarks that will enable them to return quickly to a small set of locations (Bernstein 1988; Monk 1989). Of course, following the "minimize-user-memory-load" principle, the user should have easy access to a list of the bookmarks defined by that user (Olsen 1992).

Users should be able to reuse their interaction history. A study of a command-line system showed that 35% of all commands were identical to one of the five previous commands and that 74% of the commands had been issued at least once before (Greenberg and Whitten 1988). Thus, a simple menu of the last few things the user had done would make it possible for the user to reissue a large number of commands without having to reenter them. Also, word processors, hypertext systems, and other systems where users navigate large amounts of information should have a backtrack feature or other history mechanisms to allow the user to return directly to prior locations.

Even though command reuse is simpler for command-language interfaces, some direct manipulation interfaces allow users to reissue the last formatting command or repeat the last search command by a simple command-key shortcut. It is also possible to use a kind of comic strip to show previous states of a graphical interface (Kurlander and Feiner 1992) using a principle called a visual cache to allow fast direct access to those states (Nielsen 1990g; Wiecha and Henrion 1987).

As a simple example of the use of the user's interaction history to provide shortcuts, some applications keep track of which files users often open in those applications (Barratt 1991). The applications can then offer users a special menu of the files they are most likely to open next, either because they have been used recently, because they are used a lot in general, or because they are normally used together with other files already opened in a particular session. Statistics on such "working sets" of files that are often used together are slightly harder to get right than statistics on the most recently used files, but they can offer users a convenient shortcut to get at several files in a simpler way than having to find them one at a time in the file system.

System-provided default values constitute a shortcut since it is faster to recognize a default and accept it than having to specify a value or an option. In many cases, users do not even need to see the default value, which can remain hidden on an optional screen that is only accessed in the rare case where it needs to be changed. Defaults also help novice users learn the system since they reduce the number of actions users need to make before using the system, and since the default values give an indication of the kind of values that can legally be specified.

Good Error Messages

Error messages should basically follow four simple rules (Shneiderman 1982):

• They should be phrased in clear language and avoid obscure codes. It should be possible for the user to understand the error message by itself without having to refer to any manuals or code dictionaries. It might be necessary to include internal, system-oriented information or codes to help systems managers track down the problem, but such information should always be given at the end of an otherwise human-readable error message and should be combined with constructive advice, such as "Report this information to your systems manager to get help."

• They should be precise rather than vague or general. For example, instead of saying, "Cannot open this document," the computer should say "Cannot open 'Chapter 5' because the application is not on the disk" (also following the principle about giving feedback by restating the user's input).

• They should constructively help the user solve the problem. For example, the above error message that a document could not be opened could be made more constructive by replacing the words "the application" with the name of the application, indicating to the user what should be done in order to read the document. The message could also offer to try to open the document with some other application that was known to accept data of the given type.

One useful way of generating constructive error messages is by guessing at what the user really meant to say. In the case of textual input, spelling-correction methods have been available for many years (Peterson 1980; Bentley 1985), and these methods can be especially fast and precise when the set of correct user inputs is restricted to a known set of terms such as the names of files and commands (Bickel 1987). Durham et al. (1983) found that even a simple spelling corrector could handle 27% of all user errors in a text-oriented interface, thus confirming the value of this cheap method. The Interlisp programming system even had a feature called DWIM (Do What I Mean - not what I say) (Sandewall 1978; Teitelman 1972), where the computer automatically performed the action it assumed that the user wanted. DWIM is somewhat dangerous, though, unless the computer is absolutely sure.

• Finally, error messages should be polite and should not intimidate the user or put the blame explicitly on the user. Users feel bad enough as it is when they make errors. There is no need for the computer to make the situation even worse by accusing error messages like the classic "ILLEGAL USER ACTION, JOB ABORTED" (in upper case, at that - screaming at the user). Error messages should definitely avoid abusive terms like fatal, illegal, and so forth. Often, error messages can be worded such as to suggest that the problem is really the computer's fault - as indeed it is since the interface in principle ought to have been designed to have made the error impossible. For example, the LOGO programming language will give the message "I don't know how to foo" if the user calls the undefined procedure foo, thus seeming to take a little of the blame (Nicol 1990).

Andre Bisseret (1983) from the French INRIA research center tells a story about how he tried to define a user ID, giving rise to the following dialogue:
Computer: Type user name
Bisseret: Bisseret
Computer: Error, type user name

Monsieur Bisseret was not pleased to find that the computer considered his name illegal. Unfortunately, the computer only accepted user IDs up to seven characters in length, so it could at least have given a constructive error message by explicitly saying so. But actually, a better redesign would have allowed user names of arbitrary length since doing so would follow the principle of speaking the user's language. There is no need to force users to remember strange contractions of their own and other people's names. Such a redesign would avoid any need to have this error message in the first place since the potential error situation would be designed away. Doing so is also a major dialogue principle.

Multiple-Level Messages

In an integrated user-assistance facility based on hypertext, it would also be possible for the user to link from an error message to the location in the help system that gives further assistance on the problem. If the user's difficulty was not the error situation in general but a single incomprehensible word in the message, it would be possible to link from that word to the location in the online manual where it was defined. And if the user wanted further assistance than could be provided by the help system or the manual, it would be possible to link further, to the appropriate location in the tutorial component, to get a computer-aided instruction lesson.

As mentioned above, error messages should normally not reflect mysterious internal states of the computer that are completely incomprehensible to the regular users even though the information may help specialized support staff locate and fix the problem. The notion of multiple-level messages can provide access to such detailed information for those wizard-level users who want it while shielding lessknowledgeable users from being confused and intimidated. Ideally, it should be possible to dig steadily deeper into a set of messages from lower and lower levels of the system (Efe 1987) until the error has been identified.

Prevent Errors

For example, every time the user is asked to spell out something, there is a risk of spelling errors, so selecting a filename from a menu rather than typing it in is a simple way to redesign a system to eliminate an entire category of errors.

User errors can be identified as candidates for elimination through redesign either because of their frequency or because of their serious consequences. These two kinds of information can be gathered either through user testing or by logging errors as they occur during field use of the system.

Errors with especially serious consequences can also be reduced in frequency by asking users to reconfirm that they "really, really mean this" before going ahead with the dangerous actions. One should not use confirmation dialogues so often, though, that the user's answer becomes automatic. If a long sequence of actions is performed so frequently that it is experienced as a unit, the users risk making a "capture error" (Norman 1983) if they ever need to deviate from the sequence: Because they are so used to going ahead in a certain way, they may continue and issue the fatal click on the OK button before they have even read the warning message.

Avoid Modes

Unfortunately, modes are almost impossible to avoid totally in an interface of some complexity. For example, most word processors have a word-wrap feature that causes text to move to the next line to prevent overflowing into the margin. In fact, this feature introduces modes into the interface, since the same action (typing) may or may not cause a new-line action to occur, depending on whether an "end-of-line" mode is true. Normally, this mode does not bother users who do not mind whether their writing get split over multiple lines. When users do mind, such as when constructing tables, this mode does cause problems, however (Monk 1986).

If modes cannot be avoided totally, one can at least prevent many mode errors by explicitly recognizing the modes in the interface design. By showing states clearly and distinctly to the user, a designer can follow the principle of providing feedback, and thus make it less likely that the user will mistake the current mode. In one experiment, adding different sound effects to each of the modes in a computer game decreased the users' mode errors by 70% (Monk 1986). Even if sound effects are not appropriate, other means can be used to provide mode feedback such as different colors of windows. In my own case, I often connect from my personal computer to two different mainframes that have identical operating systems and look-and-feel. After several cases of getting confused about which system I was currently dealing with, I changed the definition of the windows used for the terminal sessions to use significantly different typefaces, thus providing me with constant low-key feedback.

In addition to having clear status indicators showing the current mode, the interface should also exhibit clear differences between user actions in different modes to minimize the risk of confusing individual interface elements. Similarly, system feedback should be sufficiently varied to provide additional differentiation between modes. Mode confusion can also be prevented by the use of so-called spring-oaded modes where the users are only in the mode as long as they actively hold down a button or perform some other action that will automatically take them out of the mode as soon as they let go (Sellen et al. 1990).

Even without the added usability problem of modes, one should in general avoid having too-similar commands. In one case, a user had trouble using a certain system and asked for technical support over the telephone. The support person told the user exactly what commands to type, but the user still had problems even after following the instructions to the letter. The support person was unable to diagnose the problem over the phone and finally went to the user's office to make sure that the instructions were actually being carried out. The problem turned out to be that the system required the commands to be typed in lower case and the user had typed them in upper case. This difficulty is known as a "description error," (Norman 1983) since the descriptions of the two situations are almost identical and therefore likely to be confused. In this system, input in the wrong case was simply rejected, but other interfaces may actually act differently on input depending on its case. For example, case-sensitive search is often an option in text editors. Because users can be expected to make description errors very frequently, it is normally preferable to make case-independent search the default and only provide case-sensitive search as an extra feature that has to be explicitly activated by the user.

Help and Documentation

The fundamental truth about documentation is that most users simply do not read manuals (Rettig 1991). Users prefer spending their time on activities that make them feel productive (Carroll and Rosson 1987), so they tend to jump the gun and start using the system without having read all the instructions. If you doubt this common observation and think that your users do read the documentation, try this simple experiment: visit a few users and place a $10 bill somewhere in their manuals. On your next visit, check how many of the bills are still there! (Of course, you can only use this technique once.)

A corollary to this phenomenon is that if users do want to read the manual, then they are probably in some kind of panic and will need immediate help. This observation indicates the need for good, task-oriented search and lookup tools for manuals and online documentation. Since many users rarely use the manual before they absolutely have to, they may not have the manual immediately available (it may have been lost or borrowed by another user), which is one reason for the trend toward supplementing printed manuals with online help and online documentation. Also, online information has the potential for getting users the precise information they need faster than a paper book through features like hypertext (Nielsen 1990a) and good search facilities. As an example, users of the SuperBook® (SuperBook is a registered trademark of Bellcore) online information browser found information in an online manual in 4.3 minutes compared to 5.6 minutes for users of a printed version of the same manual (Egan et al. 1989). This result was only achieved after usability testing and iterative design of the online interface. Users of the initial design performed the same test tasks in 7.6 minutes, indicating the value of applying usability engineering principles to online documentation as well as to the main system.

The main principle to remember about online help and documentation is that these facilities add an extra set of features to a system, thus complicating the interface just by virtue of existing. Even though it is tempting to design extremely advanced and feature-rich help and documentation systems, the need for an extra "help on how to get help" is an obvious symptom of overblown help design. Many users do not progress beyond the first one or two help screens, and they mostly scan the screens for potentially useful information rather than reading long paragraphs of text (Farrand and Wolfe 1992).

In one empirical study of use of online help (Senay and Stabler 1987), 52,576 help sessions on a mainframe system were logged. 23% of all help requests turned out to be erroneous, meaning that the user did not get any help whatsoever, confirming the observation that help is a system in its own right and can present usability problems to the users. Even in the cases where they did succeed in getting some help information, users only rated it as being useful in 35% of the cases. This study confirms the saying, "help doesn't" (or at least, it does not always help, so the system had better be usable even without online help).

Online help has the advantage over documentation that it can be context-sensitive. For example, in a graphical user interface, the user should be able to point to elements in a dialog box to have them explained (Sellen and Nicol 1990). Also, error messages can be linked to online help with further explanation of the error and possible solutions. In any case, one should remember that the user's problem often is related to wanting to do something else than what is offered by the current system state, so it should also be possible for the user to ask task-oriented questions.

Of course, one important aspect of help and documentation, whether online or hardcopy, is the quality of the writing, especially including the structuring of the information and the readability of the text (Klare 1984). In fact, a major in-depth study of online help concluded that "the quality of help texts is far more important than the mechanisms by which those texts are accessed" (Borenstein 1985). Even so, teaching technical writing is beyond the scope of this book, so this section concentrates on the access mechanisms and the structuring of the information. See, for example, (Horton 1990) for further coverage of technical writing, and see (Mirel 1991) for a survey of research on the usability of printed documentation. See (Borenstein 1985; Duffy et al. 1992; Houghton 1984; Kearsley 1988; Lee 1992) for surveys of online help and (Walker 1987) for more information on online documentation. Perhaps most important of all, the information contained in the text should be correct and reflect the version of the system actually being used by the users.

A second corollary to the finding that users normally do not read the manual is that when they do want to read it, they often will not be able to find it. This problem can be overcome by using online documentation, since it normally stays on the computer once it has been installed. Of course, users have been known to remove documentation and help files when they clean up their disks, so even online documentation does not solve the problem completely.

In a field study of how people really use manuals (Comstock and Clemens 1987), the manuals were found to be stored in many strange locations. Some were nicely stored on bookshelves, though they were not organized by subject matter but rather according to their size and the color of the spines - indicating that it would be a good idea to use these visible features of manuals in a manner consistent with the content of the books. Other manuals were in desk/file drawers, in boxes, in briefcases, on the floor, and on top of computers and terminals. Users typically carried the manuals around, used them standing up, and used several manuals at a time.

A Model of Documentation Use

1. Searching: Locate information relevant to a specific need.
2. Understanding the information.
3. Applying: Carry out a procedure as described in the documentation.

To help the user understand the information once it has been found, not only should it be written without undue use of jargon, but it should also be written in a way that corresponds to the tasks users want to do and the sequence in which they should carry out the tasks. If a sequence of steps is given, the steps should be numbered. Also, it is often good to relate the specific information given in the instructions to a conceptual model of the system, for example through the use of a diagram. ( Illustrations in manuals are very popular with users who in one study rated them the second most important aspect of ease of use (after having well-organized material) (Angiolillo and Roberts 1991). Thus, even disregarding whatever increased understanding users may derive from them, illustrations serve a purpose by making the documentation more approachable and encouraging the users to read it (or at least to browse it).) Since users are likely to have jumped directly into the document without having read the previous sections, each section should be as self-contained as possible. The documentation should also include a variety of examples since it is often easier for users to understand examples than to understand abstract descriptions (LeFevre and Dixon 1986). Users are often able to modify examples to suit their own needs without having to read much more.

After the user has found and understood the information, it comes time to apply it to the system. It is always better for the user to be able to refer to the instructions while carrying them out than to have to remember them, so it should be possible to keep any online help system visible in a separate window while the user returns to the main application. It might even be possible to let the user copy examples directly from the help system to have them executed. To make it simpler for the user to carry out the instructions, they should be stated as much as possible as step-by-step procedures, which, of course, should be given in the sequence in which they should be carried out. Finally, it should be possible for the users to check that they have understood the instructions and carried them out correctly. To a large extent such confirmation is hopefully available directly from whatever feedback the system provides in any case, but the documentation should also mention how the user might check whether the operation has been a success or a failure.

Because of the many uses to which users put documentation, one might need as many as three different levels of documentation:

• Short reference cards and/or job aids (Reitman 1988) for the expert user who just wants to check a fact, and for the novice user who wants to get an overview of the system's capabilities. A similar function may be served by a keyboard template (Nolan 1991) for interfaces that are heavily based on function keys.
• Tutorial and/or introductory manuals for learners.
• Traditional reference manuals for expert users.

The Minimal Manual The minimalist philosophy of documentation (Carroll et al. 1987-88) is a kind of reaction against the profusion of documentation users are sometimes given. As an alternative, one can provide a minimal manual that only gives whatever information is absolutely necessary in order for the users to get started using the system with common tasks.

Figure 5 shows an example of a minimalist guided exploration card to help users get started quickly. Even though a minimal manual admittedly cannot contain all the information users might possibly need, experience has shown that users do not read the large manuals anyway, whereas they do benefit from minimal manuals (Carroll 1990a). A minimal manual should focus on real tasks since users want to get started doing useful work immediately after they start using a system. Also, it should help the user recognize error states and help them recover from the most common errors (the check mark and ambulance in Figure 5).

Figure 5 A hypothetical guided exploration card for spreadsheet, similar to the cards developed by Carroll et. al. (1985).