PROCEEDINGS OF THE HUMAN FACTORS SOClElY-32nd ANNUAL M E E T I N G 4 9 8 8

GUIDELINES FOR THE USE OF A PROTOTYPE IN USER INTERFACE DESIGN Lovie A. Melkus Robert J. Torres IBM Application Systems Division 2 2 0 Las Colinas Irving, Texas ABSTRACT Although the use of a prototype of the user interface of a software application early in the development cycle is a valuable tool in the design of a usable user interface, prototyping can be difficult to introduce into the development process. Furthermore, designers without experience in using a prototype can run into problems which counteract the value of this user interface design methodology. Designers with experience in a substantial prototyping effort have formulated guidelines for the use of prototyping which can help to minimize these problems. various organizations. Management and staff believed that the user interface would be the critical aspect of the success of the project, and that modeling was essential to building the right user interface. Although prototyping had often been used as a development tool by this organization, this effort used the tool on a broader scale than it had been used before, used it earlier in the cycle, and gave it more visibility -- across sites and functional areas -- than a prototype had previously received.

INTRODUCTION The use of a prototype of the user interface of a software application early in the development cycle is advocated in the human factors community as the right approach to software development (Gould and Lewis, 1 9 8 3 ; Norman, 1 9 8 4 , Hewett, 1986). Prototyping allows early evaluation of an interface by users of the system, and that feedback is essential to the development of a usable interface (Schneier and Mehal, 1 9 8 4 ; Melkus, 1 9 8 5 ; Lund, 1 9 8 5 ; Gould and Lewis, 1 9 8 3 ) .

The prototyping tool used for this project was chosen because it allowed simple definition of panels and representation of the user interface architecture and of major user interface features.

Although most software designers and developers would not disagree with ideas such as these, their acceptance of the concept of prototyping does not mean that it is easy to introduce prototyping into an established software development process. Despite the many benefits which prototyping can provide in the design and development of a user interface, it can also introduce problems into the development cycle if it is not carefully managed. The guidelines described below, derived from experience with a substantial prototyping effort, can facilitate the use of prototyping in a software development project.

The prototyping effort produced the results cited by advocates of this approach:

*

Early usability testing Usability tests were conduc’ted before any code was written.

*

Iteration Successive usability tests were run, allowing designers the opportunity to correct flaws in later iterations. Data from later tests indicated when changes to the interface had resulted in improved user performance.

The project from which these guidelines are derived was an integrated application, with development spread across several sites. The prototype had great visibility throughout the organization, and was used as a vehicle of communication by

370

PROCEEDINGS OF THE HUMAN FACTORS SOCIETY-32nd

*

Customer involvement

Nevertheless, management alone cannot create the support from throughout the organization which is required for a successful prototyping effort. The user interface design team should assume the responsibility of working closely with development and technical design in order to secure the commitment and cooperation of those groups. There should exist a constant flow of information and ideas between development and user interface design; the flow should exist in a cooperative, non-contentious environment which allows both organizations to take pride in the evolving user interface definition.

Customers participated in the usability testing and were able to give valuable feedback to designers early in the development process.

*

ANNUAL M E E T I N G 1 9 8 8

Early feedback from internal organizations The prototype provided a vehicle which allowed marketing, planning, and other internal organizations an opportunity to understand the "look and feel" of the proposed interface. The development organization was able to incorporate these suggestions at an early stage -- before code was written.

Because the user interface group is a relative newcomer to the organization, those designers should be willing to initiate the building of this close tie. By asking for assistance and guidance from developers, user interface designers can achieve two goals: developers begin to support the design effort because of their own involvement, and designers benefit from the in-depth knowledge of developers in specific areas. Designers working without this kind of development assistance are likely to create an interface which, although it may be elegant, will not be sophisticated enough to make the transition from prototype to real function.

In addition to providing the benefits listed above, use of a prototype on this scale also taught designers some valuable lessons about how this development method could be used most effectively. These lessons are incorporated into the four guidelines listed below. Organizational Commitment To The Process Is Essential The commitment and support of high-level management is a critical aspect of the success of the prototyping effort. A development team which has experience with a wellestablished development process will resist change unless it is clear that the change represents a new organizational direction.

A Prototype Is Nothing More Than A Representation Of Design.

