ESD-TR-86-278
August 1986
Sidney L. Smith and Jane N. Mosier
The MITRE Corporation, Bedford, Massachusetts, USA
Prepared for Deputy Commander for Development Plans and Support Systems, Electronic Systems Division, AFSC, United States Air Force, Hanscom Air Force Base, Massachusetts. Approved for public release; distribution unlimited.
In the numbered sections of this report, guidelines are organized within six functional areas of user-system interaction:
•Data Entry
•Data Display
•Sequence Control
•User Guidance
•Data Transmission
•Data Protection
Each section of guidelines covers a different functional area of user-system interaction, although there is necessarily some overlap in topical coverage from one section to another. Within each section, guidelines are grouped by specific functions. Each function has its own numeric designator, as listed in the table of contents for this report
.In adopting this functional organization, we have established a broad conceptual structure for dealing with the range of topics that must be considered in user interface design. Such a conceptual structure is urgently needed to help clarify discourse in this field.
Each section of the guidelines begins with an introductory discussion of design issues relating to the general functional area. That discussion provides some perspective for the guidelines that follow. The discussion concludes with brief definitions of the various user interface functions covered in that section of the guidelines, along with an internal table of contents for that section, which may help to lead a reader directly to functions of immediate interest.
Function definitions are repeated in boxed format to begin the listing of guidelines under each function. Those definitions should aid reader understanding of the material, and the boxed format will provide a notable visual indicator that a new series of guidelines has begun.
The guidelines themselves are numbered sequentially under each function, in order to permit convenient referencing. Under any function there will usually be guidelines pertaining to various subordinate topics. Each guideline has been given a short title to indicate its particular subject matter. Sometimes one guideline may introduce a new topic and then be followed by several closely related guidelines.
Each of those related guidelines has been marked with an plus sign next to its title.
Following its number and title, each guideline is stated as a single sentence. Guidelines are worded as simply as possible, usually in general terms to permit broad application, but sometimes with contingent phrasing intended to define a more limited scope of application.
In many instances, a stated guideline will be illustrated by one or more examples. When an example includes some sort of imagined computer output, such as an error message, prompt, menu, etc., that output has been marked with enclosing vertical strokes: | sample computer output |
There is no question that specific examples can help clarify a generally-worded guideline. Sometimes a reader will say, "I didn't really understand the guideline until I saw the example." But there is a potential hazard in examples. Because any example must be narrowly specific, a reader who relies on that example may interpret the guideline as having a narrower meaning than was intended. It is important to emphasize that examples are presented here only to illustrate the guidelines, and are not intended to limit the interpretation of guidelines.
Where the validity of a guideline is contingent upon special circumstances, examples may be followed by noted exceptions. Those exceptions are intended to limit the interpretation of a guideline.
Where further clarification of a guideline seems needed, examples and noted exceptions are followed by supplementary comments. Those comments may explain the reasoning behind a guideline, or suggest possible ways to interpret a guideline, or perhaps note relations between one guideline and another.
Where a guideline has been derived from or is related in some way to other published reports, a reference note may be added citing author(s) and date. Complete citations for those references are listed following Section 6 of the guidelines. Where a guideline corresponds with other published design standards or guidelines, which is often the case, reference citations are given by letter codes. Those codes are explained in the reference list.
Where a guideline is specifically related to guidelines in other sections, appropriate cross references are given. Those cross references permit an interested reader to explore how a particular topic is dealt with in different sections of the guidelines.
Toward the back of this report, following the guidelines is the reference list. Following the reference list is a glossary. The glossary defines word usage in the guidelines, for those words that are used here differently or more narrowly than in the general literature on user interface design. There is no question that we need more consistent terminology in this field.
Following the glossary is a list of the titles for all 944 guidelines, which may help a reader who is trying to find guidelines that pertain to a particular topic.
Following the list of guideline titles, and concluding this report is a topical index of the guidelines material. That index is intended to help readers find guidelines on a particular subject, independently of the functional organization that has been imposed on the guidelines material.
These notes on organization and format should serve to allow a student of the subject to skim the guidelines material and find information on different topics. For those readers who seek to apply the guidelines in software design, some further comments are needed.
Not all of the guidelines proposed here can be applied in designing any particular system. For any particular system application, some of the guidelines will be relevant and some will not. In a recent survey of guidelines application (Mosier and Smith, 1986), respondents indicated that they actually applied only 40 percent of the guidelines published in a previous report.
There is another problem to consider. Design guidelines such as those proposed here must be generally worded so that they might apply to many different system applications. Thus generally-worded guidelines must be translated into specific design rules before they can actually be applied.
The process of selecting relevant guidelines for application and translating them into specific design rules is referred to here as "tailoring". Who will do this guidelines tailoring? It should be the joint responsibility of system analysts and human factors specialists assessing design requirements, of software designers assessing feasibility, and of their managers. It may also be helpful to include representatives of the intended system users in this process, to ensure that proposed design features will meet operational requirements. To simplify discussion, we shall call all of these persons "designers".
As a first step in guidelines tailoring, a designer must review this report in order to identify those guidelines that are relevant. For example, if an application will require menus, then the 36 guidelines in Section 3.1.3 dealing with Menu Selection are potentially relevant. For a large information system, the list of relevant guidelines may be quite large.
Once all relevant guidelines have been identified, a designer must review them and decide which ones actually to apply. There are two reasons why a designer might not wish to apply all relevant guidelines. First, for any given application some guidelines may conflict, and the designer must therefore choose which are more important. Second, budgetary and time restrictions may force the designer to apply only the most important guidelines -- those that promise to have the greatest effect on system usability.
As noted above, because guidelines are intended for use on a variety of systems they are worded in general terms. Before a guideline can actually be applied it must be translated into specific design rules. For instance, a guideline which states that displays should be consistently formatted might be translated into design rules that specify where various display features should appear, such as the display title, prompts and other user guidance, error messages, command entries, etc.
Any guideline can have different possible translations. A guideline which states that each display should be uniquely identified could be translated into a design rule that display titles will be bolded and centered in the top line of the display. Or it could be translated into a design rule that display titles will be capitalized in the upper left corner of the display.
What would happen if guidelines were not translated into design rules, but instead were given directly to interface designers? If designers do not decide as a group what design rules will be used, then each designer will decide separately in the course of applying guidelines. The result will surely be an inconsistent design.
After design rules have been specified for each selected guideline, those rules should be documented for reference by software designers and others involved in system development. Documentation of agreed rules, subject to periodic review and revision as necessary, will help coordinate the design process. Documented rules can then be applied consistently for a given application. With appropriate modifications, rules adopted for one application might later be used for other applications.
In the course of design, it may be determined that a particular design rule cannot be used. Therefore, some means must be provided to deal with exceptions. If a design rule is not appropriate for one particular display, then an exception can be made by whoever has been appointed to make such decisions. But if a design rule cannot be implemented at all, perhaps due to other design constraints, then all designers for that particular system must be notified, and perhaps another design rule must be substituted.
Finally, after the design is complete, it must be evaluated against the original design requirements to ensure that all design rules have indeed been followed. To help in the exception process and in the evaluation process, it may be useful to assign different weights to the various rules, indicating which are more important than others. Such weighting will help resolve the trade-offs that are an inevitable part of the design process.
ROLE OF GUIDELINES IN SYSTEM DEVELOPMENT
If guidelines are applied in the way described here, there are some significant implications for the role of guidelines in system development. Generally stated guidelines should be offered to designers as a potential resource, rather than imposed as a contractual design standard (Smith, 1986). It is only specifically worded design rules that can be enforced, not guidelines.
Design rules can be derived from the guidelines material, but that conversion from guidelines to rules should be performed as an integral part of the design process, serving to focus attention on critical design issues and to establish specific design requirements. Once agreed design rules are established, those rules can be maintained and enforced by the managers of system development projects.
Specific design rules probably cannot be imposed effectively at the outset of system development by some external agency -- by a sponsoring organization or by a marketing group. It is the process of establishing design rules that should be imposed, rather than the rules themselves. A software design contractor might reasonably be required to establish rules for the design of user interface software, subject to review by the contracting agency. Available guidelines could be cited as a potentially useful reference for that purpose.
Some other cautionary comments about the application of guidelines deserve consideration here. Guidelines in themselves cannot assure good design for a variety of reasons (Thimbleby, 1985). Guidelines cannot take the place of experience. An experienced designer, one skilled in the art, might do well without any guidelines. An inexperienced designer might do poorly even with guidelines. Few designers will find time to read an entire book of guidelines. If they do, they will find it difficult to digest and remember all of the material. If guidelines and/or the rules derived from guidelines are to be helpful, they must be kept continually available for ready reference.
Guidelines cannot take the place of expert design consultants, or at least not entirely. A design expert will know more about a specific topic than can be presented in the guidelines. An expert will know what questions to ask, as well as many of the answers. An expert will know how to adapt generally-stated guidelines to the specific needs of a particular system design application. An expert will know how to trade off the competing demands of different guidelines, in terms of operational requirements.
For maximum effectiveness, guideline tailoring must take place early in the design process before any actual design of user interface software. In order to tailor guidelines, designers must have a thorough understanding of task requirements and user characteristics. Thus task analysis is a necessary prerequisite of guidelines tailoring.
The result of guidelines application will be a design for user interface software that may incorporate many good recommendations. However, even the most careful design will require testing with actual users in order to confirm the value of good features and discover what bad features may have been overlooked. Thus prototype testing must follow initial design, followed in turn by possible redesign and operational testing.
Indeed, testing is so essential for ensuring good design that some experts advocate early creation of an operational prototype to evaluate interface design concepts interactively with users, with iterative design changes to discover what works best (Gould and Lewis, 1983). But prototyping is no substitute for careful design. Prototyping will allow rapid change in a proposed interface; however, unless the initial design is reasonably good, prototyping may not produce a usable final design.
Considering the system development process overall, guidelines application will not necessarily save work in user interface design, and in fact may entail extra work, at least in the initial stage of establishing design rules. But guidelines application should help produce a better user interface. Because guidelines are based on what is known about good design, the resulting user interface is more likely to be usable. Certainly the common application of design rules by all designers working on a system should result in more consistent user interface design. And the single objective on which experts agree is design consistency.
Anyone involved in compilation of design guidelines must begin and end by acknowledging the significant contributions of other people. No one person, no matter how wise, can know everything about the complexities of user interface design. Nor will any one person have the perfect judgment and find the perfect words to express that knowledge to an interface designer. Thus when we propose guidelines we must build upon the work of others.
All design guidelines are necessarily based in some degree on judgment. Thus guidelines development must properly be a collaborative effort. The collective judgment of many people will often prove sounder than the ideas of just one person.
When many people contribute to guidelines development, we must find ways to acknowledge that contribution. One way is to cite previously published papers that pertain to the guidelines. Citations in this report are represented in the reference list that follows. But in the next several pages we also try to acknowledge more direct contributions to our work.
Many of the user interface design guidelines proposed in this report were not invented here, but derive from the ideas of other people. Where the idea for a guideline came from a particular source, an appropriate reference citation has been included for that guideline. Such citation offers credit where credit is due. More importantly, cited references may permit a reader who questions a particular guideline to explore its antecedents, perhaps to gain a better understanding of what is intended.
Citing an external reference in connection with a guideline does not necessarily mean that there is convincing data to support a guideline. Although the references cited here all contain worth-while ideas, only some of these references report results from systematic data collection.
Furthermore, citation of references does not necessarily mean that their authors would agree with the wording of guidelines presented here. In some instances, an idea has been borrowed intact. In many more instances, however, ideas have been modified, sometimes drastically, perhaps beyond the intent of their original authors.
In this report, in both the text and the guidelines, citations of specific references are in conventional form, showing author(s) and publication date. The particular format used here for citation and listing of references conforms in most respects to the standard referencing practice recently adopted by the Human Factors Society (1984).
However, four reference sources are used generally throughout the guidelines. Those sources are cited so frequently that they have been indicated simply by initials:
•BB = Brown, Brown, Burkleo, Mangelsdorf, Olsen, and Perkins, 1983 •EG = Engel and Granda, 1975 •MS = MIL-STD-1472C (as revised), 1983 •PR = Pew and Rollins, 1975
These four general references share a common characteristic -- like this report, they are all collections of design guidelines. None of these four general references provide supporting data for their design recommendations, and they need not be consulted for that purpose. The two early reports (EG and PR) have served as a fertile source of ideas for our current guidelines; where those reports are cited here, it means that their early recommendations are still judged to be correct. The two more recent reports (BB and MS) have drawn heavily from common sources, including previous editions of the guidelines proposed here; where those reports are cited, it means that their authors have made similar recommendations to those presented here.
The 1975 IBM report by Engel and Granda (EG) was the first widely recognized compilation of user interface design guidelines. That report has provided inspiration and has served as a seminal reference for others working in this field.
The 1975 BBN report by Pew and Rollins (PR) represents an admirable attempt to propose design guidelines for one particular system application. Its recommendations, however, can readily be generalized for broader application.
The 1983 report by Lin Brown and his colleagues at Lockheed (BB) is a good example of user interface guidelines developed for use as an in-house design standard, but which have also been made available for public reference.
None of these three reports are distributed by government sources such as the National Technical Information Service. However, these reports may be obtained by direct request from their authors.
MIL-STD-1472C (MS), in its current revision, is the US military standard for human engineering in system design. That standard has been cited here 237 times, for 209 guidelines. It is important to emphasize that guidelines do not carry the same weight as design standards. Guidelines are proposed here for optional application in system development, rather than to be imposed contractually. However, there is some considerable correspondence in content between these guidelines and the current military standard.
Not all ideas for guidelines come from published references. Some of the guidelines proposed here have resulted from discussion with professional colleagues. And the wording of all guidelines has been improved through critical review of earlier published versions.
A comprehensive glossary of words dealing with the user interface to computer systems could contain hundreds of terms. Such a glossary would be difficult to compile, because terms are often used inconsistently. The glossary presented here is not intended to be a comprehensive reference. Instead, it simply attempts to clarify the meanings of some of the terms used in this report. A term may be included in this glossary if it is used inconsistently in the general literature, or perhaps if its meaning in this report is more narrow than its commonly understood meaning.
"addressing messages" Preparing header information to specify the destination for data to be transmitted.
"attribute" A characteristic of a displayed element such as color, bolding, size, pattern or font, which can be specified by a user.
"backup" A capability that returns a user to the last previous display in a defined transaction sequence.
"bar graph" A graphic figure in which numeric quantities are represented by the linear extent of parallel lines (or bars). Bar graphs are useful for showing a comparative measure for separate entities or for a variable sampled at discrete intervals.
"cancel" A capability that regenerates (or re-initializes) the current display without processing or retaining any changes made by the user.
"category" A grouping of data values along a dimension defined for operational purposes. For example, an air traffic controller might wish to implement the same procedures for all aircraft with speeds in the category of 600 to 800 knots. See also "value".
"command language" A type of dialogue in which a user composes control entries, possibly with prompting by the computer.
"context definition" Displaying an indication of previous user actions or computer processing that will affect the results of current actions, in order to help a user predict how the system will respond.
"control entry" User input for sequence control, such as function key activation, menu selection, command entry, etc.
"controlling transmission" Ensuring that transmitted data are delivered, saved until they can be delivered, or returned to the sender. A computer will usually control transmission, but users may need information about that process.
"cursor" A marker on the display screen that indicates the current position for attention, which may designate a displayed item. A cursor might be positioned under computer control or by the user.
"curve" A graphed line that shows the relation between sets of data defined by two continuous variables. On a curve, data points are sufficiently close to appear as a smooth line.
"data" The raw materials from which a user extracts information. Data may include numbers, words, pictures, etc.
"data base" A collection of data that is stored in the computer.
"data display" Output of data from a computer to its users. Generally, this phrase denotes visual output, but it may be qualified to indicate a different modality, such as an "auditory display".
"data entry" User input of data for computer processing, and computer responses to such inputs.
"data field" An area of the display screen reserved for user entry of a data item.
"data field label" A displayed word or phrase that serves as a prompt for entering an item in a data field. Such a label usually cannot be changed by a user.
"data item" A set of characters of fixed or variable length that forms a single unit of data. Examples of a data item might be a person's last name, or a ZIP code. Sometimes a data item might contain only a single character. Data items may be entered by a user or may be supplied by the computer.
"data protection" Functional capabilities that guard against unauthorized data access and tampering, and data loss due to user errors or computer failure.
"data transmission" Computer-mediated communication among system users, and also with other systems. Transmitted data may include numbers, words, pictures, etc.
"data validation" Functional capabilities that check data entry items for correct content or format, as defined by software logic.
"default value" A predetermined, frequently used, value for a data or control entry, intended to reduce required user entry actions.
"diagram" A special form of a picture in which details are only shown if they are necessary for the performance of a task. For example, an electrical wiring diagram for a building would show wiring but not necessarily furniture or plumbing.
"dialogue" A structured series of interchanges between a user and a computer. A dialogue can be initiated by a computer (e.g., question and answer) or by a user (e.g., command language).
"dimension" A scale or categorization along which data may vary, taking different values at different times. For example, relevant dimensions for an aircraft might include its heading, speed and altitude. See also "variable".
"direction designation" User entry of directional data (azimuth, bearing, heading) on a display.
"display" See "data display".
"display control" Procedures by which a user can specify what data are shown, and how.
"display format" The organization of different types of data in a display, including information about the data such as labels, and other user guidance such as prompts, error messages, etc.
"display framing" User control of data coverage by display movement, including paging, scrolling, offset, expansion, etc.
"display selection" Refers to the specification of data outputs, either by a user or automatically.
"display tailoring" Designing displays to meet the specific task needs of a user, rather than providing a general display which can be used for many purposes.
"display update" Regeneration of changing data to show current status, by user request or automatically by the computer.
"drawing" Using computer aids to specify lines and other graphic elements, in order to create a pictorial representation.
"enter" An explicit user action that effects computer processing of user entries. For example, after typing a series of numbers, a user might press an ENTER key that will add them to a data base, subject to data validation.
"entry" See "data entry" or "control entry".
"error management" Interface design to facilitate the detection and correction of user errors.
"field" See "data field".
"file" A collection of data, treated as a single unit, that is stored in the computer.
"flowchart" A diagram that illustrates sequential relations among elements or events. Flowcharts are often shown as boxes connected by arrows.
"format" See "display format".
"form filling" A type of dialogue in which the computer displays forms containing labeled fields for data entry by a user.
"framing" See "display framing".
"function" A computer-supported capability provided to users as an aid for task performance. Examples of functions are position designation or direction designation.
"function key" A key whose activation will effect a control entry.
"graphics" Data specially formatted to show spatial, temporal, or other relations among data sets.
"graphic element" A component part of a graphic display, such as a line, a circle, or a scale.
"graphic interaction" A kind of dialogue which permits a user to select displayed control elements by pointing and other direct manipulation.
"hard copy" A printed paper display output by the computer.
"help" A capability that displays information upon user request for on-line guidance. HELP may inform a user generally about system capabilities, or may provide more specific guidance in information handling transactions.
"highlighting" Emphasizing displayed data or format features in some way, e.g., through the use of underlining, bolding, or inverse video.
"information" Organized data that users need to successfully perform their tasks. Information serves as an answer to a user's question about data. It is used here to refer to the effective assimilation of data by a user.
"information system" A computer-supported, task-oriented tool designed to help users perform defined information handling tasks.
"initiating transmission" The process of actually sending a prepared message or data file. Transmission can either be initiated by the computer, or by a system user.
"input" See "control entry" and "data entry".
"interaction" See "transaction".
"interface" See "user-system interface".
"interrupt" Stopping an ongoing transaction in order to redirect the course of the processing. Examples of interrupt options are BACKUP, REVIEW, CANCEL, RESTART.
"item" See "data item".
"job" A set of responsibilities and activities that are defined for each system user.
"label" A title or descriptor that helps a user identify displayed data. See "data field label".
"line graph" A scaled figure that shows relations among sets of data defined by two continuous variables. On a line graph, data points are connected by straight line segments.
"menu selection" A type of dialogue in which a user selects one item out of a list of displayed alternatives, whether the selection is by pointing, by entry of an associated option code, or by activation of an adjacent function key.
"message" Refers specifically to data that are transmitted as a discrete transaction from one computer user to another along with formal header information, and may sometimes refer loosely to other forms of data transmission. See "data transmission".
"natural language" A type of dialogue in which a user composes control entries in natural language (e.g., English, Spanish, French) rather than by a more formally constrained command language.
"operator" See "user".
"output" See "data Display".
"page" The data appearing at one time on a single display screen.
"panning" An orientation for display framing in which a user conceives of the display frame as moving over a fixed array of data. The opposite of scrolling.
"picture" A detailed representation of a real or imaginary object or event.
"pie charts" A circle divided into sections (as pieces of a pie) in order to represent graphically the relative proportions of different parts of a whole.
"plotting data" Locating data points on a scaled graphic display by means of coordinates.
"position designation" User selection and entry of a position on a display, or of a displayed item. See also "cursor".
"preparing messages" Includes specification of contents, format and header information.
"query language" A type of dialogue in which a user composes control entries requesting specified data from a data base.
"question and answer" A type of dialogue in which a computer displays questions, one at a time, for a user to answer.
"receiving messages" Includes provision of computer aids for queuing, reviewing, filing or otherwise disposing of data transmitted to a user from some other source.
"restart" A capability that cancels all user entries in a defined transaction sequence.
"review" A capability that returns a user to the first display in a defined transaction sequence, while retaining any entries made by the user.
"scaling" The positioning of displayed data elements with respect to a defined measurement standard.
"scatterplot" A scaled graph which shows relations among individual data points in a two dimensional array.
"screen" See "page".
"scrolling" An orientation for display framing in which a user conceives of data as moving behind a fixed display frame. The opposite of panning.
"selecting" A user's action of identifying display elements to the computer in order to manipulate those elements in some way, e.g., to move them, or change their attribute(s), or delete them.
"selection, display" See "display selection".
"sequence control" Logic and means by which user actions and computer responses are linked to become coherent transactions.
"situation display" A type of diagram on which changing data are shown on a fixed background.
"specification" See "selection".
"status information" Information on current data processing status which is displayed to a user either automatically or by user request, perhaps indicating system load, keyboard lock, or processing delay.
"suppression" User control of displayed data by temporary deletion of specified data categories.
"suspense file" A temporary collection of data saved by a computer for later use.
"system" See "information system".
"task" A series of transactions that comprises part of a user's defined job.
"terminal" An input/output device used to enter and display data. Data are usually entered via a keyboard, and are usually displayed via a video screen ("soft copy") or a printer ("hard copy").
"text entry" Initial entry and subsequent editing of textual data.
"transaction" An action by a user followed by a response from the computer. Transaction is used here to represent the smallest functional unit of user-system interaction.
"transmission control" Controlling the sequence, content, format, routine, timing, etc., of data transmission.
"update" See "display update".
"user" Any person who uses an information system in performing his/her job.
"user guidance" Computer prompts and feedback that aid users in performing their tasks. Examples include data field labels, alarm or alert signals, error messages, and HELP displays.
"user records" Automatic recording of user performance, e.g., data access records, error records, requests for HELP.
"user-system interface All aspects of information system design that affect a user's participation in information handling transactions.
"value" Specific data for a particular dimension or variable. For example, values for an aircraft's speed might be 800 knots during one observation and 500 knots during another. See also "category".
"variable" See "dimension".
"window" A portion of a display screen showing a particular kind of information, e.g., a command entry window, or a window for displaying error messages. Windows may be stable features of a display format, i.e, defined by system designers, or may be temporary, i.e., window overlays requested by a user for temporary display of data, menus, etc.
"window overlay" A portion of a display that is temporarily used to show added features such as requested data, menus, user guidance, etc., which may obscure initially-displayed data.
"work station" The physical facilities with which a user works and the relevant environment, including such things as computer terminals, source documents, desks, chairs, and lighting.