by Charles Irby and Linda Bergsteinsson, ITG Systems Development Division Thomas Moran, William Newman and Larry Tesler, Palo Alto Research Center JANUARY 1977

http://www.bitsavers.org/pdf/xerox/sdd/A_Methodology_for_User_Interface_Design_Jan77.pdf

Preface

In April 1976, a working group was formed at the Xerox Palo Alto facility to study the problem of user interface design. The group was led by Charles Irby, and included Linda Bergsteinsson, Tom Moran, William Newman and Larry Tesler as its other full-time members. The group met on a weekly basis throughout the spring and summer of 1976. David Liddle and Butler Lampson attended some of the early meetings.

User interface design is an essential part of the design of interactive application programs. The user interface encompasses the set of commands by which the user operates the program, the display techniques used to present the state of the program to him, and the more abstract notions involved in learning how to operate the program effectively. Successful user interface design is crucial to the production of useful Office Information Systems.

The working group decided at one of its earliest meetings that it could not attempt to propose an actual design for an OIS user interface. The reasons for this lie in the complex nature of user interface design, and the difficulty of performing the design without a thorough analysis of the task. These problems are discussed further in the main report.

The group therefore concentrated its efforts on developing a straightforward methodology for user interface design. This methodology is presented in the report. Included with the report is a detailed description of a user interface developed along the lines suggested.

The working group will now turn its attention to interaction with the application designers and subsequent design of the user interface facilities for OIS.

Acknowledgement

We wish to thank the many people who provided useful comments and suggestions about this report, in particular D. DeSantis, A. Kay, R. Kimball, T. Mott, R. Sproull and R. Taylor.

Introduction

One of the most troublesome and least understood aspects of interactive systems is the User Interface. In the design of user interfaces, we are concerned with several issues: the provision of languages by which users can express their commands to the computer; the design of display representations that show the state of the system to the user; and other more abstract issues that affect the user's understanding of the system's behaviour. Many of these issues are highly subjective and are therefore often addressed in an ad hoc fashion. We believe, however, that more rigorous approaches to user interface design can be developed; we present such an approach in this report.

In preparing this document, our main concern has been to propose a methodology for user interface design. It is based primarily on the separation of user interface design into a small number of separate design phases, to be applied iteratively in order to reach a satisfactory design. For each of these phases we have developed representations in which to present the concepts involved; these representations help both in formalising the design process, and in defining the user interface design for purposes of documentation and communication with others. We have included a number of guidelines that we feel may be useful to those designing user interfaces. To illustrate the use of our methodology, we have included a partial description of a user interface design for a simple interactive page layout system.

The main report is a fairly concise statement of our proposals, with only a few examples included to illustrate specific points. The user interface for page layout is described in the Appendix. Marginal notes are included with this description, to explain some of the issues that arose in the user interface design. The reader should note that this is not a complete user interface specification: a number of detailed design issues have been left unresolved, and some of the most repetitive passages have been curtailed. We hope that the reader will not be confused or misled by these omissions.

Task Analysis

In a subject as little understood as user interface design, it is not surprising to encounter many different methodologies. Some of these scarcely deserve to be called methodologies: an example is the very common practice of studying competitors' products, making a list of what appear to be their most effective features, and then planning the new design from this list. Another approach is to proceed by inventing user functions one by one, implementing each function together with a command to invoke it. Both of these methods tend to produce inconsistent user interfaces. A more sensible approach, still unsatisfactory, is to implement a complete set of functions and then to try to design a consistent command language: the resulting language may indeed be consistent, but will probably involve unsuitable concepts and abstractions that the user cannot understand.

These design methodologies are all unsatisfactory for the same basic reason: they all omit an essential step that must precede the design of any successful [[User Interface]], namely task analysis. By this we mean the analysis of the task performed by the user, or users, prior to introducing the proposed computer system. Task analysis involves establishing who the users are, what their goals are in performing the task, what information they use in performing it, what information they generate. and what methods they employ. The descriptions of input and output information should include an analysis of the various objects, or individual types of information entities, employed by the user.

