Block 3 - Unit 4: Design, prototyping and construction Flashcards
1
Q
3 prototype kinds.
A
Storyboards. (expanded by:) Card-based prototypes. (expanded by:) Interface sketches.
2
Q
What do storyboards investigate? (3)
A
Environment.
High-level view of tasks.
Conceptual model, specifically interface type.
3
Q
What do card-based prototypes investigate? (3)
A
Task flow.
Initial interface design.
Conceptual model, specifically interaction type and interface metaphor.
4
Q
What do interface sketches investigate. (2)
A
Detailed interface design.
Conceptual model - all aspects.
5
Q
Comment on use of prototypes.
A
May be constructed at any time within the products’ development, and evolve iteratively through (re)design and evaluation.
6
Q
2 design types.
A
Conceptual - conceptual model that captures what the product will do, and how it will behave.
Physical - details like screen and menu structure, icons and graphics.
7
Q
Prototype (def and examples)
A
A limited representation of the design that allows the user to interact with it to explore the design’s feasibility or appropriateness.
Eg: paper-based screen outlines; electronic 'picture'; video simulation of task; 3D card mock-up of a workstation.
8
Q
Why prototype? (7)
A
Help during discussions with stakeholders.
Support discussions among team members.
Try out feasibility of ideas.
Helps designers choose between alternatives.
Clarify vague requirements.
User testing and evaluation.
Check design direction is compatible with the rest of system development.
9
Q
Low-fidelity prototype.
A
Does not look much like the final product, has no (or very limited) automatic interaction, and is built with materials such as paper, card and string.
10
Q
Use and adantages of low-fi prototypes.
A
Simple, cheap and quick to build / modify.
Supports exploration of alternative designs and ideas.
Important in early development (eg. conceptual design), as it’s used for exploring ideas it should be flexible and encourage exploration / modification.
(Not intended to integrate into final product - exploration only).
11
Q
Examples of low-fi prototypes.
A
Storyboard.
Sketching.
Index cards.
Wizard of Oz.
12
Q
Storyboard? (4 points)
A
Series of sketches showing how a user might progress through a task using the intended product.
Show the context outside the design of the product itself.
Can be a series of sketched screens for a GUI-based system.
Often used with a scenario - brings more detail and allows people to role-play, stepping through the scenario.
13
Q
Sketching.
A
No need for high skill.
Can devise own symbols and icons for certain elements, and practice using them.
Eg.
Things - people, computer, books, etc.
Actions - give, find, transfer, write
For interface - icons, dialog box, etc.
14
Q
Index cards.
A
Quite common in website development - each card represents one screen or one element of a task.
In user evaluations, the user can step through cards, pretending to perform the task while interacting with the cards.
15
Q
Wizard of Oz.
A
User interacts at a computer, but actually a human operator at another machine is simulating the response.
16
Q
High-fidelity prototyping.
A
Uses materials you would expect to find in the final product, usually exhibits automatic interaction, and has similar characteristics to the final product.
Usually built using software tools such as VB.
17
Q
Some problems with hi-fi prototyping. (5)
A
Take longer to build.
Testers tend to comment on superficial aspects rather than content.
Developers are reluctant to change something they’ve spent a long time on.
Software prototype can set expectations too high.
One bug can halt testing.
18
Q
Hi-fi prototype uses.
A
Useful for selling ideas and testing technical issues.
(Paper-prototyping should be used for exploring content and structure issues).
19
Q
Compromises in prototyping.
A
By nature they involve compromises - produced quickly.
So, the kind of questions / choices any one prototype can answer is limited - built with key questions in mind.
20
Q
2 common compromises traded-off in prototyping.
A
Breadth vs Depth of functionality:
Horizontal prototyping - wide range of function but little detail.
Vertical prototyping - lots of details for only a few functions.
21
Q
Compromises in lo- / hi- fi prototypes.
A
Low - clear, eg. doesn’t actually work.
Software based - some clear, eg. slow, icons sketchy, limited functionality.
Some not obvious to user - internal system structure not carefully designed; ‘spaghetti code’ or badly partitioned.
Users may believe the prototype is the system.
Developers may consider fewer alternatives as they’ve found one that is liked. But, must not ignore compromises made, especially ones less obvious from the outside.
Design team must be careful to avoid something not technically feasible - need technical knowledge in the team.
22
Q
2 main cultures for innovation.
A
Specification culture.
Prototyping culture.
23
Q
Specification culture. (3 points)
A
New products and development driven by specification.
Typically large companies that gather / coordinate lots of info.
Careful specifications may prove infeasible when prototyping.
24
Q
Prototyping culture. (3 points)
A
Understanding requirements and development driven by prototyping.
Typically smaller entrepreneurial companies.
A good prototype may prove too expensive for large-scale production.
25
Construction - from design to implementation.
When design has been round the iterative cycle enough times to feel confident it fits the requirements, everything learned through the iterative steps of prototyping and evaluation must be integrated to produce the final product.
Prototypes undergo extensive user evaluation, but may not have been subject to rigorous quality testing for characteristics like robustness and error-free operation.
A different testing regime is needed for constructing a product to be used by many of various platforms under a range of circumstances.
26
Evolutionary vs Throwaway prototyping.
If various complex prototypes fit requirements, it can be tempting to pull them together into a final product. But, underlying 'invisible' compromises in software structure stores up testing and maintenance problems.
Evolving approach can lead to a robust final product, but this must be planned and designed for from the start, with rigorous testing along the way.
27
Advantages of lo-fi prototypes (UB)
Flexibility and freedom to explore alternatives (quickly) and play with ideas, without the constraints of technology and without getting sidetracked into technical issues.
Using predefined widgets (eg. in VB) you're imposing a certain look and feel on the interface, and constraints on possible interaction kinds (unlike paper/card).
28
What aspects of design are paper-based prototypes useful for exploring with users? (6)
Concepts and terminology.
(Identify any unfamiliar / misleading terms).
Navigation, work flow and task flow.
(Not constrained by programmed paths - user free to follow own, possibly unexpected, paths).
Content.
(Should involve real content as far as possible).
Documentation / help.
(Can identify confusing / inappropriate terms and phrases, which in turn will influence the documentation written).
Requirements / functionality.
(Should help identify missed pieces of functionality).
Interface layout.
(Need to understand what should appear on a particular screen or interface and what is the relative importance of their elements).
29
Conceptual design.
Transforming needs and requirements into a conceptual model (fundamental to ID).
30
Conceptual model.
Outline what people can do with a product and what concepts are needed to understand how to interact with it.
Former - will emerge from current functional requirements.
Latter - who will the user be, the kind of interaction used, the kind of interface used, terminology, metaphors, application domain, etc.
31
First step to getting a concrete view of the conceptual model.
Investigate data gathered about users and goals, and try to empathise with them.
A picture of what you want the UX to be emerges.
32
Key guiding principles of conceptual design. (4)
Keep and open mind, but never forget the users and their context.
Discuss ideas with other stakeholders as much as possible.
Use low-fi prototyping to get rapid feedback.
Iterate, iterate, iterate,..............
33
How to really understand the users' experience.
'Learning by doing' is more effective.
'Experience prototyping' - intended to give an insight into UX that can only come from first-hand experience.
Eg. implanted defibrillator. Team given pager to receive messages, and record context and feelings knowing it represented a shock.
Third age suit - restricts movement, so simulates eg. old person driving.
34
Approaches which help pull together and initial conceptual model. (3)
Which interface metaphors are 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?
35
Choosing a good interface metaphor. (3 steps, not expanded).
1. Understand what the system / product will do.
2. Understand which bits of the system are likely to cause users problems.
3. Generate interface metaphors.
36
Expand on 'understand what the system will do' when choosing a good interface metaphor.
Achieved through the requirements activity;
eg. generate scenarios;
eg. 'provide users with recipes, tailored to own needs'.
37
Expand on 'understand which bits of the system are likely to cause problems' when choosing a good interface metaphor.
Identify which tasks or subtasks cause problems, are complicated or are critical.
A metaphor is only a partial mapping between software and something real - a metaphor can be chosen to support difficult areas.
38
Expand on 'Generate interface metaphors' when choosing a good interface metaphor.
Look for metaphors in users' descriptions of tasks to start.
Metaphors used in the application domain with which users may be familiar may be suitable.
Eg. KitchenMade - cookbooks, TV, paper-based forms.
39
How to evaluate suitable metaphors once generated. (5 questions)
1. How much structure does the metaphor provide?
(Good one requires structure, preferably familiar).
2. How much of the metaphor is relevant to the problem?
(Users can think they understand more than they do, and start applying inappropriate elements).
3. Is the interface metaphor easy to represent?
(A good one will be associated with visual / audio as well as words).
4. Will your audience understand the metaphor?
5. How extensible is the metaphor? Will extra aspects be useful later on?
40
Before answering the 5 questions to evaluate a metaphor, what needs to be done?
Analyse the metaphor and identify some key characteristics:
- what elements does it have?
- what can you do with it?
- what can't you do with it? (Limitations).
Consider interaction characteristics, not internal workings.
41
Process- vs Product- oriented conceptual models.
Difference - drivers for the design activity.
Product-oriented app - main products and tools needed to create them form the main structure of the app.
Process-oriented app - list of process steps forms the system's basis.
42
What issues should be addressed in conceptual design, whether product- or process- oriented. (Mayhew) (6)
Products or processes must be clearly identified. Eg. documents to be generated.
A set of presentation rules must be designed. Eg. urgent tasks must be placed on the desktop, less urgent via menu bar.
Design a set of rules for how windows will be used.
Identify how major info and functionality will be divided across displays.
Define and design major navigational pathways.
Document alternative conceptual design models in sketches and explanatory notes.
43
Choosing interaction types.
Which type is suited to the current design depends on the app domain and the kind of product being developed.
Eg. computer game - manipulating, drawing package - instructing / conversing.
Most conceptual models will include a combination o interaction types, and it is necessary to associate different parts of the interaction with different types.
Eg. KitchenMade - First entering diet requirements - instructing; choosing a suitable recipe - conversing / exploring.
44
How is considering interface types useful when thinking of the conceptual model.
Different interface types prompt and support different perspectives on the product under development and suggest different possible behaviours.
Therefore, considering the effect of different interfaces can prompt alternatives.
45
Expanding the conceptual model. (2 questions)
What functions will the product perform?
How are the functions related to each other?
46
Expand on 'what functions will the product perform?' when expanding the conceptual model.
Need to consider how the task will be divided up between the human and machine.
Eg. travel organiser - should the system automatically put holidays on hold, or wait to be told if suitable.
Development of scenarios, (essential) use cases helps to clarify.
Trade-off has cognitive implications - if high, can be stressful; if product does too much and is too inflexible, it may not be used.
47
Expand on 'how are the functions related to each other? when expanding the conceptual model.
May be related temporally, eg. one must be before another, or can be done in parallel.
May also be related through any number of possible categorisations, eg. all functions related to memory storage; all options for accessing files.
Relationships between tasks may constrain use or may indicate suitable task structures within the product.
Eg. restrict to strict order if a task is dependent on another being completed.
48
3 relationships between tasks.
Tasks and subtasks.
Sequencing.
Categorisation.
These influence how tasks are designed into the product, eg. by structuring screens around a task hierarchy, grouping related tasks, keeping unrelated tasks separate, etc.
49
KitchenMade task relationships.
2 main subtasks: entering user's data and choosing a suitable recipe.
Sequential relationship - if dietary requirements known, it can help more effectively in choosing a recipe.
Also related as recipe-choosing task needs to be able to make use of a user's data. Eg. if diabetic, needs to make suitable choice.
50
What info needs to be available for tasks?
For each supported task, we need to identify the info it requires.
Data requirements will have been identified during the requirements activity, but will not have been related to specific tasks.
Can be captured with a list of 'tasks : data needed'.
This will feed into interface design when we consider how the task is divided across screens, and what info needs to be on each screen.
KitchenMade:
Entering user-specific data - allergies, likes/dislikes, etc.
This info will be needed in order to search the set of recipes that the system holds.
Choosing suitable recipe - this info will be needed so a suitable recipe can be chosen, but need not necessarily be shown to the user.
51
When does conceptual design become physical design.
No rigid border.
Producing a prototype will mean making some (tentative) detailed decisions.
ID is iterative - some detailed issues come up in conceptual design; in physical design we'll need to revisit decisions made in conceptual design.
Border not relevant - what is relevant is that conceptual design should be allowed to develop freely without being tied to physical constraints too early - might inhibit creativity.
52
Design choices.
Must strive to balance environmental, user, data and usability requirements with functional requirements.
Often in conflict, eg. functionality and size of portable devices.
The way we design the potential interface shouldn't conflict with the users' cognitive processes involved in achieving the task, (attention, memory, etc), and musth design physical form with these in mind.
Eg. avoid memory overload by listing options.
53
Designing websites for different cultures (alternative to Hofstede's dimensions).
A international site, with guidelines including:
Be careful about using images that depict hand gestures or people.
Use generic icons.
Avoid colours associated with flags or political movements.
Ensure product supports different calenders, date/time formats, number formats, currencies, etc.
Avoid integrating text in graphics - can't be translated easily.
54
One global website vs many local ones.
Different cultures respond differently to a whole range of attitudes and priorities.
One website to appeal to all may be difficult, but creating different ones is resource-intensive and may dilute the brand.
55
WIMP / GUI interfaces.
Originally - Windows, Icons, Menu, Pointing.
First generation - boxy, constrained to a set of widgets, eg. dialog box.
Modern GUI - same basic building blocks, but evolved into different forms and types.
Eg. different types of icon and menus - audio icons/menus, 3D animated icons, 2D icon based menus.
Windows expanded - variety of dialog boxes, interactive forms and feedback/error messages boxes.
56
Window design.
Overcame constraints of display - more info can be viewed and more tasks performed on the same screen.
Multiple windows open at once - can switch between.
Scroll bars - horizontal / vertical.
57
Dialog box.
Confirmations, error messages, checklists, forms.
Info often guides user interaction - follow sequence of options.
Eg. sequenced forms (Wizards) for required and optional choices when creating Powerpoint or Excel documents.
Downside - tendency to cram too much info or entry fields in one box - confusing and cramped, difficult to read.
58
Research and design issues - window design.
Window management - fluid switching, rapid attention switch without distraction.
Average activation - 20 secs, ie. frequent switching.
Taskbar in main method in 'Windows'.
New ways being developed, eg 'galleries' - set of options instead of dialog box.
Design principles - spacing, grouping, simplicity; leads to legibility and ease of use.
59
Menu design.
Structured way to choose from options
Headings make it easier to scan and find what you want.
Interface menus across the top or down the side using category headers.
Contents mostly invisible - drop down on select / rollover.
Options typically in frequency of use order, or grouped with similar options.
60
Styles of menu. (4)
Flat lists.
Drop-down.
Pop-up.
Contextual.
Expanding.
61
Flat menu style.
Good for small number of options at the same time, and where the display is small (smart phone).
But, options often nested - several steps to get to the desired list (and back to the top level).
62
Expanding menu style.
Can show more options.
Navigation more flexible - selection of options in the same window.
But, may have to scroll through many options.
Cascade is a common example.
Disadvantage - requires precise mouse control.
63
Contextual menu style.
Provide access to often-used commands associated with a particular item (eg. an icon).
Commands make sense in the context of the current task.
Eg. right-click on web image - 'view', 'copy', 'save', etc.
Advantage - limited number of options associated with an interface element - overcomes some navigation problems with expanding menus.
64
Research and design issues - menu design.
Choice of term is important, eg. 'bring all to the front' is more informative than 'front'.
But, space often restricted - names short.
Need to be distinguishable from each other.
Operations, eg. 'quit' and 'save' should not be next to each other.
Choice is often determined by app and system type - depends on number of options and display size.
65
Icon design.
Assumption - icons are easier to learn and remember than text labels.
Can also be compact and variably positioned on a screen.
Functions - represent desktop objects, depict tools, apps and abstract operations (eg. cut, paste, next, accept).
Modern icon tend to be more detailed, and may be animated.
66
Icons and mapping.
Mapping between representations and underlying referent can be:
- similar (eg. picture of a file to represent an object file).
- analogical (eg. picture of scissor for 'cut').
- arbitrary (eg. X to represent delete).
67
Research and design issues - icon design.
Books with guidelines, standards and style guides.
Icon builders and icon sets, eg. clipart.
Apple provides developers with guidelines and style guides.
Text labels can help disambiguate - if space is limited can use rollover text.
68
Physical design. (Def)
Concerned with the details of a product, including colours, sound and images, menu design and icon design, size / location of buttons etc.
69
How do company style guides guide design.
Dictate the look and feel - which widgets for which purpose, and how they look.
Eg. menus in the same place, same icon for 'close', 'print', etc., typeface in dialog boxes.
Can be used to deliver a particular corporate image (corporation style guide).
70
Universal usability.
The universal usability movement believes design should cater for a wide range of needs and abilities, and therefore be flexible and enable alternative methods of interaction.
Guidelines / principles for universal access help make use of systems easier for all, not just disabled.
71
Universal design.
'.... design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialised design.'
72
Principles of universal design. (7)
Equitable use.
Flexibility in use.
Simple and intuitive.
Perceptible info.
Tolerance for error.
Low physical effort.
Size and space for approach and use.
(Not specifically software-based).
73
Designing for cultural diversity.
One way - identify aspects that will need to be culture specific, and those that won't. Then design suitable alternatives for these culture-specific aspects.
Another approach - design to be as international as possible.
74
Using scenarios in design. (UB)
Powerful mechanism for communicating among team members and with users.
Can be used and refined through different data gathering sessions, and they can be used to check out alternative designs at any stage.
Can be used to explicate existing work situations, but more often used for expressing proposed / imagined situations to help in conceptual design.
Often, stakeholders are actively involved in producing and checking through scenarios for a product.
75
4 suggested roles for scenarios.
As a basis for overall design.
For technical implementation.
As a means of cooperation within design teams.
As a means of cooperation across professional boundaries, ie. in a multidisciplinary team.
(Could be used for all these in one project).
76
More specific uses of scenarios.
Scripts for user evaluation of prototypes, providing a concrete example of a task the user will perform with a product.
A basis of storyboard creation, and to build a shared understanding among team members of the kind of system being developed.
Good at selling ideas to users, managers and potential customers.
'Plus' and 'minus' scenarios attempt to capture the most +ve and -ve consequences of a particular proposed design solution, therby helping designers gain a more comprehesive view of the proposal.
77
Generating storyboards from scenarios.
A storyboard represents a sequence of actions or events the user and system go through to achieve a task.
A scenario is one story about how a product may be used to achieve the task.
Therefore possible to generate a storyboard from a scenario by breaking it into steps focusing on interaction - one scene per step.
78
Purpose of generating a storyboard from a scenario. (2)
The storyboard can be used to get feedback from users / colleagues.
To prompt the design team to consider the scenario and the use of the system in more detail.
79
How does generating a storyboard from a scenario help design?
A scenario is not detailed. Drawing the environment or just the screen, it makes you think about details.
Eg. where the system will be used, the kind of I/O devices, what info needs to be available on what screen.
Helps explore design decisions and alternatives, but also made more explicit because of the drawing act.
80
Travel organiser - questions raised by drawing. (4)
How can interaction be designed for all the family?
How confidential?
Sit or stand?
Documents or help needed?
(The questions prompted are as important as the end product).
81
Key strength of a storyboard.
It can show the context of use (environment).
It can also be used to check out the interface type chosen for the product, and provide a high-level view of supported tasks.
82
Process of generating a storyboard from a scenario.
Break down the scenario into discrete steps - drawn as discrete actions.
Similar process to developing an essential use case (which can form the basis of a storyboard).
Should try and avoid assumptions like the device the system is running on, or detail of interaction.
This could lead to alternatives (such as portable device) being missed.
Captures activities beyond those directly with the interface, ie. considers environmental requirements.
83
Reflection on generating a storyboard from a scenario.
Good understanding of requirements helps.
Should be quick and easy to draw.
Explore the environment an interface type while drawing.
Focus on scenario and user characteristics - helps make things concrete and to consider system details.
84
Uses and benefits of generating card-based prototypes from use cases.
Value - screens / screen elements can be manipulated and moved around to simulate interaction (with or without user).
Drawing concrete elements of the interface forces a designer to think about detailed issues so the user can interact with the prototype.
Cards can be shown to potential users for informal feedback.
The more often developing ideas are shown, the more chance of fulfilling goals.
Also important to show colleagues to get another designer's perspective on emerging design.
85
Uses of card-based prototypes (UB)
Used to explore elements of a conceptual model - division of tasks across screens, relationships between tasks and info required for each task to be undertaken (what's available on each screen).
One card can represent a view of the whole interface, or elements of that view.
Card-based prototypes may also be used to test out different interface metaphors, interaction types and interface types (that have been considered in the development of the conceptual model).
86
Best place to start when generating card-based prototypes.
Step through the task that the user will perform.
Scenarios / use cases can help, but they may have been modified as a result of earlier conceptual design stages.
Focus on content rather than layout.
87
How card-based prototypes can help.
Feedback can form the basis of redesign and rethinking.
Would be redrawn, evaluated with users and modified, etc., several times before considering detailed interface design.
User may prefer a particular layout as it's eg. familiar, may expect more info, etc.
May have alternative suggestions.
Getting terminology, task flow, support features, interaction type and metaphor right are important design decisions which can be tested using cards.
88
Design patterns for HCI.
Patterns capture experience, but have a different structure and different philosophy from eg. guidelines or specific methods.
Vocabulary created, based on pattern names, used to communicate between designers, and to users.
Pattern - solution to a problem in a particular context.
Literature documents experience in a compelling form - users of a pattern can understand when / where it has worked before and see the rationale for why it worked.
89
Prototyping physical design.
Can expand cards to generate a more detailed software or paper-based prototype.
One of more cards would translate to a sketch with more detail about I/O tech, icon usage, error messages, menu structures and style conventions for external consistency.
Also, issues like layout, info display, attention, memory, etc. considered at this stage.
90
Forms of physical design prototypes.
Paper-based - may consist of a set of sketches representing the interface and its different states;
or may use post-its, tape, acetate, etc, that allow the prototype to be 'run' - a human plays the part of a system; observers may also be involved.
91
As well as considering info related to the product's usability and UX goals, what else do physical design prototypes draw on.
Design guidelines for potential interface types.
Eg. travel organiser - shareable interface needed.
Horizontal surface encourages collaboration, large interface can break up collaboration.
Design guidelines exist for tabletop displays.
92
Interface sketch.
Low-fi prototype, which shows a detailed design of the interface for an interactive product.
A4 paper - whole screen for a desktop, possibly whole interface for a mobile app.
93
Questions to consider after gaining feedback from cards to develop interface sketch. (8)
Was the task split in the cards appropriate, or need changing? If so, how?
Does the app need to be consistent with other apps?
(Sketch first to account for constraints).
What elements need to be included in the interface you're sketching?
Which elements do you want users' attention to be drawn to when they first arrive at this point? How?
What mechanisms will users need to indicate control such as choosing options or next task stage?
Does the interface require icons, or would the interface be enhanced by using icons?
(Eg. replace text using icons)
Are there clear groupings of info or commands that will make the interface easier to use? How to represent grouping?
What kinds of info needs to be displayed? How best to represent?
94
Tool support.
Tools available, from development environments that support prototyping to sketching tools, icon & menu design, widget libraries, etc.
Eg. DENIM - pen-based sketching tool for informal sketch / prototypes of websites.
95
Benefit of tool support
UI tools reduce code needed to implement elements and tie them together.
Many desktop apps are constructed with such tools. (Different tools / techniques needed for eg. mobile or tabletop displays).
96
Examples of successful tools. (3)
Window managers an toolkits.
Event languages.
Interactive graphical tools or interface builders.
97
Examples of unsuccessful tools. (2)
UI management tool (UIMS).
Constraints. Eg. maintain relationships among elements.
As there might be more than one solution the result may be unexpected.
