Both evolutionary and throwaway prototypes are evolved in response to changes in the feature set or user-interface design. You'll generally want to keep the prototype flexible so that you can refine it in response to user feedback. Once you've explored the system's functionality with the users, the prototype can serve as a live requirements specification for the visible aspects of the program.

At some point, you begin building the real system, and at that point you either throw away the user-interface prototype and begin building the real system or you begin evolving the user-interface prototype into production code. The first decision you make with User-Interface Prototyping is whether to build a throwaway prototype or one that you will eventually evolve into production code—an evolutionary prototype. You need to make that decision at the time that you begin building the prototype, not the time that you begin building the real system.

One rule of thumb is: If you know a lot about requirements and have had relatively few conflicts about priorities and trade-offs, use the Evolutionary Prototyping approach. Otherwise there will be too many changes, in which case you should use the Throwaway Prototyping approach to explore requirements and user-interface designs.

Another guideline is that, on small systems, Evolutionary Prototyping is preferable because the overhead of creating a throwaway prototype makes it economically undesirable. On medium and large systems, you can use either Throwaway Prototyping or Evolutionary Prototyping successfully.

You can also prototype the main system using Evolutionary Prototyping and prototype the riskiest parts with Throwaway Prototyping before beginning full-scale development of those parts.

If you plan to throw away the user-interface prototype, you might decide to use a special-purpose prototyping language. The main consideration in choosing a language in this case is how quickly you can develop the user interface. You don't even have to use a prototyping language. One company made screen shots of the product's screens, blew them up to giant size, and posted them on the walls of a conference room. Then they held an "art show," and had people walk through the "art gallery" and write their comments directly on the screen shots. When you use screen shots like this, they end up being covered with comments. People can proceed at their own pace, come and go according to their own schedules, respond to other written comments. This can be a useful practice.

If you plan to evolve the user-interface prototype into the final system, the most important consideration in choosing a language is determining how well the prototyping language supports the entire growth envelope of the system. Some user-interface–oriented languages offer strong support for user-interface development but weaker support for development of database, graphics, communications, report formatting, and other program areas, which can consume at least as much time as developing the user interface does. Choose a language based on its support for end-to-end product development, not just support for the user interface.

Another key to success is remembering that you are prototyping, not developing the real system. All your prototyping work stands a chance of being thrown away if your users don't like it. Until you know for sure whether any part of the system is in or out, try to put 100 percent of your effort into the visible parts of the system. Don't spend time on parts the user can't see. Treat the prototype as a Hollywood movie facade—it looks real from certain angles, but aside from its looks, it's nothing like the real thing.

The more smoke and mirrors, the better. If the prototype is supposed to display color graphics, don't implement color graphics support in code even if it's relatively easy to do so. Instead, try to find an even easier way to display prebuilt color graphics. Create the graphics using an off-the-shelf drawing program, and load each prebuilt graphic at the appropriate time. The prototype should provide end-users with the look and feel of the program. It doesn't actually have to work. If it does work, you've probably spent more time than you needed to.

Calculations don't have to calculate: Simply show the same results every time, or switch back and forth between two sets of results. Reformatting doesn't have to reformat anything; simply swap one canned screen shot for another. The Print button doesn't have to perform printing; simply copy a preexisting print file to the printer. Data conversion from the old version of the product doesn't have to convert data; simply put up the wait cursor and then display predefined output. Have your group brainstorm about creative ways to provide the desired look and feel while writing the least amount of code possible.

Keep entry-level programmers away from prototyping. During prototyping, developers need to have a well-developed sense of how little they can do to explore the areas of risk that the prototype is intended to explore.

Although User-Interface Prototyping usually improves software usability, that doesn't necessarily translate into improved user satisfaction. Inappropriate kinds of user involvement sometimes worsen user satisfaction.

You must involve end-users. You won't realize the benefits of prototyping if only developers and middle management are involved. Let the users test-drive the user-interface prototype. This will clarify the requirements, help to reveal the actual requirements of the program, improve the match between the software and the users' needs, and improve the product's overall usability.

Control access to the prototype. Unrealistically high user expectations are usually fueled by too much or too little access to the prototype. Tell the users that the purpose of showing them the prototype is to clarify the requirements. You might want to limit their use of the prototype to a demonstration of certain sequences of screen shots and operations, using the prototype more as a visual aid than as an interactive software program.

Be aware that customers don't always know what they're looking at when they see a prototype. I once developed a prototype for an analytical application in Microsoft Windows that generated graphical outputs. In the prototype, I used canned graphics so that no matter what numbers the user input, the same canned graphic would always appear. Since the canned graphics could be generated instantly, I put in a 2-second delay to create the impression that the prototype was doing the database access and number crunching that the real application would have to do.

Even with the 2-second delay, users were delighted at how quickly the prototype generated its graphics. The first time I demonstrated the prototype, several users argued with each other about why the Windows prototype was so much faster than the Microsoft MS-DOS product it was replacing. One user argued that it was because Windows graphics were faster than DOS graphics. Another argued that it was because the prototype must have had only a miniature database instead of the full-scale database. Another argued that it was because the new program was using a different math library than the old program. It didn't seem to occur to anyone that the prototype was truly just smoke and mirrors, that nothing was really going on behind the scenes, and that the graphics were actually taking longer to generate than they should have taken.

If you do a good job of prototyping the look and feel of your product, your users are likely to be overwhelmed by a live software demonstration. They will be so impressed that they won't think about whether the prototype includes all the functionality they want. If you're using the prototype to elicit user requirements, be sure that users study the prototype carefully enough to criticize it. Explain some of the design trade-offs you've made, and be sure that they understand the trade-offs and agree to them. Develop a checklist so that you can conduct a structured interview with users who use the prototype. Be sure that they look at everything you want them to look at.

Once you do get meaningful feedback from your users, evolve the prototype enough to confirm that you understand what they told you. One of the most effective ways of showing that you have heard and understood their comments is to show them an updated prototype that accounts for their feedback. In addition to building good relations with users, this helps to catch any miscommunications; it gives the user a chance to say, "No, that's not what I meant."

Creating a Hollywood facade is a great prototyping strategy, but a product can't live on smoke and mirrors forever. At some point you have to decide how to move from the prototype to the finished product. At that point you have three options:

You can also use different approaches for the user interface and the rest of the system. It's possible to prototype the user interface but develop the rest of the system using a traditional approach.