Analysis of a simple text-editing task, for example, will typically indicate the involvement of two people, an author and a typist. The goal of the author is to produce a set of corrections to the current draft of a document, while the typist's goal is to follow the instructions implied by these corrections, in order to generate a fresh draft. Thus the list of corrections (probably written on the current draft) is the author's output; this list, in conjunction with the current draft, forms the typist's input. Conversely, the output from the-typist is-the fresh draft, and this forms the input for the author's next editing task. In each case, the principal information objects are pages of text, arranged in paragraphs, each paragraph consisting of lines of text made up of words, each word consisting of text characters. The typist's input objects also include corrections, in the form of a set of marks relating to entities in the draft. The method employed by the author is to read the current draft, marking his corrections; the typist's method is to copy text from the current draft to the fresh one, performing each correction as encountered.

Task analysis thus leads to what we term the current task description. Its purpose is to define current procedures, informational objects and their inter-relationships, and terminology. It serves as a checkpoint against which further design steps can be measured. The Appendix includes the current task description for a somewhat more complex task than text editing, taken to considerably greater detail. In time, the form of the current task description may evolve to a yet more useful form.

The Three Components of the User Interface

The purpose of task analysis is to direct the remaining stages in user interface design. The current task description, with its breakdown of the information objects and methods presently employed, offers a starting point for the definition of a corresponding set of objects and methods to be provided by the computer system. The idea behind this phase of design is to build up a new task environment for the user, in which he can work to accomplish the same goaIs us before, surrounded now by a different set of objects, and employing new methods. The new task environment can be described much as before, by means of a new task description. In the generation of this new task description. the three basic components of the user interface must be considered. These three components are:

The user's conceptual model (generally abbreviated to user's model) of the system with which he is interacting and how it relates to the tasks described in the current task description;
The command language that he uses in order to express commands to the system;
The information display used by the system to present the results of executing commands, and to show the state of the system in general.

We consider the user's model to be the most important single component of the user interface. This is the user's set of concepts, or abstractions, of the objects he is manipulating with the aid of the system, and of the processes, or actions, that he can apply to these data. This set of objects and actions is crucial in enabling the user to anticipate the behavior of the system. In general, the choice of abstractions for objects and actions to a large extent determines the actual data structures and procedures used in implementing the application program. It is important, however, to design these abstractions with the user's needs in mind; otherwise they may turn out to be inconsistent or incomprehensible.

The command language provides the user with a set of physical actions to use in performing the conceptual actions of the user's model. Command language design can be viewed as the problem of providing the means to apply each of these conceptual actions. In reality, however, command language design also involves a great deal of careful and detailed work on command syntax. It differs from user model design in that it is greatly influenced by the physical environment in which the system will be used. It also interacts strongly with the third component of the user interface, information display.

Information display, like the command language, is concerned with providing the user with a more concrete representation of the user's model; in this case, the objects of the user's model are furnished with visible representations. Information display interacts with the command language, in the sense that command language design involves a number of considerations of output effects. In particular, interactive command languages depend on feedback to reassure the user that his actions are being understood, and to prevent him wherever possible from taking a wrong step. Most display-oriented command languages also make use of the display of control information: cursor symbols. command menus, window boundaries. and so forth. The remaining class of information display, data presentation, is concerned purely with showing the user the state of the information he is manipulating.

In order to avoid a fragmented approach to information display, we distinguish between the intrinsic objects essential to the application, and control objects, such as menus and windows. used to control user actions. This concept allows us to treat both control information display and data presentation in a uniform way, as the display of objects.

The Design Process

In this section, we describe in detail the steps involved in developing the user interface. This is an iterative process. in which the designer must return time and again to earlier phases of the process after encountering snags in the later phases. Thus the sequence of steps we describe here is best viewed as a framework for the actual steps followed in design.

