Prototypes answer questions.
So prototype appropriately.
A prototype can be a lump of wood, a slide show, a paper sketch or working software. What matters is which question it is being built to answer - and what compromise you accepted to build it that quickly.
LEARNING OUTCOMES
- Describe prototyping and different types of prototyping activity.
- Produce a simple prototype from the models developed during the requirements activity.
- Explain conceptual design and its steps from requirements to design.
- Evaluate an interface metaphor against the five stated criteria.
- Generate storyboards from scenarios and card-based prototypes from use cases.
A prototype is anything users can react to
In other design fields a prototype is a small-scale model - a miniature car, a miniature building, a 3D-printed part. In interaction design it can be many other things.
- A series of screen sketches.
- A storyboard - a cartoon-like series of scenes.
- A PowerPoint slide show.
- A video simulating the use of a system.
- A lump of wood - the PalmPilot is the famous case.
- A cardboard mock-up.
- A piece of software with limited functionality, written in the target language or in another language.
| Why prototype? | What it buys you |
|---|---|
| Evaluation and feedback are central to interaction design. | A prototype is the object those activities act on. |
| Stakeholders can see, hold and interact with a prototype. | Far easier than reacting to a document or a drawing. |
| Team members can communicate effectively. | A shared concrete referent instead of competing mental models. |
| You can test out ideas for yourself. | Cheap disproof before expensive commitment. |
| It encourages reflection. | A very important aspect of design. |
| Prototypes answer questions. | And support designers in choosing between alternatives. |
What to prototype: technical issues; work flow and task design; screen layouts and information display; and difficult, controversial or critical areas. Prototyping is also described along filtering and manifestation dimensions - which aspects of the design the prototype keeps, and in what form it appears.
The single most useful sentence in this deck: "Prototypes answer questions, so prototype appropriately." Every choice below - fidelity, horizontal or vertical, paper or code - follows from asking which question you are trying to answer.
Unlike the final medium, on purpose
A low-fidelity prototype uses a medium which is unlike the final medium - paper, cardboard. It is quick, cheap and easily changed.
a. Storyboards
Often used with scenarios, bringing more detail and a chance to role play. A series of sketches showing how a user might progress through a task using the device. Used early in design.
b. Sketching
Important to low-fidelity prototyping. Don't be inhibited about drawing ability - practise simple symbols. The point is the idea, not the draughtsmanship.
c. Card-based
Index cards (3 x 5 inches), each representing one screen or part of a screen. Often used in website development, and generated from use cases.
The deck states two direct mappings you should be able to reproduce: storyboards are generated from scenarios, and card-based prototypes are generated from use cases. Narrative → storyboard; step sequence → cards.
Materials you expect in the final product
A high-fidelity prototype uses materials you would expect to be in the final product, and looks more like the final system than a low-fidelity version.
- Common software-prototyping environments named in the deck: Macromedia Director, Visual Basic, Smalltalk.
- Danger: users think they have a full system.
Wizard of Oz
The user thinks they are interacting with a computer, but a developer is responding to output rather than the system. Usually done early in design to understand users' expectations. The lecture asks what is 'wrong' with this approach - the answer is that it tests the interaction concept while proving nothing about feasibility, and it depends on a human able to respond as no real system yet can.
| Compromise type | What it provides |
|---|---|
| Horizontal | A wide range of functions, but with little detail. |
| Vertical | A lot of detail for only a few functions. |
All prototypes involve compromises - a slow response, sketchy icons, limited functionality. And: compromises in prototypes must not be ignored. The product needs engineering. A prototype that quietly becomes the product ships every compromise with it.
Horizontal is wide and shallow; vertical is narrow and deep. Picture the letter: the horizontal bar stretches across everything, the vertical bar drills down through one spot.
Taking the prototypes and creating a whole
Construction means taking the prototypes - or learning from them - and creating a whole. Quality must be attended to.
- Usability - of course.
- Reliability.
- Robustness.
- Maintainability.
- Integrity.
- Portability.
- Efficiency.
Physical computing is the hardware side of construction: building and coding prototypes using electronics. The toolkits named are Arduino, LilyPad (for fabrics), Senseboard and MaKey MaKey. All are designed for use by a wide range of people, not only engineers.
Construction qualities: U-R-R-M-I-P-E. The first is usability and the rest are the software-engineering qualities you already know - the point of the list is that usability sits among them, not after them.
From requirements to design
Conceptual design transforms user requirements and needs into a conceptual model - the first step of design.
A conceptual model is "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."
- A mood board may be used to capture the intended feel.
- Don't move to a solution too quickly. Iterate, iterate, iterate.
- Which metaphors would be suitable to help users understand the product?
- Which interaction type(s) would best support the users' activities?
- Do different interface types suggest alternative design insights or options?
- Understand the functionalityStep 1 of finding a metaphor.
- Identify potential problem areasStep 2.
- Generate metaphorsStep 3.
| Evaluating a metaphor - five questions | What it probes |
|---|---|
| How much structure does it provide? | A thin metaphor explains nothing. |
| How much is relevant to the problem? | Borrowed structure that does not apply becomes misleading. |
| Is it easy to represent? | If it cannot be drawn or built, it cannot be shown at the interface. |
| Will the audience understand it? | A metaphor is only familiar knowledge if the audience has it. |
| How extensible is it? | Will it still work when the product grows? |
Expanding the initial conceptual model asks three groups of question. What functions will the product perform - and what will the product do versus what will the human do (task allocation)? How are the functions related - sequential or parallel, and how are they categorised, such as all actions related to privacy on a smartphone? What information is needed - what data is required to perform the task, and how is that data to be transformed by the system?
Concrete design
The many detailed aspects: colour, icons, buttons, interaction devices. It must account for user characteristics and context - accessibility and cross-cultural design - and follow cultural website guidelines. The quotation to remember: successful products "are ... bundles of social solutions. Inventors succeed in a particular culture because they understand the values, institutional arrangements, and economic notions of that culture."
Expressing proposed or imagined situations
Scenarios return here, but doing a different job than in requirements.
- Used as scripts for user evaluation of prototypes.
- Used as concrete examples of tasks.
- Used as a means of co-operation across professional boundaries.
- Plus and minus scenarios explore extreme cases - the best and worst that could happen.
Scenario → storyboard. Use case → card-based prototype. Both appear as worked examples in the deck, and both are the kind of thing an exam asks you to demonstrate rather than define.
A scenario is a story, so it becomes a picture strip (storyboard). A use case is a numbered sequence, so it becomes a stack of numbered cards. The artifact keeps the shape of its source.
Mistakes students usually make
Each claim below is the wrong answer; the line beneath it is the correction, in the wording this course marks against.
Shortest correct answers
The night-before table: every term in this lecture with the smallest answer that still earns the mark.
| Concept | Shortest correct answer |
|---|---|
| Prototype | Anything from screen sketches, a storyboard, a slide show, a video, a lump of wood or a cardboard mock-up to limited-functionality software. |
| Why prototype | Prototypes answer questions, support choosing between alternatives, enable stakeholder feedback, aid team communication and encourage reflection. |
| What to prototype | Technical issues; work flow and task design; screen layouts and information display; difficult, controversial or critical areas. |
| Low fidelity | Uses a medium unlike the final one - paper, cardboard. Quick, cheap, easily changed. |
| Low-fi forms | Storyboards, sketching, card-based prototypes. |
| Storyboard | A series of sketches showing how a user might progress through a task; used early, often with scenarios. |
| High fidelity | Uses materials expected in the final product; danger that users think they have a full system. |
| Wizard of Oz | The user thinks they interact with a computer, but a developer produces the responses; used early to understand expectations. |
| Horizontal prototype | Wide range of functions with little detail. |
| Vertical prototype | A lot of detail for only a few functions. |
| Construction qualities | Usability, reliability, robustness, maintainability, integrity, portability, efficiency. |
| Physical computing kits | Arduino, LilyPad (fabrics), Senseboard, MaKey MaKey. |
| Conceptual model | A description of the proposed system as integrated ideas and concepts about what it should do, behave and look like, understandable by users. |
| Metaphor evaluation | Structure, relevance, ease of representation, audience understanding, extensibility. |
| Task allocation | Deciding what the product will do and what the human will do. |
| Concrete design | Colour, icons, buttons, interaction devices, plus accessibility and cross-cultural design. |
Exam-style application
Write your own answer first, then open the model answer. These are the longer-form questions this material generates.
You have one week to decide between three navigation concepts for a banking app. Choose a prototyping strategy and justify every choice.
Evaluate a 'filing cabinet' metaphor for a cloud storage product against the five criteria.
Explain why a successful prototype is not a product, using the lecture's own vocabulary.
Check yourself
6 questions. Every option is explained after submitting, including why the wrong ones are wrong.