8.2.4 High-Fidelity Prototyping

8.2 Prototyping and construction 245 I Drive car to gas pump Take nozzle from pump ... and put it ~ntothe car's gas tank Squeeze trigger on Replace nozzle Pay cash~er the nozzle until when tank is full tank is full Figure 8.4 A storyboard depicting how to fill a car with gas. Wizard of Oz Another low-fidelity prototyping method called Wizard of Oz assumes that you have a software-based prototype. In this technique, the user sits at a computer screen and interacts with the software as though interacting with the product. In fact, however, the computer is connected to another ma- chine where a human operator sits and simulates the software's response to the user. The method takes its name from the classic story of the little girl who is swept away in a storm and finds herself in the Land of Oz (Baum and Denslow, 1900). 8.2.4 High-fidelity prototyping High-fidelity prototyping uses materials that you would expect to be in the final product and produces a prototype that looks much more like the final thing. For example, a prototype of a software system developed in Visual Basic is higher fidelity than a paper-based mockup; a molded piece of plastic with a dummy key- board is a higher-fidelity prototype of the PalmPilot than the lump of wood. If you are to build a prototype in software, then clearly you need a software tool to support this. Common prototyping tools include Macromedia Director, Vi- sual Basic, and Smalltalk. These are also full-fledged development environments, so they are powerful tools, but building prototypes using them can also be very straightforward. 246 Chapter 8 Design, protowing and construction Table 8.1 Relative effectiveness of low- vs. high-fidelity prototypes (Rudd et al., 1996) Type Advantages Disadvantages Low-fidelity prototype Lower development cost. Limited error checking. Evaluate multiple design Poor detailed specification concepts. to code to. Useful communication device. Facilitator-driven. Address screen layout issues. Limited utility after 6 Useful for identifyingmarket requirements established. requirements. Limited usefulness for Proof-of-concept. usability tests. Navigational and flow limitations. High-fidelity prototype 6 Complete functionality. More expensive to develop. Fully interactive. Time-consuming to create. User-driven. Inefficient for proof-of- Clearly defines navigational concept designs. scheme. Not effective for Use for exploration and test. requirements gathering. Look and feel of final product. Serves as a living specification. Marketing and sales tool. Marc Rettig (1994) argues that more projects should use low-fidelity prototyping because of the inherent problems with high-fidelity prototyping. He identifies these problems as: They take too long to build. Reviewers and testers tend to comment on superficial aspects rather than content. Developers are reluctant to change something they have crafted for hours. A software prototype can set expectations too high. Just one bug in a high-fidelity prototype can bring the testing to a halt. High-fidelity prototyping is useful for selling ideas to people and for testing out technical issues. However, the use of paper prototyping and other ideas should be actively encouraged for exploring issues of content and structure. Further advantages and disadvantages of the two types of prototyping are listed in Table 8.1. 8.2.5 Compromises in protoiyping By their very nature, prototypes involve compromises: the intention is to produce something quickly to test an aspect of the product. The kind of questions or choices 8.2 Prototyping and construction 247 that any one prototype allows the designer to answer is therefore limited, and the prototype must be designed and built with the key issues in mind. In low-fidelity prototyping, it is fairly clear that compromises have been made. For example, with a paper-based prototype an obvious compromise is that the device doesn't actually work! For software-based prototyping, some of the compromises will still be fairly clear; for example, the response speed may be slow, or the exact icons may be sketchy, or only a limited amount of functionality may be available. Two common compromises that often must be traded against each other are breadth of functionality provided versus depth. These two kinds of prototyping 248 Chapter 8 Design, prototyping and construction I are called horizontal prototyping (providing a wide range of functions but with little detail) and vertical prototyping (providing a lot of detail for only a few functions). Other compromises won't be obvious to a user of the system. For example, the internal structure of the system may not have been carefully designed, and the prototype may contain "spaghetti code" or may be badly partitioned. One of the dan- gers of producing running prototypes, i.e., ones that users can interact with automatically, is that they may believe that the prototype is the system. The danger for developers is that it may lead them to consider fewer alternatives because they have found one that works and that the users like. However, the compromises made in order to produce the prototype must not be ignored, particularly the ones that are less obvious from the outside. We still must produce a good-quality system and good engineering principles must be adhered to. 8.2.6 Construction: from design to implementation When the design has been around the iteration cycle enough times to feel confi- dent that it fits requirements, everything that has been learned through the iter- ated steps of prototyping and evaluation must be integrated to produce the final product. Although prototypes will have undergone extensive user evaluation, they will not necessarily have been subjected to rigorous quality testing for other character- istics such as robustness and error-free operation. Constructing a product to be used by thousands or millions of people running on various platforms and under a wide range of circumstances requires a different testing regime than producing a quick prototype to answer specific questions. The dilemma box below discusses two different development philosophies. One approach, called evolutionary prototyping, involves evolving a prototype into the final product. An alternative approach, called throwaway prototyping, uses the prototypes as stepping stones towards the final design. In this case, the 8.3 Conceptual design: moving from requirements to first design 249 prototypes are thrown away and the final product is built from scratch. If an evolutionary prototyping approach is to be taken, the prototypes should be subjected to rigorous testing along the way; for throw-away prototyping such testing is not necessary. 8.3 Conceptual design: moving from requirements to first design Conceptual design is concerned with transforming the user requirements and needs into a conceptual model. Conceptual models were introduced in Chapter 2, and here we provide more detail and discuss how to go about developing one. We defined conceptual model as "a description of the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave, and look like, that will be understandable by the users in the manner intended." The basis for designing this model is the set of user tasks the product will support. There is no easy transformation to apply to a set of requirements data that will produce "the best" or even a "good enough" conceptual model. Steeping yourself in the data and trying to empathize with the users while considering the issues raised in this section is one of the best ways to proceed. From the requirements and this experience, a picture of what you want the users' experience to be when using the new product will emerge. 250 Chapter 8 Design, prototyping and construction I Beyer and Holtzblatt (1998), in their method Contextual Design discussed in Chapter 9, recommend holding review meetings within the team to get different peoples' perspectives on the data and what they observed. This helps to deepen understanding and to expose the whole team to different aspects. Ideas will emerge as this extended understanding of the requirements is established, and these can be tested against other data and scenarios, discussed with other design team members and prototyped for testing with users. Other ways to understand the users' experience are described in Box 8.2. Ideas for a conceptual model may emerge during data gathering, but remember what Suzanne Robertson said in her interview at the end of Chapter 7: you must separate the real requirements from solution ideas. Key guiding principles of conceptual design are: Keep an open mind but never forget the users and their context. Discuss ideas with other stakeholders as much as possible. Use low-fidelity prototyping to get rapid feedback. Iterate, iterate, and iterate. Remember Fudd's first law of creativity: "To get a good idea, get lots of ideas" (Rettig, 1994). Considering alternatives and repeatedly thinking about different perspectives helps to expand the solution space and can help prompt insights. Prototyping (introduced in Section 8.2) and scenarios (introduced in Chapter 7) are two techniques to help you explore ideas and make design decisions. But before explaining how these can help, we need to explore in more detail how to go about envisioning the product. 8.3.1 Three perspectives for developing a conceptual model Chapter 2 introduced three ways of thinking about a conceptual model: Which interaction mode would best support the users' activities? Is there a suitable interface metaphor to help users understand the product? Which interaction paradigm will the product follow? In this section, we discuss each of these in more detail. In all the discussions that follow, we are not suggesting that one way of approaching a conceptual design is right for one situation and wrong for another; they all provide different ways of thinking about the product and hence aid in generating alternatives.

Load more