Task Analysis
Task analysis is the process in which a task description is developed. This analysis attempts to describe the current task as performed prior to the introduction of the computer system:
1. Definitions are given, itemizing each of the important components involved in the task, and the terms used to describe them;
2. First-level tasks are identified. Typically each of these represents a portion of the entire task domain performed by a single person; in some cases, it may be useful to divide up the duties of each person into several of these tasks.
3. Under each major task heading, descriptions are drawn up of the different entities involved, as follows:
  Agents: i.e. the person, persons, or machines performing the task;
  Goals: the rationale behind the task, and the criteria that determine its completion;
  Inputs: the items of information required in order to perform the task.;
  Outputs: the items of information generated by performing the task;
  Methods: the procedures employed to get the task done; each method identifies a series of subtasks that are then defined by recursively applying step 3, until a sufficiently fine level of detail is reached.
The User's Model
The user's model is based on a set of conceptual objects, and on a corresponding set of actions that may be performed on these objects. From the user's point of view, the objects are abstract entities that behave in a consistent and predictable way when the actions are performed on them. The designer, on the other hand, may find it useful to consider objects to be items of data structure in the user's domain: corresponding to each object seen by the user, there will generally be an item in the data structure maintained by the system. Design of the user's model must steer a careful path between the often conflicting requirements of the user and the system designer.
We suggest the following guidelines for user's model design:
Completeness: if a concept, or set of concepts, is introduced to the user's model, it should be supported thoroughly and convincingly.
Consistency: the behavior of the system should be consistent, whatever the context of use. Objects should not exhibit different behavior at different times for no apparent reason, and actions should have consistent effects.
Use of concrete objects: it is sometimes helpful to base the choice of objects in the user's model on concrete examples. It would be appropriate, for example, to allow the user of a page layout system to manipulate the same words, text lines and paragraphs that he would layout manually. While this can be a useful guideline in choosing a user's model, we feel it can also be limiting.
The New Task Environment
A description of the user's model forms the starting point for a description of the new, computer-based task. Many features of this description bear close resemblance to corresponding parts of the manual task description completed earlier. The purpose of this description is different, however: it is the foundation upon which the detailed command language design is based. Descriptions of objects and actions are therefore taken to a level of detail that will support the direct development of the command language. The actual task description is preceded by a section describing each object and action in some detail.
The representation used for the current task description can be used almost unchanged for the new task. The main differences are (a) a complete list of objects and actions should be provided with control objects included; and (b) tasks are broken down into subtasks until they reach the level of actions, so as to provide a basis for command language design.
Information Display
Information display is on the whole a poorly documented area. As we have mentioned earlier, it encompasses three topics: data presentation feedback and control information display, The last two topics relate closely to command language design.
Data presentation is the means by which the system presents to the user a view of the objects he is manipulating. The purpose of data presentation is twofold: it conveys to the user the effects of his previous actions; and it enables him to plan his next move. The design of data presentation techniques should take both of these into account. To some extent, this raises conflicting requirements: in order to show the effects of past actions, data presentation techniques should show the state of the user's model in an economical and consistent fashion; to help in planning the next action, they should highlight the information on which this action is likely to operate. We suggest that any such conflict be resolved in favor of overall consistency.
The design of data presentation methods is considerably easier when the user's model is based on concrete objects. In text-editing and formatting applications; for example, it is obvious that text should generally be displayed in the form of character symbols -- anything else would require the user to make a mental transformation from the displayed data to the text itself. In applications such as information retrieval, however, there may be no obvious method of displaying the data, and the designer must choose among several alternatives. When it is not possible to portray all aspects of an object accurately, the designer must decide which aspects are the most important.
Guidelines for data presentation include the following:
Faithfulness: the display should show as faithfully as possible the true state of the stored data. Often the data cannot be shown absolutely faithfully because of poor display resolution; this creates a problem well-known in text editor design --"what you get" when printing the text is not "what you see" on the screen. A related problem is that of "cleaning up" the screen after one or more deletions: in cases where this is not done immediately, the user should be made fully aware that the screen shows anomalies.
Economy: in applications such as information retrieval, it is very valuable to perform some analysis of the data to be displayed, and to try to isolate the different attributes that are to be shown. This will help in the design of an economical and effective display. Bertin [1] has suggested some further guidelines to the use of symbol shapes, line qualities, etc.
Control information display is concerned with the control objects used in operating the program. Many of the same techniques used in data presentation design are useful here. Guidelines include:
Physical convenience: the control objects should lie close at hand. Command menus, if used, should not be placed at the extreme edge of the screen where they can be reached only with excessive hand movement.
Selections should be visible: if commands operate on a selected object, then the user should always be able to find that object easily.
Feedback is distinguished from other forms of information display in that it relates much more closely to actions than it does to objects, and in particular is generally very closely coupled to the actual commands of the command language. Feedback is used wherever it can help the user to give his commands more quickly and accurately. Guidelines include:
Economy: feedback should show only the minimum information to permit the command to be given. Feedback should not be used where it is not needed: one should be sparing in the use of dynamic effects like dragging, rubber-band lines and zooming.
Smooth feedback: where the action requiring feedback is a smooth one, the feedback should be smooth; this is particularly true of pointer movement. The user should be able to easily follow the transformations that are taking place on the display.
The Command Language
The final section of the user interface specification is a description of the command language. We suggest the use of a relatively formal command language description, organized in the same order as the lowest-level subtasks. A suggested syntax for this formal description is given in the Appendix. It is also suggested that the designer compile cross references of user input and output: these list the effects of each input, and the meaning of each style of output, and help to expose ambiguities and sources of confusion. It should be obvious that command language descriptions are aided by the use of illustrations, figures and examples.
Command language design involves decisions at two levels: the global level, at which the choices are made between alternatives such as menus and function buttons, prefix or postfix operators, and so forth; and at the level of individual commands, where detailed design can be extremely important. Guidelines for command language design include:
Consistency: function keys should retain their meaning throughout the system if possible, and if not should have analogous meanings (e.g. an "insert" key that adds text or dispenses ink).
Minimum effort: the most frequently used commands should be easier to apply, and should not require great dexterity.
Safeguards: dangerous commands should require confirmation from the user, and should use keys or menu symbols that are not easily confused with others.
Modes: command languages should avoid the use of several different command modes, in which different meanings are assigned to the same set of input actions. The mode of a command language is one additional concept that the user must understand; and even when understood, it is a frequent cause of erroneous user action.

