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

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.

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.

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 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:

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.

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.

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:

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.