Najjar, L. J. (1990). Rapid prototyping (TR 52.0020). Atlanta, GA: IBM Corporation.

Rapid Prototyping

April, 1990

Lawrence J. Najjar

IBM Corp.
Software Usability Department
R16B
Atlanta, GA 30328

Abstract

Rapid prototyping is a process for creating a realistic model of a product’s user interface. A rapid prototyped user interface is easy to change and gets customers involved early in the design of the product. This report suggests that successful rapid prototyping is done quickly and iteratively by domain experts. It suggests steps for the rapid prototyping process and describes advantages and disadvantages of rapid prototyping. To prototype successfully, the report recommends that you pick a rapid prototyping tool that meets your needs, form a small prototyping team, get lots of customer feedback, and iterate until customers are delighted with your user interface.

Preface

This report is a general, non-technical introduction to rapid prototyping. It is intended for information developers, managers, marketers, planners, programmers, and usability representatives who help develop product user interfaces.

Biography

Larry Najjar is a human factors engineer in IBM’s Industrial Sector Division Software Usability department in Atlanta, Georgia. He earned his MS in Engineering Psychology from the Georgia Institute of Technology in 1983. After graduating, he worked for Systems Research Laboratories in Hanover, Maryland where he helped design and prototype the hardware and software user interface for an advanced word processing and transcription work station. In 1984, he joined IBM’s Systems Integration Division in Rockville, Maryland where he helped design and prototype the hardware and software user interface for tower and en route air traffic controllers. In 1989, he transferred to the Industrial Sector Division in Atlanta. He helps improve the usability of software for health and electronic data interchange products and coordinates the development of a proprietary rapid prototyping tool. Larry is a member of the Human Factors Society.

Acknowledgement

The author is grateful to Emily Walker for her efforts to identify and obtain publicly available articles referenced in this report, to Betsy Freeman for providing copies of the IBM documents on rapid prototyping, and to Laurie Najjar for her valuable editorial suggestions.

Overview

Due to the intense competition in software, products that are successful in the marketplace are:

• Functional,
• Reasonably priced, and
• Easy to learn and use.

Pricing aside, it is difficult and time-consuming to develop products with these characteristics. However, one way to minimize effort and time spent is to use the rapid prototyping process of product development.

Rapid prototyping involves creating a realistic model of a product’s user interface to get prospective customers involved early in the design of the product. Using rapid prototyping, you model the look and feel of the user interface without investing the time and labor required to write actual code. Then you show the prototype to prospective customers, revise the prototype to address their comments, and keep repeating these two steps. Your goal is to produce a complete, agreed-upon design of the product’s user interface before writing a single line of actual code. When walkthroughs and usability tests show you that customers are delighted with your prototype user interface, then programmers can model it when they code the actual product.

Elements of Successful Rapid Prototyping

Successful rapid prototyping is performed:

• Quickly – The first pass must be done quickly, and subsequent improvements should be incorporated immediately. While the prototype needs to give customers a realistic feel for the product, it does not need to include special graphics or computational algorithms that require a lot of time and effort to create.
• Iteratively – The prototyped user interface is reviewed, commented upon, improved, and reviewed again in a repeating cycle. No one creates a perfect design the first time. This iterative cycle allows you to gradually improve the user interface. These cycles can be completed more quickly if the prototype is easily changed.
• Using domain experts – Ideally, the prototype should be built by a domain expert. Domain experts are familiar with the user – his or her job, expectations, requirements, jargon, and priorities. These people may have done the user’s job in the past. Domain experts can do the best job of incorporating user requirements into the prototype. If your prototyping tool is too difficult for the domain expert to use, make sure that the domain expert works closely with the programmer.

Traditional Development Process versus Rapid Prototyping Process

The traditional process used to develop a product follows the general steps shown in Figure 1. During Step 1, “Analyze Proposed System,” marketing and planning identify a customer need and determine whether the company can develop a product that will profitably meet that need. In Step 2, “Specify Requirements,” marketing and planning draft general requirements for the proposed product. In Step 3, “Design System,” development writes detailed specifications for the proposed product. In Step 4, “Develop System,” development creates the product. In Step 5, “Release Product,” the company releases the product.

Figure 1. Traditional and Rapid Prototyping Product Development Processes

