Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

34 Cards in this Set

  • Front
  • Back


- it can be anything from a paper-based storyboard through a complex piece of software and from a cardboard mock-up to a moulded or pressed piece of metal

- allows stakeholders to interact with an envisioned product, to gain some experience of using it in a realistic setting and to explore imagined uses

usefulness of prototype

- useful aid when discussing ideas with stakeholders

- communication devices among the team members

- an effective way to test out ideas

- answer questions and support designers in choosing between alternatives

low-fidelity prototyping

- does not look very much like the final product

- uses materials that are different from the intended final version

- paper and cardboard

-useful because they tend to be simple, cheap and quick to produce

- also simple and quick to modify


- low-fidelity prototyping

- often used in conjunction with scenarios

- consists a series of sketches showing how a user might process through a task using the product under development

- it can be a series of sketched screens or a series of scene sketches showing how the user can perform a task using the device

- brings more details to the written scenario

- offers stakeholders a chance to role-play with the prototype, interacting with it be stepping through the scenario


- don't have to be more than simple boxes, stick figures and stars

prototyping with index cards

- used quite commonly when developing websites

- each card represents one screen or one element of a task

- the user can step through the cards, pretending to perform the task while interacting with the cards

Wizard of Oz

- the user sits at a computer screen and interacts with the software an though interacting with the product

- the computer is connected to another machine where a human operator sits and simulates the software's response to the user

high-fidelity prototypes

- uses materials that you would expect to be the final product and produces a prototype that looks much more like the final thing

- tools Flash, Visual Basic and SmallTalks

problems with high-fidelity prototyping (Mark Rettig 1994)

- take too long to build

- reviewers and testers tend to comment on specifical aspects rather than content

- developers are reluctant to change something they have crafted or hours

- a software prototype can set expectations too high

- just one bug can bring the testing to halt

compromises in prototyping

- compromises between breadthof functionality provided and depth

- these 2 kinds of prototyping:

- horizontal prototyping

- vertical prototyping

horizontal prototyping

providing a range of functions but with little detail

vertical prototyping

providing a lot of detail for only a few functions

2 different development philosophies

- evolutionary prototyping

- throwaway prototyping

evolutionary prototyping

evolving a prototype into the final product

throwaway prototyping

the prototypes are used as stepping stones towards the final design,

the prototypes are thrown away and the final product is built from scratch

conceptual design

- concerned with transforming needs and requirements into a conceptual model

- best to understood by exploring and experiencing different approaches to it

contextual design (Holtzblatt 1998)

holding review meetings within a team to get different people's point of view on the data gathered and what they observed

guiding principles of conceptual design:

- 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

interface metaphors

- combine familiar knowledge with new knowledge in a way that help the user understand the system

- choosing suitable metaphors and combining new and familiar concepts requires a careful balance between utility and fun, and is based on a sound understanding of the users and their context

process of choosing a good metaphor (Erickson 1990)

- understand what the system will do
- understand which bits of the systen are likely to cause users problems
- generate metaphors

questions to evaluate metaphors

- how much structure does the metaphor provide?

- how much of the metaphor is relevant to the problem?

- is the interface metaphor easy to represent?

- will your audience understand the metaphor?

- how existible is the metaphor?

interaction types

- the best suited to your design depends on the application domain and the kind of product being developed.

- most conceptual models will combine interaction types

interface types

-different interface types prompt and support different perspectives on the product under development and suggest different possible behaviours

what functions will the product perform?

- understanding the tasks the product will support is a fundamental aspect of developing the conceptual model, but it is also important to consider more specifically what functions the product will perform

task allocation

- deciding what the system will do and what must be left for the user

how are the functions related to each other?

functions may be related temporarily, they may also be related through any number of possible categorisations

- the relationships between tasks may constrain use or may indicate suitable task structures within the product

what information needs to be available?

- ensure that our model provides the information necessary to perform a task


- can be used to explicate existing work situations, but they are commonly used for expressing proposed or imagined situations to help in conceptual design

4 roles for scenarios (Boker)

- as a basisi for the overall design

- for technical implementation

- as a mean of cooperation within design teams

- as a means of cooperation across professional boundaries

plus and minus scenarios (Bodker)

capture the most positive and the most negative consequences of a particular proposed design solution thereby helping designers to gain a more comprehensive view of the proposal

genrating a storyboard from a scenario

- breaking the scenario into a series of step and creating one scene in the storyboard for each step

purpose of generating storyboard from scenario

- can be used to get feedback from users and colleagues

- prompt the design team to consider the scenario and the user of the system in more detail

generating card-based prototypes from use cases

screens or screen elements can be manipulated and moved around in order to simulate interaction.

prototyping physical design

- you can take one or more cards and translate them into a sketch that included more detail about input and output technology, icon usage, error messages, menu structures and any style conventions needed for consistency with other products

- it can be more sophisticated using post-it notes, masking tape, acetate sheets and various paper products that allow the prototype to be run by a person pretending to be the computer