Question 5 of 14: Prototyping — Fidelity, Scope and the Wizard of Oz Technique

Question 5: Prototyping — Fidelity, Scope and the Wizard of Oz Technique (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part A — what a prototype is, and why use one. A prototype is a partial, tangible representation of a design — ranging from a paper sketch to a fully interactive mock-up — that is concrete enough for stakeholders to interact with, react to, and evaluate before the real system is built. Two reasons for using prototypes: (1) they let designers elicit concrete, specific feedback from users and stakeholders who often cannot articulate requirements in the abstract but can readily critique something in front of them (a pharmacist may struggle to describe "what a good drug-library editor should feel like" but will immediately spot that a proposed screen buries a critical dose-limit field); (2) they allow cheap, early detection of design problems before expensive code is committed — a usability flaw caught in a paper prototype costs minutes to fix, the same flaw caught after full implementation costs a rebuild and, in a safety-relevant product like infusion-pump software, a compliance re-review.

Part B — fidelity and scope dimensions. Low-fidelity prototypes (paper sketches, index-card screens, wireframes) are quick and cheap to produce and to discard, use simple materials, deliberately look unfinished (so reviewers critique the concept, not the visual polish), and are best for exploring alternative concepts early. High-fidelity prototypes are interactive, closely resemble the final product in look, content and behaviour, take substantially longer to build, and are best for detailed usability testing and for stakeholder sign-off closer to release, since they let users perform close-to-real tasks and reveal interaction-level problems a sketch cannot. Horizontal prototypes implement a wide slice of functionality (most or all screens/features) but at shallow depth (little or no working logic underneath) — useful for reviewing overall structure, navigation and scope. Vertical prototypes implement a narrow slice (one or a few features/tasks) but in full depth, all the way to working logic — useful for validating that a specific, often technically risky, task (e.g. the drug-library upload-and-verify sequence) can actually be completed end to end.

Part C — Wizard of Oz. In the Wizard of Oz technique, a participant interacts with what appears to be a working system, but some or all of the system's "intelligent" responses are actually being produced in real time by a hidden human operator (the "wizard"), rather than by real functioning software. Advantage: it lets designers test the interaction design and gather realistic user reactions to complex or not-yet-built behaviour (e.g. how a pharmacist would react to an automated drug-interaction warning) without first having to implement that behaviour, which is far cheaper than building working intelligence just to find out whether users would even want it. Limitation: the wizard's responses may be faster, more consistent, or more forgiving of edge cases than any real implementation could achieve, so the technique can produce an overly optimistic picture of how the finished system will actually perform and be received.