There are two obvious differences between the traditional product development process and the rapid prototyping process shown in Figure 1. These differences are customer involvement and iterative design. Customers are involved only indirectly at the beginning of the traditional process, when marketing and planning specify requirements. In rapid prototyping, customers are involved directly throughout the development process. Also, the traditional process goes from requirements, to design, to development in a fixed series of steps. In rapid prototyping, the process is iterative. This makes it easier to change or add requirements that will make the product more popular with customers.

Performing Rapid Prototyping

Before you begin rapid prototyping, you should select a rapid prototyping tool and form a rapid prototyping team.

Select a Tool

To prototype successfully, first select an appropriate rapid prototyping tool. There are hundreds of rapid prototyping tools available. They range from simple graphics packages that allow you to draw screens to complex systems that allow you to create animation. Each tool is better for some functions than for others. There is no one, perfect rapid prototyping tool. Identify your prototyping needs, then find the tool that most closely meets those needs. You can learn about different prototyping tools by consulting computer magazines, technical reports, and books that describe prototyping tools (see Appendix A, “Sources of Information on Prototyping Tools”).

Form a Team

Another way to help make your rapid prototyping effort successful is to form a rapid prototyping team. The team should include a domain expert, an information developer, a marketer or planner, a programmer, and a usability representative. Their variety of skills allows the members of the small team to quickly and efficiently prototype a user interface that meets customer needs and development constraints. For example, the marketer can ensure that the proposed product has the features the customers want, and the programmer can ensure that the features will work with the proposed product architecture.

Rapid Prototyping Process

After you select a tool and form a team, you can begin the rapid prototyping process. Figure 1 shows suggested steps for developing a product with the rapid prototyping process.

• Analyze proposed system – First, marketing and planning identify a customer need and determine whether the company can develop a product that will profitably meet the need.
• Identify initial customer requirements – Marketing and planning identify general requirements for the product.
• Identify objects and actions – Next, your prototyping team identifies specific objects (nouns) and actions (verbs) to be used in the product. For example, the product could have “memo” as an object and “print” as an action. Specifying objects and actions help you design your screens to be compliant with the object-action syntax in IBM’s Common User Access guidelines. To perform this step, your team refines the initial, general requirements into specific objects and actions. Your team can also add other objects and actions that are needed.
• Put together related objects and actions – After the team has identified most of the application objects and actions, the next step is to organize the objects and actions in a logical, easy-to-understand way. Based on their knowledge of the customer, your team members can group related objects on panels and related actions on action bar pull-downs. One helpful way to do this grouping is to mimic a concept with which customers are already familiar. For example, IBM’s OfficeVision product organizes objects and actions by using in-baskets, out-baskets, a telephone, and other concepts familiar to office workers.
• Prototype panels – In this step, your prototyping team works together to prototype a portion of the proposed application user interface. Ideas are discussed, prototyped, commented on, improved, and prototyped again in quick, informal steps.
• Get feedback – Once your prototyping team is reasonably satisfied with the prototype, show it to other domain experts, information developers, marketers, planners, usability representatives or anyone else who has knowledge and interest in the product. Eventually, you can show the prototype screens to current or future customers. You can do this through informal walkthroughs or more formal usability tests. This feedback will generate additional requirements that were not identified in the initial requirements.
• Improve prototype – Use the feedback to improve the prototype. The feedback may trigger new ideas among the prototyping team. Make those changes that are best for the customer and that can reasonably be done.
• Iterate – Repeat the “prototype-feedback-improve prototype” cycle as quickly and as frequently as you can. Keep iterating until customers are delighted with your prototype user interface. The customers’ evaluations can be measured with questionnaires. To most customers, the user interface is the product. If customers are delighted with your prototype user interface, they are likely to be delighted with the product. When customers are delighted with one portion of the proposed application user interface, go on to another portion.
• Convert prototype code to actual code – The next step is to ask product programmers to code the prototype user interface. During this step, they build the actual product. The prototype serves as the product functional specification.
• Get feedback – Since the actual code includes elements of the user interface that you did not prototype, get feedback again. Use informal customer walkthroughs and formal usability tests to get this feedback.
• Improve actual code – Based on the customer feedback, the programmers refine the code to make the product easier to learn and use.
• Iterate – Repeat the “actual code-feedback-improve actual code” cycle as quickly and as frequently as you can. Remember, good software is easy to use and hard to design.
• Release the product – Finally, when customers are delighted with the actual user interface, release the product.

Compared to the traditional process of product development, rapid prototyping produces realistic screens earlier in the design process, puts more emphasis on the customer throughout the development process, and allows designers to make changes more quickly and easily.

