In the first part of this article we discussed the difference between functional and user interface prototypes. In this one we’ll discuss whether your prototype should have a role beyond the discovery and design phase.
People often talk about “Throwaway Prototypes” versus “Evolutionary Prototypes” and it’s very important to understand the difference and exactly what type you are creating before you begin.
A Throwaway Prototype, as the name suggests, forms no part of the final application. Its purpose is to prove (or disprove) a design and get approval for actual implementation.
It can be produced using any quick and dirty technique and the quality can even be quite poor, so long as it satisfies the requirements of identifying what’s right about a design, what’s wrong and what’s missing.
Because of the speed at which Throwaway Prototypes can be put together and changed (usually on-the-fly), they encourage feedback and continual revision until the design is about right.
Because the effort required to produce them is relatively small, there’s less ‘attachment’ to a design and therefore very little reluctance to change. However, you do need to be careful that you don’t end up in an endless cycle of analysis and revision without making any development progress at all!
In contrast, Evolutionary Prototypes are intended, right from the start, to eventually evolve into the final, delivered application (or system) through incremental developments and changes. In one sense, this seems like a great idea because each increment is getting you closer to a delivery and progress is clearly being made.
However, there are many risks involved in this approach. Because it involves implementation of the system itself, the coding has to be of production quality from the start. The idea of ‘cleaning it up later’ is a very bad one since this will never happen in practice, leading to potential problems and instability later on. But this conflicts with one of the key benefits of being able to create prototypes quickly. Also, because of the effort that’s gone into it, there can become too much attachment to the implementation which leads to a resistance to change.
Not only that, it’s very difficult to see the ‘bigger picture’ with an evolutionary prototype because you can only see, and therefore review, the parts that have been implemented and it’s very difficult to compare different versions or approaches to a given design.
There’s another potential problem with evolutionary prototypes. Sometimes you’ll already know what technology you’ll be using but sometimes you will be free to choose what’s best for the application. By creating an evolutionary prototype you will be committing to an implementation too early when a more suitable technology or component set might become apparent later on once the requirements of the application are better understood.
In the last part of this article we’ll discuss different methods and tools for generating prototypes.