Conclusion

The methodology proposed in this report involves the use of three levels of representations for ideas involved in the user interface: the Task Description, the User's Model, and the Command Language. We believe the use of such a three-stage approach to user interface design offers a number of- advantages over other approaches. Some particular benefits are worthy of mention:

The designer is encouraged to focus his attention on the user's view of the task and of the system. An attempt is made to treat the user's view as a precise and specific concept in these representations, not just a metaphor.
The representations define the state of the design. both before and after completion. Thus they serve both as working documents and as design specifications for program implementation. As working documents, they can provide several general benefits to the designer: they force completeness of the design for the given task, and they tend to encourage consistency and simplicity. As specifications, they communicate in a precise manner the intended design to the user manual writer, the system programmers, etc. They can also be helpful in coordinating the efforts of several designers.
The representations help to rationalize the design, i.e. to show the reasons for designing the user interface in a particular way.
The representations can serve as a framework for the development of design principles and for conducting user studies.
The representations potentially provide the basis for useful design analysis, involving such aspects as learning time, interference between commands, performance for various types of task, etc.

We have suggested a relatively formal syntax for user interface descriptions. We consider this appropriate where communication amongst designers is important. We do not recommend the use of such a syntax in the user's manual.

The methodology we propose implies different design activities at the different stages of design. We believe that user model design is the most "creative" aspect of the entire process; it must be preceded by careful task analysis and followed by equally careful command language design. This in turn suggests the possibility that different kinds of professionals, each a specialist of sorts, be involved in the design process, working either as a team or as consultants to a "systems architect" who has overall responsibility for the design.

References

Bertin, 1., Semiologie Graphique, Paris: Mouton, 1967.
Newman, W. M., and Sproull. R. F., Principles of Interactive Computer Graphics, McGraw-HilI, 1973, Chapter 11.