Introduction to Design and Prototyping

1
Introduction to Design and Prototyping

• Loren Terveen
• CS 5115, Fall 2008
• September 29

2
Objectives for today

• Review next weeks project deliverables
• Get a quick tour of interaction styles
• Learn about design methods, specifically LoFi
  (paper) prototyping

3
This weeks Hall of Fame/Shame

• Today
• Sinan Goknur Denis Foo Kune
• Noah Odland Luke Parrott
• Wednesday
• Arun Kumar Mannava Josh Fehrman
• Paul Kavan Robert Fraher

4
Hall of Shame/Fame

• Sinan Goknur Denis Foo Kune
• September 29, 2008

5
My Dell Laptop
6
My Dell Laptop
7
IBM Takes the Cake
8
IBM Takes the Cake
IBM Even if both slots afford headphone jack to
go in, good use of color coding helps recognition
faster.
Dell Need to pay attention to faint and painful
icons each time.
9
Currency

• Who are the users
• Typically local and foreign residents of a
  particular country
• Purchase goods and services
• Be able to know the state to the system
• This system
• Conceal the state from other users

10
US Currency

• Source US Bureau of Engraving and Printing
  (http//www.moneyfactory.gov)

11
Usable design?

• Visibility
• Bills that differ in value are similar in size,
  color and texture
• Uses recognition faces
• Cluttered with anti-forgery features
• Affordances
• Unclear view of what the user can actually afford
  (no pun intended)
• Affords transport and exchange
• Constraints
• Not built in the system. Relies on honest users.
• Mappings
• Intuitive, analogous to the barter system
• Give a bill, receive goods and/or services in
  return.
• Change? How much? Again unclear due to design
  that is visually analogous
• Cultural standard
• Has to be learned, but visual cues present

12
Usable design?

• Feedback
• Instantaneous if receiver is honest
• After the fact otherwise
• Hard to prove in any case
• Users cannot feel the different bills due to
  similar size and texture
• Visually impaired users are at a severe
  disadvantage
• Design for error
• 100 v/s 5 Possibility that large mistakes (up
  to 2 orders of magnitude per bill) could go
  undetected
• The current US system with current bills affords
  you to give any bill, regardless of the users
  intentions
• Gulf of perception
• Perceiving the state the the system is hard for
  such a simple task
• The user has to carefully inspect each bill to
  know the state of the system
• Gulf of execution
• Intention to act (give 5) can result in an
  incorrect sequence of events (give 20)

13
Hall of

• Shame!

14
Australian Currency
Source Reserve Bank of Australia (http//www.rba
.gov.au/)
15
Australian Currency(relative sizes)
16
Usable design?

• Visibility
• Visual scanning is enough
• Bills of different values are similar in texture,
  but different in size and color
• Uses recognition faces
• Cluttered with anti-forgery features
• Affordances
• Clear view of what the user can afford
• Affords transport and exchange
• Constraints
• Not built in the system. Relies on honest users.
• Mappings
• Intuitive, analogous to the barter system
• Give a bill, receive goods and/or services in
  return.
• How much change? Obvious by the bill that was
  handed out.
• Cultural standard
• Has to be learned, but visual cues present
  numbers, faces, color and size

17
Usable design?

• Feedback
• Users can feel the different value bills due to
  different sizes
• Instantaneous before exchanging the bill
• Visually impaired users can compare a stack of
  different sized bills
• Intuitively, the most valuable notes are bigger.
  But that makes it hard to conceal as well
• Design for error
• 100 v/s 5 Large mistakes are more easily
  detected with different sizes and color
• Gulf of perception
• Perceiving the state the the system is simple for
  a simple task
• The user glance and scan the sizes and colors to
  get the state of the system
• Gulf of execution
• Intention to act is closer to the sequence of
  events since different color bills are hard to
  mix up
• The Australian system provides better limits
  depending on the users intentions

18
Hall of

• Fame!

19
Hall of Fame/Shame

• Luke Parrott and Noah Odland

20
Shower Controls 1
21
Hall of Fame

• Follows many conventions
• Uses color coding, blue for cold, red for hot
• Follows convention of "righty tighy, lefty
  loosey"
• Pull up on slider to activate shower
• Not overly complicated
• One knob for water/temperature control
• One pull to activate shower head
• Only downfall could be confusion over tub and
  shower controls, but that mistake would only need
  to be made once.

22
Shower Controls 2
23
Hall of Shame

•  There are not any labels
• Cannot be sure which knob controls what function,
  may be hard for first time users
• Must guess based on previous experiences which
  direction to turn knob to control temperature
• There are no directions for the tub/shower
  control.  Could be very difficult to know how to
  change settings

24
Shower Controls 3
25
Hall of Fame

• Uses colors for hot and cold
• Temperature bar gets bigger the farther you get
• Arrow showing where you currently are
• Turns on by lifting up on the knob, which is
  pretty standard. Would only take once to figure
  out

26
(No Transcript)
27
Deliverables for next week

• Paper (LoFi) prototypes
• Two per project team 8 minute presentation
• Be prepared to discuss rationale and (if you have
  more than one prototype) pros and cons of the
  alternatives
• Note that it will eventually have to support a
  task walkthrough
• Logistics
• Class in EE/CS 2-260
• No TA meetings
• Come as often as you can!
• And youll also begin preparing for your
  executable prototype next week, too

28
Presentation logistics

• 8 minutes 2 for questions
• Show tasks
• Show prototype
• Walk through a task (same)?
• What are the main design ideas?
• Where did you get them?
• Why do you think theyll work?

29
Design
30
Design Broad Spectrum

• System Design
• Requirements
• Architecture
• Information Design
• Graphic Design
• Interaction Design

31
Design as a Discipline

• Balance between creation and evaluation
• What could be
• What should be
• Form vs. function
• Design as good taste
• How do you get it?

32
Levels of Design

• Conceptual
• Logical
• Visual

33
Heuristics and Rules

• Normans Principles
• Shneidermans Golden Rules
• Nielsens heuristics (later)?

34
Interface Design Strategies

• Find a tool that does all/part of the job
• dont write a new spreadsheet extend!
• Borrow intelligently know the rationale
• Work within an existing framework / paradigm /
  model

35
Paradigms

• Direct manipulation (games)?
• Navigation Menus, links (web)?
• Entry Form fill-in (web)?
• Command Language (unix)?
• Natural Language/Speech
• Access Search, browsing, tagging
• Interaction Blogs, Forums, Wikis

36
Direct Manipulation

• Advantages
• Visually presents task concepts
• Allows easy learning
• Allows easy retention
• Can prevent errors
• Encourages exploration
• High subjective satisfaction

• Disadvantages
• Harder to program
• Require graphics display and pointing device

37
Menu Selection

• Advantages
• Shortens learning
• Reduces keystrokes
• Structures decision making
• Permits use of dialog management
• Easy error handling

• Disadvantages
• Presents danger of many menus
• May slow frequent users
• Consumes screen space
• Requires rapid display

38
Form fill-in

• Advantages
• Simplifies data entry
• Requires modest training
• Gives convenient assistance
• Permits form management tools

• Disadvantages
• Consumes screen space

39
Command Language

• Advantages
• Flexible
• Appeals to power users
• Supports user initiative
• Allows convenient creation of macros

• Disadvantages
• Poor error handling
• Substantial training and memorization

40
Natural Language

• Advantages
• Relieves burden of learning syntax
• May be natural in some settings, e.g.,
  interaction over a telephone

• Disadvantages
• Requires clarification dialog
• May require more keystrokes
• May not show context
• Is unpredictable

41
Some comments

• All these styles should be in your toolbox (NL
  used much less frequently)?
• Often are combined in a single app
• DM with menus and forms is common
• Different platforms / toolkits make particular
  styles more or less easy

42
Prototyping
43
Why prototype?

• Power of the concrete
• Encourage reflection
• Communicate ideas, get feedback
• Identify hard/controversial parts of the design
• Early is better before resources committed and
  emotions invested
• Support selecting among alternatives
• Help budget and plan

44
Prototype vs. Product

• Can you use the final prototype as the product?
• No, but
• Parts of the prototype may be usable
• executable interface
• images, media
• Design is often harder than implementation

45
Prototyping Techniques

• Functioning Programs
• Scenario-Functioning Programs
• Stand-Alone Interfaces
• Dedicated Prototypes
• Drawn Prototypes
• Paper Prototypes

46
Functioning Programs

• Unoptimized draft program
• Best approach for
• simple problems (few design options)?
• easy development tools
• already existing back-end
• applications where complete interaction is
  critical

47
Scenario-Functioning Programs

• Only work for a specific path of execution
• Perhaps for specific user, task
• Examples
• clinical record system that only handles routine
  check-up
• ATM that only handles withdrawals
• Pro good for getting real feedback
• Con bad for further analysis

48
Stand-Alone Interfaces

• Implement UI without back-end functionality
• Mock up functionality where needed
• every query returns same data...
• Interface builders may be useful

49
Dedicated Prototypes

• No path to delivery code
• Provide only the necessary functionality
• May implement on different platform or with
  completely different tool
• Hypercard, Flash
• Not common anymore most current tools can lead
  (close) to a deliverable

50
Drawn Prototypes

• Screen shots without execution
• Efficient when tools are good
• PowerPoint
• Visio
• Better looking than paper without excessive
  commitment

51
Paper (Low Fidelity) Prototypes

• Sketches of interface and task completion
• paper, post-its, or screen drawings
• Sufficient sequences to model interaction
• Very inexpensive, quite useful
• Cannot handle dynamic interaction

52
A Surprising Finding

• In many circumstances, LofFi prototypes work
  better than HiFi prototypes

53
Why?

• Goal to try out lots of ideas fast/early
• to get a good idea, get lots of ideas
• Instant iteration
• users suggest more fundamental changes
• users focus on high level rather than color,
  labels, graphical details
• Status is clear

54
HiFi prototype downsides

• Take longer to develop
• More resources
• More emotional commitment
• So developers resist changes
• A single bug can halt testing
• Users may focus on superficial issues
• Can set unrealistic expectations

55
What to prototype?

• Screen layouts and information display
• Work flow, task design
• Technical issues
• Difficult, controversial, critical areas

56
Paper prototyping video from Nielsen Norman Group