Reference: Sharp, H., Rogers, Y., & Preece, J. (2007). Interaction design : beyond human-computer interaction (p. 464-521). Wiley.
A prototype is a model or representation of a product whether it is physical or electronic that “simulates the scenario of use.”(Sharp, Rogers, & Preece, 2007) A prototype allows prospective users to envision what it would be like to use the real product. Prototypes are highly supported and encouraged in the design process with researchers like Liddle (1996) recommending that it precede any writing of coding.
Prototypes serve many purposes which include:
- To test out the technical feasibility of an idea
- To clarify some vague requirements
- To do some user testing and evaluation
- To check that a certain design direction is compatible with the rest of the system development.
(Sharp et al., 2007)
Prototypes usually come in two forms: low-fidelity and hi-fidelity with the latter posing risks for both users and developers. Low-fidelity prototypes are obvious models of the real product because they are usually made with a different material from the final product and the functions don’t work. Someone would obviously realize that a real tablet device is not made of paper or plastic. The danger comes when the device is operational and the customer can interact with it. In this case they may tend to think that prototype is the final device and may develop wrong impressions of it. Also developers may be tempted to use these prototypes by simply adding a few more functions especially if time is against them.
Low fidelity prototypes are intended to be thrown away and this is perfectly understandable. Why would anyone decide to keep such a prototype unless they want a souvenir? On the other hand I would be less inclined to throw away a hi-fidelity prototype, in spite of the dangers associated with it. From the view point of a programmer, too much work and effort have been place in the prototype to throw it all away and start again from scratch. In addition enough information would have been collected to know which parts of the prototype had high quality usability and which functions had to be revamped. If this is done properly, then I think that a highly usable product can be produced from that prototype.
The authors also made a valid point that I tend to agree with. Due to the fast development cycle of products today it makes more sense to have a “good enough” product on the market than having high quality product released two months after your competitors. Do what Microsoft does, release a “somewhat good product” then later release updates and fixes.