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.
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.
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____ |
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.
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.
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: __ __ __ __ __ __ __ __ __ __ __ |
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.
126.96.36.199 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.
188.8.131.52 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).
184.108.40.206 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.
220.127.116.11 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.
18.104.22.168 Labeling Surface Charts
Where space permits, label the different areas of surface charts directly within the textured or shaded bands.
22.214.171.124 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.
126.96.36.199 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.
188.8.131.52 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.
184.108.40.206 Consistent Orientation of Bars
In a related series of bar graphs, adopt a consistent orientation for bars displaying similar information, either vertical or horizontal.
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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.
188.8.131.52 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.
184.108.40.206 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.
220.127.116.11 Single Key for Continuous Functions
When a function is continuously available, assign that function to a single key.
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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.
188.8.131.52 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.
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.
4.2.9 Indicating Option Selection
When previously selected options are still operative, display those options either automatically or on user request.
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.
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.
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.
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.