Rapid Prototyping Pros and Cons

Rapid prototyping has some clear advantages and disadvantages. These are described below.

Advantages of Rapid Prototyping

Rapid prototyping has many advantages over the traditional process used to develop a product, including those describe below.

• Saves time and money – Rapid prototyping encourages creating a detailed design at the beginning of a product’s development. This early design work can lead to a more usable product in a shorter period of time. In fact, one study (1) found that development teams that prototyped produced systems that were easier to learn than development teams that did not prototype. Teams that prototyped got these results using 45% less effort and 40% less code. A complex system can be prototyped successfully for less than 10% of the total software development cost (2).
• Promotes consistency in user interface design – Since rapid prototyping produces screens that are easy for your team to review and copy, you can establish screen design conventions. The conventions allow the team to produce screens that are consistent, thereby reducing the amount of code that has to be rewritten during prototyping and coding.

• Allows early customer involvement – Rapid prototyping allows customers to see and use realistic screens early in product design, when changes can be made quickly and cheaply. You can conduct walkthroughs and usability tests with the prototype, then use this customer feedback in revising the prototype to better match customer requirements and preferences. A study (3) found that users of a prototyped system evaluated it more favorably and were more satisfied with it than users of the same system developed in the traditional way.
• Changes perceived ownership to customers – As customers see their design suggestions incorporated quickly into the prototype, they come to think of it as “their” product. Customers can begin to believe that they are designing a product to meet their unique needs, with IBM simply facilitating the process. Customers take pride in the prototype and try to make is as useful as possible. This pride of ownership results in a product that closely matches customer needs.
• Shows progress to management in a concrete way – Seeing is believing. Instead of telling management how many KSLOCs (thousand software lines of code) you’ve finished, management can see your progress as you build and refine the prototype. This visible process builds your credibility and provides a direct, easy-to-understand way to demonstrate progress.
• Allows marketers and planners to ensure that customer needs are met – By reviewing your prototype, these team members can get an early understanding of the product’s functions and user interface and can suggest improvements that meet customer needs.
• Allows domain experts, information developers, and usability representatives to get involved earlier – Rapid prototyping allows domain experts, information developers, and usability representatives to become an integral part of the design team. Instead of waiting for the code to be finished, they can work side-by-side with development to produce a user interface (screens, screen flow, help, and documentation) that is simple, consistent, and easy-to-use.
• Reduces the time required to create a product functional specification – Instead of writing a long and detailed specification that describes the proposed screens and navigation of your product, show the screens and navigation by using the prototype as the product functional specification. Using the prototype will save you significant documentation time and will be a much easier way for people to understand your proposed product.

Disadvantages of Rapid Prototyping

Rapid prototyping also poses some special challenges that are usually worth overcoming. Some of the disadvantages of rapid prototyping are described below.

• Has poor tools – Rapid prototyping is just now becoming a standard step in the design of complex systems. At the same time, user interfaces are becoming increasingly difficult to program (e.g., IBM’s Presentation Manager-based Advanced Common User Access). Although rapid prototyping tools are most needed for these new user interfaces, the very fact that they are new and difficult to program means that the user interfaces are evolving faster than the tools to help build them. Simply put, rapid prototyping tools have not been able to keep up with the user interfaces. As a result, we often end up with a tool that can reproduce the function that we want (e.g., dragging an icon) but is very difficult to use.
  
  To reduce the risk of using a poor prototyping tool, carefully evaluate a variety of candidate tools and select the one that best meets your needs. Your needs can include specific functions, operating systems, programming languages, and ease of use. If no tool meets your needs, consider compromising on your needs to more closely match the available prototyping tools. It is more important to be able to change your prototype quickly and easily than it is to simulate every feature of the proposed product.
