This document discusses user-centered design and prototyping. It defines user-centered design as an approach that focuses on understanding users, their goals, tasks, and environment. Prototyping is described as an essential part of user-centered design. Prototypes allow designers to evaluate designs with users early in the design process to identify and address issues before final development. The document outlines different types of prototypes including low-fidelity prototypes using simple materials and high-fidelity prototypes that more closely resemble the final product. Both have benefits and limitations for gathering feedback.
2. A model for interaction design
Evaluate
(Re)Design
Identify needs/
establish
requirements
Build an
interactive
version
Final product
3. What is User-Centered Design?
• An approach to UI development and system
development.
• Focuses on understanding:
– Users, and
– Their goals and tasks, and
– The environment (physical, organizational,
social)
• Pay attention to these throughout
development
4. ISO on User-centered Design
• ISO 13407 describes human-centered
design processes for interactive
systems
• Principles of human-centered design:
– Active involvement of users
– Appropriate allocation of function
between user and system
– Iteration of design solutions
– Multidisciplinary design teams
5. ISO on User-centered Design (2)
• Essential activities in human-centered
design:
– Understand and specify the context of
use
– Specify the user and organizational
requirements
– Produce design solutions (prototypes)
– Evaluate designs with users against
requirements
6. What is a prototype?
• What do you think of when you hear
“prototype”?
• What kinds of prototypes have you
seen anywhere?
– in other fields or disciplines?
– on television?
• What are they “for”?
7. What is a prototype?
• In other design fields a prototype is a
small-scale model:
a miniature car
a miniature building or town
• Exists for some purpose
– Show the “concept” to some stakeholders
– Get feedback about some aspect
– Test somehow
• E.g. a wing in a wind-tunnel
8. Prototyping and Software
• Do software companies do this?
– Sometimes do it well
– But sometimes the prototype is…
Version 1.0!
• Constantine and Lockwood:
“Software is the only engineering field that
throws together prototypes and then
attempts to sell them as delivered goods.”
9. What is a prototype for us?
In HCI / interaction design it can be (among other
things):
a series of screen sketches
a storyboard, i.e. a cartoon-like series of scenes
a Powerpoint slide show
a video simulating the use of a system
a lump of wood (e.g. PalmPilot)
a cardboard mock-up
a piece of software with limited functionality
written in the target language or in another
language
10. Why prototype in general?
• Evaluation and feedback are central to interaction
design
• Developers can test feasibility of ideas with team, users
• Stakeholders can see, hold, interact with a prototype
more easily than a document or a drawing
• Team members and users can communicate effectively
• To validate existing / other requirements
• It encourages reflection: very important aspect of
design
• Prototypes answer questions, and support designers in
choosing between alternatives
11. What to Prototype and Why
• Prototyping reduces uncertainty
– It can be a major tool for risk management
– Apply on whatever you might be uncertain
about!
• Prototyping technical issues
– E.g. run-time issues
• Prototyping to establish requirements
– Users “see” functionality
• Prototyping for usability concerns
– Our concern in this course
12. When and at What Level
• For SW, you might prototype at
various times in the lifecycle
– Different goals, different techniques
• Conceptual Design
• Interaction Design
• Screen Design
13. Benefits of Prototyping Early
• Exploration and evaluation of different
design options
• Increase communication among users
and developers
– Rapid feedback on ideas and changes
• Identify problems and issues before
construction (expensive)
14. Prototyping: Conceptual Design
• Early in development
• Explore high-level issues
– Different conceptual models
– Interaction styles
– User needs and characteristics
– Usability goals
• High-level representations
– Far from final code or GUIs
15. Prototyping: Interaction Design
• Later in development
• Focus on user work-flows
– Tasks and scenarios you’ve identified
• Might focus at the screen (or page) level.
Possibly like this:
– identify screens, pages, activities
– Organize these in groups
– Define flows or transitions between them
• Involve users in evaluation
• Representations
– Still probably not much like final code or GUIs
16. Prototyping: Screen Design
• Before development
• Define and refine screens (pages)
– Blue-prints for final physical design
• User evaluation
– Both achieving tasks and navigation, and
other usability criteria (as we’ve studied)
• Representations
– Low-fidelity or high-fidelity prototypes
17. Low-fidelity Prototyping
•Uses a medium which is unlike the final
medium, e.g. paper, cardboard
•Is quick, cheap and easily changed
•Examples:
sketches of screens, task sequences, etc
‘Post-it’ notes
storyboards
18. Storyboards
•Often used with scenarios, bringing more
detail, and a chance to role play
•It is a series of sketches showing how a user
might progress through a task using the
device
•Used early in design
19. Sketching
• Sketching is important to low-fidelity
prototyping
• Don’t be inhibited about drawing ability.
Practice simple symbols
• Can use post-its, photo-copied widgets,
etc.
20. •Index cards, post-its
•Index cards (3 X 5 inches)
•Each card represents one screen
•Often used in website development
Using Office Supplies
21. Using Office Supplies
• Post-its, index cards
– Can represent one screen, one page
– Color coded
– Draw on them
– Group them
– Put them on a wall or whiteboard,
connect them with string or lines
• Write-on tape, clear film
• And so on… See Rettig’s article
22. Rettig’s “Prototyping for Tiny
Fingers”
• “To get a a good idea, get lots of
ideas.”
• Problems with hi-fi prototyping:
– too easy to focus on “fit and finish”
– developers resist changing software
– SW prototype sets expectations
– Bug in SW prototype kills an evaluation
23. Storyboards
• Storyboards are:
– a low fidelity visual representation where
– steps or actions represented by panels,
like a comic book
• Goals are to
– flesh out the scenarios in an interaction
design
– effectively communicate with users or
stakeholders
24. Principles and Variations
• (As usual in HCI) storyboards should be
“real” and “representational” rather than
“abstract” or “complete”
• Used in different ways at different phases
– Early: focus on user tasks, work-flow, context,
etc.
– Later: lo-fi drawing of screens, menus, etc.
• Principles:
– Describe a scenario -- focused on interaction
– Contains explanations, notes, etc.
25. • Example:
• Shows
– workflow
of mail
merging
– who’s
involved,
responsib
ilities,
etc.
26. • This shows high-level of view of users
involved in other storyboards
From: Usability Case Studies, http://ucs.ist.psu.edu
27. • Lo-fi interface sketches
– Annotated with scenario/execution info
From: Usability Case Studies, http://ucs.ist.psu.edu
28. • Storyboard for
a website
– for
photographers
• Sequence of
pages
– based on clicks
• Explanations /
annotations
29. High-fidelity prototyping
•Uses materials that you would expect to be in
the final product.
•Prototype looks more like the final system
than a low-fidelity version.
•For a high-fidelity software prototype
common environments include Macromedia
Director, Visual Basic, and Smalltalk.
•Danger that users think they have a full
system…….see compromises
30. High-fidelity Prototyping
• Benefits
– More realistic
– Closer to final product
• Good for developers and users
– Can collect metrics
• Limitations
– More expensive, less rapid
– Reluctance to change
– See Rettig’s list
31. Compromises in prototyping
•All prototypes involve compromises
•For software-based prototyping maybe there
is a slow response? sketchy icons? limited
functionality?
•Two common types of compromise
• ‘horizontal’: provide a wide range of
functions, but with little detail
• ‘vertical’: provide a lot of detail for only
a few functions
•Compromises in prototypes mustn’t be
ignored. Product needs engineering
32. Possible Problems with
Prototyping
• Pressure to enhance prototype to become
delivered system
– From client
– From management
• Both see code, see almost-working “system”
• Why not use the prototype?
• Prototype built for quick updates, so...
– No design, so hard to maintain
– Ugly code, no error checking
– Wrong environment
33. And then… Construction
•Taking the prototypes (or learning from
them) and creating a final product
•Quality must be attended to: usability (of
course), reliability, robustness,
maintainability, integrity, portability,
efficiency, etc
•Product must be engineered
Evolutionary prototyping
‘Throw-away’ prototyping