CS352
• Project – learning from your users due tomorrow Wed. 11:59pm
2
• P redispositions: Did this in Project
Proposal.
• RI : R esearch was studying users.
Hopefully led to I nsights.
CP : C oncept and initial (very low-fi)
P rototypes
• Evaluate throughout, repeat iteratively!!
• Pre-prototype
• Explore how to address some aspect, e.g.,:
– The interface metaphor
• e.g., desktop, ...
– The paradigm or device
• e.g., WIMP, wearable, …
– The interaction type
• e.g., instructing, conversing, manipulating/demonstrating, or exploring)
• This is a brainstorming-like tool
– Consider several concepts.
The best way to have a good idea is to have lots of ideas.
-- Linus Pauling http://en.wikipedia.org/wiki/File:Pauling.jpg
• There should be some bad ideas!
• Don’t get too attached to a concept
– i.e., avoid design fixation
• Don’t spend too much time on any of them.
• Examples
– Example #1: The thermostat ideas you presented last week.
– Example #2: Fig 11.7
– Examples from Mike Madison’s homelessness project. (He ultimately scrapped all of them.)
Mike Madison, Jason De Runa, Jordan Fugate, Sakshi
Gupta
• In your teams:
– Sketch >=3 concepts for the on-line grocery.
– Pick a population/device(s).
– Be ready to argue for why your solution would work for that device/population
– Aim for creative, interesting, useful solutions
• We’ll look at a few with the doc scanner.
• Questions to try to decide (#2-6 are for metaphor concepts):
1. Does it solve the problem/aspect?
2. How much structure does it provide?
3. How much of it relevant to the problem?
4. Is it easy to represent?
5. Will your audience understand the metaphor?
6. How extensible is the metaphor?
• Project – learning from your users due tomorrow at 11:59pm
• Reading:
– Skim the BOXES only of section 6.3. (What is a box: heading says "Box n" or "Research and design issues")
– Read 11.2, 11.3, 11.5, 11.6
11
• To flesh out a concept with enough detail
– to communicate/understand user experience in detail.
– in this class: for our use to understand user problems with our ideas.
– can also be used to communicate with boss, news media, etc...
Low Fidelity
Marty Siegel
High Fidelity
Early design
Brainstorm different representations
Choose a representation
Rough out interface style
Low fidelity (paper) prototypes
Task centered walkthrough and redesign
Medium fidelity prototypes
Fine tune interface, screen design
Heuristic evaluation and redesign
Usability testing and redesign
High fidelity prototypes
Limited field testing
Alpha/Beta tests
Working systems
Late design
• Lo-fi prototypes ideal for some purposes:
– cheap
– flexible
– yet force enough attention to detail.
• Useful:
– When: AFTER get through lower-fi ones first.
– Why: Get at details of design (layout, icons, colors etc)
– Example:
Wizard of Oz: on the computer, but human fakes in the computer logic.
• Front end finished with widgets polished up, but behavior/data is hard-coded (no back end).
– For boss, at trade shows, etc.
• A method of testing a system that does not exist
– the voice editor, IBM 1984
What the user sees The Wizard
• Just how lo-fi can one go
– The lowest-fi: paper
• At first: sketches.
• Later can be more polished.
– Static paper vs. “interactive” paper.
– There are tool-supported variants of above concepts.
– Details of each next...
• Static paper
– For communicating among team.
– Usually done as a written use case or a sketched storyboard or sketched “state machine”.
– Example: Fig 11.2 (very high-level).
– Examples: Fig 11.4, 11.9 (more detailed).
– Example: Fig. 11.17 (very detailed).
– Another very detailed one (next slide).
• Dynamic (interactive) paper
– For evaluating with user at a very low-cost.
• Designing with office supplies
– multiple layers of sticky notes and plastic overlays
– different sized stickies represent icons, menus, windows etc.
• interaction demonstrated by manipulating notes
– new interfaces built on the fly
• session videotaped for later analysis
– usually end up with mess of paper and plastic!
• Can pre-make paper interface components buttons menu alert box combo box tabs list box entries
• Examples:
– Example #1: from ML-interaction experiment.
• (Next slide).
– Example #2: Fig 11.11
– Example #4: Fig 11.15
• Low-fi with tool support.
– DENIM (Fig 11.18) and CogTool (fig next slide): tools for sketched storyboards/states.
– Can transition these to nicer, more polished versions.
• vertical prototypes
– includes in-depth functionality for only a few selected features
– common design ideas can be tested in depth
• horizontal prototypes
– the entire surface interface with no underlying functionality
– a simulation; no real work can be performed
• scenario
– scripts of particular fixed uses of
Horizontal prototype
Scenario the system; no deviation allowed
Vertical prototype
Nielsen, J. (1993) Usability Engineering, p93-101, Academic Press.
Full interface
• throw-away
– prototype only serves to elicit user reaction
– creating prototype must be rapid, otherwise too expensive
• incremental
– product built as separate components (modules)
– each component prototyped & tested, then added to the final system
• evolutionary
– prototype altered to incorporate design changes
– eventually becomes the final product
• In here:
– We will begin with static paper (by Week 4),
• then iterate from that start using CogTool, and
• eventually have a more polished version, still in CogTool.
• Choose one concept you did for the online grocery.
• Consider one specific user task:
– your user wants to buy ingredients to make lemonade.
• Sketch a static prototype storyboard/states of your UI:
– that shows how your user will accomplish that task in your UI.
• The prototyping tool for this class.
• Supports:
– creating prototypes (various fidelities).
• static and interactive
– measuring user efficiency with your prototype
• skilled users
• given a particular task
• how 1: GOMS under the hood
• how 2: ACT/R full cognitive model under the hood
• Web site: resources/examples/QA support
• 1. Create a design storyboard
– From scanned images, html files, or ...
• 2. Define a task the (skilled) user is supposed to do.
• 3. Demonstrate the steps to accomplish the task.
• Example (see CogTool Tutorial):
– ChoiceWay Guide to NYC: Museum lookup task.
• A method of testing a system that does not exist
– the voice editor, IBM 1984
What the user sees The Wizard