• Sometimes encourages prototyping by programmers rather than domain experts – Since current rapid prototyping tools are difficult to use, programmers often end up being the people who operate them. This can be a disadvantage since those most familiar with the customer – domain experts, information developers, marketers, planners, and usability representatives – should prototype the user interface. You can reduce this potential problem by having your prototyping team work together closely. The team members who are most familiar with the customers can help the programmer by adding value, such as by using terms with which the customer is familiar and by prioritizing the actions which appear in a pull-down menu.
• Usually does not produce reusable code – Prototyping tools can be lumped into two groups. Tools in the first group let you prototype user interfaces quickly, but don’t produce reusable code. Tools in the second group let you produce reusable code, but create prototype user interfaces that are difficult to revise. The two kinds of tools are useful for different, mutually exclusive purposes. You are most likely to benefit from the tools that let you prototype quickly. These tools are more likely to reflect customer requirements, priorities, and preferences. The sacrifice of reusable code for customer satisfaction is generally worthwhile.
• Slows development process if put under formal configuration control – Prototyping is a very dynamic, informal process. You want to encourage people to give you as much feedback as possible. An offhand comment can help you to make your product even better. One sure way to keep people from giving you feedback is to require them to write Design Change Requests for each suggestion. Instead, ask people for their verbal suggestions and write them down. Then allow your prototyping team to discuss the suggestions. When the team has trouble deciding between two mutually exclusive suggestions, prototype both of them and show them to prospective customers. Let customers decide which option is better.
• Lacks an obvious stopping point – A dedicated prototyping team always feels that their prototype can be improved a little more. Encourage this pride, but keep in mind that you want to build and sell a real product. You an always impose an artificial stopping point based on schedule or cost. A better stopping point might be Customer Delight. Don’t satisfy customers. Delight them. Delighted customers tell other customers about your product and are more likely to buy other products from your company. To attain Customer Delight, improve your prototype quickly and iteratively until walkthroughs and usability tests show that prospective customers are delighted with it.

Summary

Rapid prototyping helps you build the product right the first time and puts design emphasis on meeting customer needs. It can save time and money, and improve the usability of your product. To prototype successfully, be sure to:

• Pick a prototyping tool that meets your needs.
• Form a small, diverse prototyping team.
• Get lots of customer feedback.
• Iterate until customers are delighted with your prototype user interface.

References

1. Boehm, B. W., Gray, T. E., and Seewaldt, T. (1984). Prototyping versus specifying: A multiproject experiment. IEEE Transactions on Software Engineering, 10, 3, 290-303.
2. Gomaa, H., and Scott, D. B. (1981). Prototyping as a tool in the specification of user requirements. In Proceedings of the 5^th International Conference on Software Engineering (pp. 333-339). New York: Association for Computing Machinery/Institute of Electrical and Electronics Engineers.
3. Alavi, M. (1984). An assessment of the prototyping approach to information systems development. Communications of the ACM, 27, 6, 556-563.

Appendix A. Sources of Information on Prototyping Tools

• Bernstein, K., Crossley, J., and Murray, K. (1988, June). Draft PWS CUA user interface tool review. Atlanta: IBM Corporation. Note: This report is IBM-Confidential. IBM employees may get a copy by contacting the authors.
• Cuomo, D. L., and Mosier, J. N. (1989, September). Choosing a user interface prototyping tool for the Macintosh or IBM PC (M89-57). Bedford, Massachusetts: MITRE Corporation.
• Ellenbogen, E., and Freeman, B. (1988, December). User interface prototyping tools (UICC-TOOLS-001). Gaithersburg, Maryland: IBM Corporation. Note: This report is IBM-Confidential. IBM employees may get a copy by contacting the authors.
• Ellenbogen, E., Freeman, B., Lewis, J., and Phillips, F. (1989, November). User interface prototyping and development tools (UICC-TOOLS-002). Gaithersburg, Maryland: IBM Corporation. Note: This report is IBM-Confidential. IBM employees may get a copy by contacting the authors.
• Murray, K. (1990, January). Tools for CUA User Interfaces under Presentation Manager. Atlanta SD Lab Newsletter Special Edition: Exploring usability and the user interface. 12-13. Note: This report is IBM-Internal Use Only. IBM employees may get a copy by contacting the author.
• PC WEEK. P.O. Box 5970, Cherry Hill, NJ 08034, telephone (609) 428-5000. Includes advertisements and occasional reviews of graphics and prototyping tools.
• Pfauth, M., Hammer, A., and Fissel J. (1985). Software prototyping as a human factors tool. In Proceedings of the Human Factors Society 29^th Annual Meeting (pp. 467-469). Santa Monica, CA: Human Factors Society.
• Schwalm, R. C., Thomas, M. E., White, R. J., and Williams, R. D. (1987). User interface prototyping: A review of PC-based tools and their features. In Proceedings of the Human Factors Society 31^st Annual Meeting (pp. 1082-1086). Santa Monica, CA Human Factors Society.
• Tullis, T. S. (1988, October). A survey of user interface design and development tools for the IBM PC and Apple Macintosh. Torrance, California: Ashton-Tate.