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.
Mark Chambers is a freelance web designer specialising in web design for small to medium sized businesses.
http://www.markchambers.net