Block 3 - Unit 4: Design, prototyping and construction Flashcards
3 prototype kinds.
Storyboards. (expanded by:) Card-based prototypes. (expanded by:) Interface sketches.
What do storyboards investigate? (3)
Environment.
High-level view of tasks.
Conceptual model, specifically interface type.
What do card-based prototypes investigate? (3)
Task flow.
Initial interface design.
Conceptual model, specifically interaction type and interface metaphor.
What do interface sketches investigate. (2)
Detailed interface design.
Conceptual model - all aspects.
Comment on use of prototypes.
May be constructed at any time within the products’ development, and evolve iteratively through (re)design and evaluation.
2 design types.
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.
Prototype (def and examples)
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.
Why prototype? (7)
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.
Low-fidelity prototype.
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.
Use and adantages of low-fi prototypes.
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).
Examples of low-fi prototypes.
Storyboard.
Sketching.
Index cards.
Wizard of Oz.
Storyboard? (4 points)
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.
Sketching.
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.
Index cards.
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.
Wizard of Oz.
User interacts at a computer, but actually a human operator at another machine is simulating the response.
High-fidelity prototyping.
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.
Some problems with hi-fi prototyping. (5)
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.
Hi-fi prototype uses.
Useful for selling ideas and testing technical issues.
(Paper-prototyping should be used for exploring content and structure issues).
Compromises in prototyping.
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.
2 common compromises traded-off in prototyping.
Breadth vs Depth of functionality:
Horizontal prototyping - wide range of function but little detail.
Vertical prototyping - lots of details for only a few functions.
Compromises in lo- / hi- fi prototypes.
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.
2 main cultures for innovation.
Specification culture.
Prototyping culture.
Specification culture. (3 points)
New products and development driven by specification.
Typically large companies that gather / coordinate lots of info.
Careful specifications may prove infeasible when prototyping.
Prototyping culture. (3 points)
Understanding requirements and development driven by prototyping.
Typically smaller entrepreneurial companies.
A good prototype may prove too expensive for large-scale production.
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.
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.
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).
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).
Conceptual design.
Transforming needs and requirements into a conceptual model (fundamental to ID).
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.
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.
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,…………..
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.
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?
Choosing a good interface metaphor. (3 steps, not expanded).
- Understand what the system / product will do.
- Understand which bits of the system are likely to cause users problems.
- Generate interface metaphors.
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’.
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.
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.
