Paper Prototyping And Software Prototyping

‘Much good design evolves: the design is tested, problem areas are discovered and modified, and then it is continually retested and remodified until time, energy, and resources run out’. (Norman 1998:142)

That is to say that there are cycles of design, evaluation and redesign involving users throughout. For effective evaluation of the interface, the designer must develop an interactive version of the product. This allows stakeholders to ‘interact with an envisioned product, to gain some experience of using it in a realistic setting, and to explore imagined uses’. (Preece et al. 2002:241) Furthermore, this allows the designer the opportunity to test the design and through analysis of the results the product can be improved and retested.

A paper prototype may be chosen during the early stages of design as it can ‘save a great deal of time, effort and money by enabling different ideas to be shown and user tested before a particular approach is settled upon’. (Lindgaard 1994:93) A paper prototype is known as a ‘low-fidelity prototype’ (LFP), which resembles the final product but shares few characteristics with it. For example, a final product would be fully functional and displayed on a computer screen whereas paper is used here. LFPs have several advantages in that they are inexpensive, simple and can be produced quickly. The designer can rapidly modify the prototype and alternative designs and ideas can be easily explored. (Preece et al. 2002:243) Furthermore, a paper prototype can be used in isolation, as it is not dependent on a computer. A disadvantage is that more explanation and guidance from the designer is required to direct the user during evaluation. Further disadvantages are that there is limited error checking, restricted illustration of navigation and flow and limited usefulness for usability testing. (ibid. 2002:246)

Another example of a LFP is a storyboard. This is a ‘series of sketches showing how a user might progress through a task using the device being developed’. (Preece et al. 2002:243) A storyboard summarises the function of each screen and illustrates the hierarchical relationships by showing how the screens are interconnected and thereby allows the user to observe how a task might be performed. In a similar way, a flowchart facilitates illustration of the structure of the design. In conjunction with a paper prototype, a storyboard and flowchart give the user a better idea of the overall manner in which a proposed system functions. Users tested with a paper prototype may find both the storyboard and flowchart useful in this respect.

Evaluation of a paper prototype, can lead to its redesign, re-evaluation and design of a software prototype.

A computer-based prototype can be described as a ‘high-fidelity prototype’, which corresponds closely with the envisaged final product. (Preece et al. 2002:245) That is to say that it looks similar and has some elements of the proposed functionality.

The main reason for the development of a software prototype is that the user can acquire a greater understanding of how the final product will function and the way it will ‘look and feel’. During evaluation, this leads to more realistic and therefore superior feedback, which, in turn, can lead to better-informed modifications. Disadvantages are that a software design is time consuming, expensive and a computer is necessary to perform tests. Furthermore, there may be a reluctance to change elements of the design that the designer has invested many hours developing. (Preece et al. 2002:246) However, a software prototype can ameliorate some of the problems associated with a paper prototype and allow more fruitful evaluation of the subtleties of the interface.