Once an organization is convinced that building a prototype of the end user interface is the right thing to do, there may be a tendency to inflate the capability and purpose of the prototype. A prototype will never be a substitute for a complete specification of the project. It does not contain the level of detail necessary for programmers to code to, and it is not an efficient source of information for programmers. User interface designers have probably put considerable effort into masking functional complexity from end users; programmers need to understand the functional complexity and should not have to pursue numerous paths within a prototype in order to understand a function.

Management may understand the importance of the end user interface (which is stressed by consultants, writers, and customers) without understanding how it should affect the development process. User interface designers will be responsible for outlining how a successful user interface can be attained, including how a prototype will be used, and educating management on the user interface process. It is important that everyone involved in the project understand the concept -and importance -- of usability testing and iteration; acceptance of the concept by management helps to generate this idea through the organization.

Designers, also, must be aware of the limitations of the prototype,

371

PROCEEDlNGS OF THE HUMAN FACTORS SOCIETY-32nd ANNUAL M E E T I N G 4 9 8 8

evaluate the prototype must also understand its limitations. Management, customers, usability test subjects, and marketing representatives may all have an opportunity to use the prototype. They will tend to ask for more function and better performance, often confusing the capabilities of the prototype with those of the real system.

which is a representation of design, not a substitute for it. Because procedures for the design and development of an end user interface have not been as well defined as those for other aspects of software, user interface designers may be asked to produce a prototype of the system before they have had an opportunity to go through preliminary design stages. This pressure, of course, should be resisted. A prototype created without adequate preliminary analysis and planning will not be a means to the development of a superior user interface. Unfortunately, unless designers have adequate documentation of the user interface design process and have communicated that process to the development organization, they will find it very difficult to explain why they cannot go immediately to the creation of a prototype.

The design team must resist the requests for more and more function, and reinforce the definition of what the prototype is and what it can do. Otherwise, the prototype will become a large piece of unwieldy code; it will no longer be a means for quickly looking at user interface alternatives. When the prototype is driven beyond its capability, it may be as hard to change as a real product would be; and designers will spend their time maintaining the prototype instead of designing alternatives.

The Prototype Is A Representation Of High-Level Design.

The Prototyping Tool Must Be Adequate There are several factors one can use to assess the adequacy of a prototyping tool. Major factors which influence selection and use of a given tool include the following:

A prototype which is developed early in the development cycle is a means to evaluate approaches to the user interface. It should not be a representation of the complete interface, although designers may choose to develop a limited number of paths in greater detail. In selecting these paths, the designer should consider the following:

*

Representation of the overall interaction styles

*

Demonstration of overall system definition and structure via significant or representative paths through the system

* *

*

Sufficiency of design representation

*

Efficiency of development and use

*

Sufficiency for evaluation in both test and demonstration environments

Sufficiency of design representation. The model or prototype is a representation of the user interface and function to be provided by the system. A critical mass of key user interface features and function must be represented with fidelity. Failure to do so results in long-term problems for the design team when trying to explain, sell, evaluate, or transfer the user interface design to the product implementation team.

Necessary representation for sensitive aspects of the user interface Sufficient representation for user interface evaluation of conformance to requireand detection of severe problems

The user interface designers must determine the key user interface interface features and functions of the product. Then they must evaluate candidate tools by mapping the features and requirements for the design to the capabilities of the tool alternatives.

The necessity for a realistic perception of the purpose and capability of the prototype extends beyond the development/ design team. All other groups who will work with or

372

PROCEEDINGS OF THE HUMAN FACTORS SOCIETY42nd ANNUAL MEETING1988

A summary of key user interface features for any product include but are not limited to the following:

*

Conformance to required architectures

*

Support of required user interface styles, e.?., commands, graphical interface, menu bypass, etc.

Development of the model requires that the user interface designer perform model development tasks. Model development tasks are independent of design tasks in that they relate to the effort involved with representing the design in the tool. Model development tasks include:

Panel definition and esthetics Support for representing application user interface components

*

Plan

* * * *

Design, develop, and test Maintain and control Document and distribute Transfer to development

The list of potential considerations is lengthy. Comparisons of tool candidates typically leads to relative and qualitative evaluations.

If a tool is selected which requires skills not available to the design team, then design schedules can be affected.

In the case of the modeling task undertaken by the design and model development team, the evaluation of requirements compared to alternative tools found that no one tool was sufficient to represent the design.

