Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
34 Cards in this Set
- Front
- Back
|
prototype |
- 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 |
|
|
storyboarding |
- 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 |
|
|
sketching |
- 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 |
|
|
scenarios |
- 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 |
