Sixty Guidelines From 1986 Revisited

by Jakob Nielsen on January 17, 2005

Sidebar to Jakob Nielsen 's column Durability of Usability Guidelines .

Guidelines for Designing User Interface Software by Sidney L. Smith and Jane N. Mosier was published in 1986 by the MITRE Corporation and funded by the U.S. Air Force's Electronic Systems Division. The report contained 944 usability guidelines.

To assess how well old usability guidelines hold up over time , I reviewed a subset of these guidelines, taking a stratified sample of ten guidelines from each of the report's six main sections. To select the samples, I flipped the report open to the middle of each section and selected the first ten guidelines starting on the upper left page.

Following here are reprints of the sixty guidelines I reviewed. In the book, most guidelines were supplemented with examples, comments, and literature references. In the interest of brevity, I repeat little of that information here.

Also, I don't comment on the guidelines that I still view as correct. Obviously, even if they are correct , old guidelines are less important if they relate to rarely used design elements. Still, if you're using such an element, you should heed the corresponding guideline unless it's followed by an annotation declaring it obsolete.

For a broader set of current guidelines, please see my two-day tutorial on application usability .

Section 1: Data Entry

This section contained guidelines for text entry, online forms, data validation, and other issues related to getting information into the computer. The middle of this section dealt with how to relate labels with input fields. This topic is still important, especially for Web-based applications, which often rely on primitive forms that are only slightly better than mainframe interactions from the 1970s.

1.4.12 Marking Required and Optional Data Fields

In designing form displays, distinguish clearly and consistently between required and optional entry fields.

1.4.13 Field Markers Not Entered with Data

When item length is variable, so that a data entry does not completely replace the markers in a field, ignore any remaining field markers in computer processing.

Jakob's analysis in 2005:
Modern systems don't use field markers in input fields, so this guideline has become irrelevant.

1.4.14 Automatic Justification of Variable-Length Entries

When item length is variable, provide automatic justification in computer processing; a user should not have to justify an entry either right or left.

Assuming field delineation by underscore, the following entries should all be considered equivalent

     | Address: 40 Dalton Road_______ |
     | Address: _______40 Dalton Road |
     | Address: ___40 Dalton Road____ |

Jakob's analysis in 2005:
In most modern systems, users can't justify their input field entries because designers typically justify each field in advance. Thus, this guideline has become irrelevant.

1.4.15 Explicit Tabbing to Data Fields

Require users to take explicit keying ("tabbing") action to move from one data entry field to the next; the computer should not provide such tabbing automatically.

Automatic tabbing may cause cascading of errors, if a skilled typist keys a series of items without looking at the display and has accidentally overrun one of the earlier data fields. An acceptable solution here is to design each field to end with an extra (blank) character space; software should be designed to prevent keying into a blank space, and an auditory signal should be provided to alert the user when that is attempted. This will permit consistent use of tab keying by the user to move accurately from one field to the next, even for touch typists.

Jakob's analysis in 2005:
This is a common error on websites that insist on dividing telephone numbers, social security numbers, and the like into multiple, tiny boxes. As we've known since 1986, data entry is more error-prone when the computer automatically moves users between these small boxes. In any case, it's better to designate a single input field for, say, a telephone number, and then accept multiple variants of user-preferred formatting, such as parentheses around the area code. (Flexible input fields are especially important for senior citizens .)

1.4.16 Distinctive Label Format

Make labels for data fields distinctive, so that they will not be readily confused with data entries, labeled control options, guidance messages, or other displayed material.

Labels might be displayed in capital letters always followed by a colon. Or labels might be displayed in dim characters, with data entries brighter.

Jakob's analysis in 2005:
Users must still be able to distinguish between labels and data entry fields, but we no longer need to advise designers to make the labels distinct as the system does this automatically.

1.4.17 Consistent Label Format

When data fields are distributed across a display, adopt a consistent format for relating labels to delineated entry areas.

The label might always be to the left of the field; or the label might always be immediately above and left-justified with the beginning of the field.

1.4.18 Label Punctuation as Entry Cue

The label for each entry field should end with a special symbol, signifying that an entry may be made.

A colon is recommended for this purpose, as
     | NAME: __ __ __ __ __ __ __ __ __ __ __ |