Again, a list of the key model development factors against the candidate tools. The comparison of tool candidates results in relative and qualitative results. For the case of the modeling task upon which these guidelines are based, the evaluation of candidates favored the same tool chosen as for Sufficiency of Design Representation. The schedule was very aggressive. The design team was very small and was responsible for developing the model in parallel with the design.

The selection process based on this comparison favored one modeling tool over others because of its ability to achieve architecture conformance, support of key user interface styles, and the support for key application user interface features. Selection of another tool would have resulted in "working around" or ignoring the architecture representation in the expected functional environment, an approach which was clearly unacceptable.

The skills of the design team were heavily skewed towards design versus programming. Selection of any other tools would have resulted in missing the early design schedules. Although an ideal prototype would have included code which would be used in the final product, a tradeoff was made in order to facilitate the development of the prototype with the skills available.

Efficiency of development and A model or prototype of a software product user interface is software pure and simple. The model is a tool which is used for many purposes, design evaluation and quick iteration of alternatives being key requirements.

use.

Sufficiency for evaluation. The next major feature that the model or prototype must satisfy is that it should allow evaluation of the product in both test and demonstration environments.

The tool selected must be matched to the people and skills available, and it must not require people or hardware/software resources that are scarce to the overall project development team.

All tools may be adequate to some degree for designers and design purposes. However, if the design team must also meet requirements for formal usability testing, demonstrations to designers and management,

Developing the model is software development, which demands a rigorous process if large scale and formal design activities are required.

373

PROCEEDINGS OF THE HUMAN FACTORS SOCIEZY-32nd ANNUAL M E E T I N G 1 9 8 8

and hands-on by customers and executives, then a more sophisticated tool is required.

used with an understanding of simulation principles, and implemented with an appropriate tool. The effort required of a large product development organization to establish prototyping as an essential element of the development process can result in a user interface which has been improved by means of iteration and early evaluation by users.

When the prototype will be used for evaluation, designers should consider whether capabilities such as data entry, editing, database, logic, and program exits will be necessary. The tool used in this project was chosen for characteristics (e.g., simplicity of development and representation of the user interface architecture) other than its technical capability. Lack of editing capability, which is described below, and lack of a database facility were particularly problematic during evaluation. The prototype, because it had hard-coded panels, forced users through a single thread. It often confused test subjects, and it forced designers to maintain multiple versions of a single panel.

REFERENCES Gould, J. D., and Lewis, C. Designing for Usability -- Key Principles and What Designers Think. In CHI'83 Conference Proceedings, ed. A. Janda. New York: Association for Computing Machinery, 1983, 50-53. Gould, J. D., and Lewis, C. Human Factors Principles in Designing for Usability. IBM Research Report, 1983. Norman, D. A. Cognitive Engineering Principles in the Design of HumanComDuter Interfaces. In HumanComputer Interaction: Proceedings of the First USA-Japan Conference on Human-Computer Interaction, ed. Gavriel Salvendy. New York: Elsevier, 1984, 11-16.

Sufficiency for test is, to some extent, a subjective judgment. Designers must make trade-offs between what is desirable for usability testing and what is practical or feasible in early-stage prototyping. For instance, test subjects using our prototype often made suggestions regarding "editor" function. In fact, the prototype did not have an editor, and designers did not believe that building an editor specifically for the prototype would result in sufficient added value to justify its cost in development effort and delay in the prototyping effort.

Hewett, T. and C. Meadow. On Designing for Usability: An Application of Four Key Principles. In CHI-86 Conference Proceedings, ed. M. Mantei and P. Oberton. New York: Association for Computing Machinery, 1986, 247-252. Melkus, L. The Benefits of Laboratory Testing for Usability. In Proceedings of the Twenty-First Annual Computer Personnel Research Conference Cosponsored with Business Data Processing, ed. James C. Wetherbe. New York: Association for Computing Machinery, 1985, 91-96.

Designers should participate in early usability tests as "consultants" in order to answer questions from experimenters and users which pertain, even indirectly, to the technical capability and limitations of the prototype. Inattention to this requirement will mean that designers will repeatedly answer comments about function or constraints which are representative of the tool or the prototype instead of the product; in addition, usability evaluations will be much more valuable when experimenters are knowledgeable about which concerns are applicable to the product under development.

Schneiderman, B. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Reading, Mass.: Addison Wesley Publishing Company, 1987. Schneier, C., and M. Mehal. Evaluating the Usability of Application Inter-

CONCLUSION Prototyping can be effective, provided that it is properly managed,

374