Chapter 14 -- Prototype with Caution

Chapter 14

A user interface prototype is a mock-up interface that has selected functionality designed to demonstrate how a program is going to look and behave. Its purpose is to solve specific problems and to obtain early feedback from users and other team members. Prototyping allows you to get feedback more quickly and cost effectively than normal production software.

Software prototyping is at least in part a reaction to the classic "waterfall" software development lifecycle model, which goes from requirements to specification, to design, to implementation, to testing, and then to maintenance. The problem with this lifecycle model is that it is heavily weighted to the earlier phases in the development process. There is often no visible output until late in the implementation phase. If the output of this process is found to be unacceptable, the consequences are often disastrous. Prototyping is used to shorten this feedback loop so that users, customers, and other interested parties can determine early in the process whether the results are acceptable.

User interface prototypes exist in many forms, ranging from paper mock-ups to nearly fully functional user interfaces. But in all cases a prototype cannot be a real user interface. For a prototype to have any sort of cost or time advantage over the real user interface, it must have some significant functionality missing. While the basic user interface elements might be present, many of the details are not. If data is involved, the prototype data might not be real. Also, there might not be detailed features that help the user eliminate unnecessary effort, error messages, or advanced features. Furthermore, the prototype might not give a realistic indication of the actual performance.

I have to admit that I'm not a big fan of what is normally considered prototyping—that is, functional prototyping, or the creation of prototypes consisting of functional, working code. I've worked for two small start-up companies that went down the tubes, and I believe that improper functional prototyping was a major factor in the demise of each company. In both cases, what was supposed to be a prototype became the actual product. Both projects were disasters. Easily foreseeable disasters, in fact. In one case, management did realize that the prototype-based product was a serious problem, so they hit the reset button and started over. This would have been a good move, but by that time their capital (financial and otherwise) was pretty much gone. It was all spent on developing the prototype.

You can see that it's very important to have a realistic understanding of what prototyping can and cannot do. It's important to understand the potential hazards of prototyping and how to avoid them by setting proper, realistic objectives. Lastly, you need to understand that there are effective prototyping techniques that do not involve creating functional software. You should prefer these nonfunctional techniques whenever possible. Misguided prototyping can be dangerous, so be sure to prototype with caution.