Jakob's analysis in 2005:
This guideline continues to be good advice in most cases, especially for online forms, but there are exceptions. On websites, for example, you can pair a search box with the word "search" and avoid the colon, making the word into a combined label and action button. (This is guideline #49 for homepage usability .)

1.4.19 Informative Labels

In labeling data fields, employ descriptive wording, or else standard, predefined terms, codes and/or abbreviations; avoid arbitrary codes.

1.4.20 Data Format Cueing in Labels

Include in a field label additional cueing of data format when that seems helpful.

     | DATE (MM/DD/YY): __ __/__ __/__ __ |

1.4.21 Labeling Units of Measurement

When a measurement unit is consistently associated with a particular data field, include that unit as part of the field label rather than requiring a user to enter it.


     | SPEED (MPH): __ __ __ |

Section 2: Data Display

Most of this section dealt with text output, data forms, and tables, but the middle of the section focused on graphical display of data. I therefore selected those guidelines for my analysis. Repeating Display of Cyclic Data

Where curves represent cyclic data, consider extending the graph to repeat uncompleted portions of the displayed cycle.

The intent here is to allow users to scan any critical portion of the displayed cycle without having to return visually to the beginning of the plot. How much extension is desirable will depend on the particular application. In short, data that are used together should be displayed together. Direct Display of Differences

Where users must evaluate the difference between two sets of data, plot that difference directly as a curve in its own right, rather than requiring users to compare visually the curves that represent the original data sets.

If two curves represent income and expenses, then it might help to plot the difference between those curves to show profit (or loss). Surface Charts

When curves represent all of the portions of a whole, consider using a surface chart in which curves are stacked above one another to display aggregated amounts, and the areas defined below the curves are textured or shaded.

Jakob's analysis in 2005:
This type of chart is called a "Stacked Area Chart" in Microsoft Excel. Ordering Data in Surface Charts

Order the data categories in a surface chart so that the least variable curves are displayed at the bottom and the most variable at the top.

In a surface chart, any irregularity in the bottom curve will "propagate" throughout the curves above it, which will make it difficult for a user to distinguish whether apparent irregularity in upper curves is real or merely a consequence of this method of presentation.

Sometimes there are independent logical grounds for the ordering of data categories. If a surface chart constructed on a logical basis produces confusing irregularity of curves, then it might be better to display the data in some other graphic format. Labeling Surface Charts

Where space permits, label the different areas of surface charts directly within the textured or shaded bands. Cumulative Curves

Consider cumulative curves to show the current total at any point; but do not rely on cumulative curves to show effectively the amount of change at any point. Bar Graphs

Consider bar graphs, where numeric quantities are represented by the linear extent of parallel bars, for comparing a single measure across a set of several entities or for a variable sampled at discrete intervals. Histograms (Step Charts)

Consider histograms (step charts), bar graphs without spaces between the bars, when there are a great many entities or intervals to be plotted.

Histograms are often used to plot frequency data, i.e., the frequency of observations for each of many intervals scaled along the X-axis. For such applications, a histogram will avoid the "picket fence" appearance which might result from spaces between bars. Consistent Orientation of Bars

In a related series of bar graphs, adopt a consistent orientation for bars displaying similar information, either vertical or horizontal. Bar Spacing

Space adjacent bars closely enough that a direct visual comparison can be made without eye movement.

If there are a great many bars to be displayed, then spacing will produce an alternating pattern of bright and dark bands that could prove visually disturbing, particularly for viewers with epileptic vulnerability. In such a case it might be better to display a histogram with no spacing between bars.

Section 3: Sequence Control

This somewhat quaint title referred to the user's control of the workflow--that is, how users made actions happen in the system, as opposed to just entering or viewing data. Much of this section discussed the design of menu structures, command languages, and error handling, all of which continue to be relevant. As always, I picked the middle of the section for my analysis. The corresponding guidelines discussed function keys, which were one of the main ways of controlling mainframe dialogues.

On today's systems, actual function keys (F1, F2, etc.) are rarely used, but command-key shortcuts (Ctrl-X, Ctrl-C, Ctrl-V, etc.) are common, and many of the guidelines will be the same. Consistent Logic for Double Keying

If double (control/shift) keying is used, the logical relation between shifted and unshifted functions should be consistent from one key to another.

One consistent logic might be that shifted and unshifted functions are opposite, so that if a particular key moves the cursor forward then that key when shifted would move the cursor backward.

Another possible logic might be that shifted and unshifted functions are related by degree, so that if a particular key deletes a single displayed character then that key when shifted would delete a word. Single Activation of Function Keys

Ensure that any key will perform its labeled function with a single activation, and will not change its function with repeated activation.

Jakob's analysis in 2005:
If we consider mouse buttons to be a special type of function key, then this guideline no longer holds: double clicking is so firmly embedded in the interaction vocabulary that it would be unreasonable to prohibit it. Of course, double clicking causes notorious usability problems and many users never truly understand the difference between a single and a double click. We might have been better off if Apple had heeded this guideline, used a two-button mouse, and never introduced double clicking. For now, though, double clicks are here to stay. Feedback for Function Key Activation

When function key activation does not result in any immediately observable natural response, provide users with some other form of computer acknowledgment. Indicating Active Function Keys

If some function keys are active and some are not, indicate the current subset of active keys in some noticeable way, perhaps by brighter illumination. Disabling Unneeded Function Keys

When function keys are not needed for any current transaction, temporarily disable those keys under computer control; do not require users to apply mechanical overlays for this purpose. Single Key for Continuous Functions

When a function is continuously available, assign that function to a single key.

Jakob's analysis in 2005:
This guideline is not valid for modern systems because they use a different mechanism for making functions continuously available: typically, a persistent menu or navigation bar. Because function keys are less prominent in modern user interfaces, it would be unreasonable to require a function key for all continuously available functions. Also, much modern software has so many continuously available functions that it would require more function keys than keyboards provide. Consistent Assignment of Function Keys

If a function is assigned to a particular key in one transaction, assign that function to the same key in other transactions. Consistent Functions in Different Operational Modes

When a function key performs different functions in different operational modes, assign equivalent or similar functions to the same key. Easy Return to Base-Level Functions

If the functions assigned to a set of keys change as a result of user selection, give the user an easy means to return to the initial, base-level functions.

In cockpit design, where multifunction keys may be used for various purposes such as navigation or weapons control, the pilot should be able to take a single action to restore those keys quickly to their basic flight control functions.

For some applications, it may be desirable to automate the return to base-level assignment of multifunction keys, to occur immediately on completion of a transaction and/or by time-out following a period of user inaction. The optimum period for any automatic time-out would have to be determined empirically for each application. Distinctive Location

Group function keys in distinctive locations on the keyboard to facilitate their learning and use; place frequently used function keys in the most convenient locations.

Section 4: User Guidance

This section went far beyond help systems, discussing such topics as system feedback and status information.

4.2.3 Feedback for Control Entries

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.

4.2.4 Indicating Completion of Processing

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.

4.2.5 Feedback for Print Requests

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.

4.2.6 Display Identification

Provide a unique identification for each display in a consistent location at the top of the display frame.

Jakob's analysis in 2005:
This guideline is no longer true the way it is stated. For websites, you might say that the URL serves as a "unique identifier," but the deeper point is that users no longer relate to specific screens the way they did in the mainframe age. Instead, the current guideline is to provide a title or headline that tells users at a glance what the current page is about.

4.2.7 Identifying Multipage Displays

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.

4.2.8 Indicating Operational Mode

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.

Jakob's analysis in 2005:
Modes are frowned upon by modern interaction design. However, if you do use modes, you should certainly indicate that fact.

4.2.9 Indicating Option Selection

When previously selected options are still operative, display those options either automatically or on user request.

Jakob's analysis in 2005:
This sounds good, but given a modern system's myriad options, it's impractical to continuously display all previously selected ones. It's certainly still a guideline to let users display their chosen options if desired. It's also advisable to list all the chosen options on a summary page in e-commerce checkout processes just before the final purchase action.

4.2.10 Indicating Item Selection

When a user selects a displayed item in order to perform some operation on it, highlight that item on the display.

Jakob's analysis in 2005:
This is still correct advice, but the system typically handles it automatically, so we usually don't need a guideline for indicating item selection. Even so, we did have to include guidelines on highlighting and other selection feedback in our Flash usability report because many users were tripped up by poor feedback in current Flash designs.

4.2.11 Feedback for User Interrupt

Following user interrupt of data processing, display an advisory message assuring the user that the system has returned to its previous status.

4.3.1 Informative Error Messages

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.

Section 5: Data Transmission

From today's vantage point, this section reads like a discussion of email user interfaces, but many of the guidelines are also relevant for other systems that allow users to notify each other, such as wish lists, photo sharing applications, and so on.

5.2.10 Informal Distribution Lists

Allow individuals or groups to create their own informal distribution lists for local use.

5.2.11 Lists Within Lists

Within a distribution list, allow users to include other distribution lists as well as individual names.

5.2.12 Modifying Distribution Lists

Provide computer aids to permit users to modify distribution lists once created.

5.2.13 Automatic Expansion of Partial Addresses

Allow users to enter a partial name when specifying addresses, if that will identify a particular destination uniquely.

5.2.14 Automatic Address Checking

Provide computer checks for address accuracy (i.e., recognized content and format) and require users to correct mistakes before initiating message transmission.

5.2.15 Addressing Replies to Messages Received

If a user wishes to reply to a received message, provide the appropriate address(es) automatically, along with a reference to that received message.

5.2.16 Editing Address Headers

Allow users to edit the address fields in the header of a message being prepared for transmission.

Jakob's analysis in 2005:
Even though this is still true, it's hard to imaging a designer who would produce an uneditable address field today. I'm sure they exist, but they must be rare. That said, it's good to be reminded from time to time about how inflexible and awkward computer systems used to be; computers are still bad, but not as bad as they were twenty years ago.

5.2.17 Single Occurrence of Address

Ensure that the address of any particular recipient will occur only once in a message.

5.2.18 Serial Distribution

In applications requiring coordinated review of messages by several recipients, allow the sender to specify a serial distribution so that a message will be passed from one recipient to the next.

5.2.19 Redistributing Received Messages

Allow users to redistribute received messages by enlarging their address headers.

Jakob's analysis in 2005:
The underlying intention behind this guideline is still correct: users should be able to redistribute messages. However, the specific advice for how to accomplish this is no longer relevant. As this example emphasizes, it's important to explain the rationale behind guidelines so that future readers can adapt them to changing circumstances when the basic point holds, but smaller details change.

Section 6: Data Protection

This section shows the guidelines' military provenance, being very concerned with keeping secrets. But even civilian systems need to protect their users' data, and so these guidelines remain highly relevant.

6.1.1 Easy LOG-ON

Design the LOG-ON process and procedures for user identification to be as simple as possible consistent with protecting data from unauthorized use.

6.1.2 Prompting LOG-ON

Design the LOG-ON process to provide prompts for all user entries, including passwords and/or whatever other data are required to confirm user identity and to authorize appropriate data access/change privileges.

6.1.3 User Choice of Passwords

When passwords are required, allow users to choose their own passwords.

6.1.4 Changing Passwords

Allow users to change their passwords whenever they choose.

6.1.5 Private Entry of Passwords

When a password must be entered by a user, ensure that password entry can be private; password entries should not be displayed.

6.1.6 Limiting Unsuccessful LOG-ON Attempts

Impose a maximum limit on the number and rate of unsuccessful LOG-ON attempts that will provide a margin for user error while protecting the system from persistent attempts at illegitimate access.

6.1.7 Auxiliary Tests to Authenticate User Identity

When system security requires more stringent user identification than is provided by password entry, devise auxiliary tests that can authenticate user identity without imposing impractical demands on users' memory.

6.1.8 Continuous Recognition of User Identity

Once a user's identity has been authenticated, ensure that whatever data access/change privileges are authorized for that user will continue throughout a work session.

6.2.1 Single Authorization for Data Access

Establish user authorization for data access at initial LOG-ON; do not require further authentication when a user requests display of particular data.

6.2.2 Displayed Security Classification

When displayed data are classified for security purposes, include a prominent indication of security classification in each display.

Share this article: Twitter | LinkedIn | Google+ | Email