LowFidelity Prototyping: Chauffeured Testing

1
Low-Fidelity PrototypingChauffeured Testing

• MIS 441 User Interface Design, Prototyping, and
  Evaluation
  
• Class 10 - February 15, 2000

2
Agenda for Today

• Review and finish discussion from last class
• What is prototyping?
• High-fidelity vs. low-fidelity prototyping
• Low-fi development materials
• Low-fi user testing (chauffeured methods)
• Examples

3
What Is a Prototype?

• Smaller representation of the system
• less reliable, robust, and complete than final
  systems
  
• Communicates the design to the user
• e.g., see if design model equals users
  conceptual model
  
• Built with different construction materials than
  the final system
  
• much faster to develop and change
• Keeps the design centered on the user
• allows user involvement in testing design ideas
• supports iterative design based on user feedback

4
Why do We Prototype?

• Resolves uncertainty about how well a design
  suits user needs
  
• necessary functionality of the system
• operation sequences
• user support / training needs
• required representations / mappings / metaphors
• look and feel of the interface
• Get user feedback on our design faster
• Enables experimentation with alternative designs
• Fix problems before code is written

5
What is Fidelity?

• High-fidelity (Hi-fi)
• prototypes look like their final product
• computer-based prototypes
• limited functionality so that users can actually
  interact with it
  
• more polished and aesthetically pleasing
• Low-fidelity (Low-fi)
• artists rendition with many details missing
• paper-based prototypes
• quick and inexpensive, provide valuable insights,
  but dont really demonstrate functionality
  
• think about a fashion designer

6

Low-Fi Sketch An Example
7
Why Use Low-Fi Prototypes?

• Traditional methods take too long
• sketches -- hi-fi prototype -- evaluate --
  iterate
  
• Can simulate the prototypes
• sketches -- evaluate -- iterate
• sketches act as prototypes
• designer plays computer
• other design members observe and record
• Kindergarten implementation skills
• allows non-programmers to participate

8
Problems With Hi-Fi Prototypes

• Perceptions of the tester/reviewer?
• formal representation indicates finished
  nature
  
• comments on color, fonts, and alignment
• Time?
• encourages precision
• specifying details takes more time and results in
  fewer iterations
  
• Creativity?
• lose track of the big picture
• we tend to fall in love with our sftwr solutions

9
The Basic Materials (Low-Fi prototyping)

• Large, heavy, white paper (11 x 17)
• 5 x 8 index cards
• Tape, glue stick, correction tape
• Pens and markers (many colors and sizes)
• Overhead transparencies
• Scissors, X-acto knives, etc.

10
Constructing the Model

• Set a deadline
• dont think too long - build it!!
• its about getting ideas on paper
• Draw a window frame on large paper
• Put different screen regions on cards
• anything that moves, changes, appears/disappears
• Ready responses for any user action
• e.g., have those pull-down menus already made
• Use photocopiers to make many versions

11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
Testing the Model

• Select your users
• look at user profile for target users
• use a questionnaire to get the people you need
• dont use friends or family
• get at least 3 users to evaluate the system
• Prepare scenarios (look at TA) that are
• typical of the product during actual use
• make prototype support these (small, yet broad)
• use 3 scenarios of varying difficulty in the
  evaluation
  
• Practice to avoid bugs

16
Conducting a Low-Fi Test

• Four testers (minimum)
• greeter - puts users at ease gets data
• facilitator - only team member who speaks
• gives instructions to the users
• hands the scenarios to be completed to the users
• encourages thoughts, opinions (think aloud
  protocol)
  
• computer - knows application logic controls it
• always simulates the response, w/o explanation
• observers - take notes recommendations
• Typical session is 1 hour (no more than 2)
• preparation, the test, debriefing

17
Conducting a Low-Fi Test

• Greet
• get forms filled, assure confidentiality, etc.
• provide brief background of what test is about
• Test
• facilitator hands written scenarios to the user
• must be clear detailed
• chauffeur the prototypes
• involves user watching while another person
  drives the system
  
• facilitator keeps getting output from
  participant
  
• Think Aloud Protocol - what are you thinking
  right now?
  
• observe - no a-ha, laugh, gape, etc.

18
Conducting a Low-Fi Test

• Debrief
• testers fill out post-evaluation questionnaire
• ask questions about parts you saw problems
• gather impressions (use interview scripts)
• give thanks
• You absolutely must read
• Guidelines for User Observation During User
  Testing (link on the MIS 441 web-site)
  
• explains the process and provides specific
  suggestions
  
• you should incorporate this into Milestone 4

19
Evaluating Results

• Sort prioritize observations
• what was important?
• lots of problems in the same area?
• Create a written report on findings
• gives agenda for meeting on design changes
• Develop a simple database to track these
  findings
  
• Make changes iterate

20
Sample Tracking Database
21
Clothes-Shopper An Example

• Problem
• contemporary approach to shopping is often slow
  and painful
  
• people often have problems shopping for clothing
  through catalogs (on-line or otherwise) because
  they are unable to visualize how they will look
  in the clothing
• Design solution
• design a UI that allow shoppers to quickly and
  easily visualize how various combinations of
  clothing will look on them
  
• Method
• use low-fi prototyping to develop a good, general
  understanding of the strengths / weaknesses of
  the initial UI design w/o spending a large amount
  of time on developing software

22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
2nd Iteration Opening Screen
27
2nd Iteration Main Screen
28
2 Iteration Screen After Tasks Performed
29
Three Scenarios to Be Evaluated

• Moderate scenario
• Joe from Berkeley wants to buy a new shirt and
  sports coat to be more fashionable in school. He
  does not have a car today and decides to give the
  Clothes Shopper a try. Help him navigate through
  the system, buy the things he wants and leave.
  Although there is no budget constraint, he wants
  a white plain shirt and a cool brown jacket.
• Moderate - difficult scenario
• Sally is a regular user of the Clothes Shopper
  system. She wants to buy a white gown for an
  upcoming prom but only has 150 as her budget.
  She already has an existing profile and does not
  wish to reenter the same information. Help Sally
  buy the gown and get her on a happy date!
• Beginner scenario
• Joanna is a new user to the Clothes Shopping
  system. She wants to go on the tour first and
  become familiarized with the system before doing
  any shopping. After the tour she wants to window
  shop some blue shorts, but doesn't feel like
  buying anything today. She prefers to try on some
  shorts casually and leave the mall.

30
Procedure

• Greet
• Conduct the test
• facilitator, computer, observers
• Debrief
• Evaluate and analyze
• discuss what went well, what went poorly
• comment on users reactions and comments
• compile into master copy and make suggestions for
  next iteration

31
Results of Evaluation (Clothes-Shopper)

• User knew how to enter system by clicking on
  diagram
  
• one user had question about what Tour meant
• Users got through logon screen pretty easily
• comments about how much information the user was
  able or willing to reveal (e.g., body weight,
  exact dimensions of clothes, etc.)
  
• Big confusion at the main menu
• did not know what to do to begin shopping
  (clicked on a lot of areas)
  
• finally noticed Navigation Assistant after much
  searching and experimentation and learned that
  they needed to click on it to begin
  
• when selected garment that they wanted, many
  clicked on preferences (colors) thinking they
  would be presented with choices
  
• specifying search parameters was not intuitive
  and natural in choosing their garment
  
• began to play with search parameters and figured
  out how to use it to get results

32
Results of evaluation (Clothes-Shopper)

• Big confusion at the main menu (continued)
• once the user got to the search results, two
  users were often confused on how to get the
  garment of their choice on the model
  
• they just clicked on the garment and expected it
  to appear on the model
  
• the design model was to have the user drag the
  garment to the model
  
• after getting the garments on the model the users
  expected to see a checkout or buy option that
  would send them to a checkout screen
  
• the designers intended for the users to
  double-click on the shopping cart to do this
  function
  
• after the users figured out how to get to the
  checkout, they bought the garments and exited the
  system pretty easily
  
• Final note was that once the user learned how the
  system worked, they were able to quickly run
  through the system to perform the other scenarios

33
Discussion What to Do Next?

• Change Begin Tour to Begin Tutorial
• Login screen was too wordy -- the number of
  buttons will be reduced to 3
  
• New User, Use existing profile, Change Current
  Profile
  
• Profile setup was fine except, for women, bra and
  chest size were considered redundant (eliminate
  one)
  
• Navigational Assistant was not intuitive -- maybe
  add text or have menus automatically pop up
  instead of requiring a click
  
• also need to add dresses and suit to torso
  section of assistant since users asked where
  these would be
  
• gray out preferences menu initially so user knows
  to click on the navigational assistant first

34
Discussion What to Do Next?

• Change preferences menu
• use words Show Clothes instead of Search (not
  very intuitive)
  
• Change some things about the Search Results
  section
  
• user did not know whether to click or drag the
  thumbnails to dress the dressing room model.
  They decided to just require a click to minimize
  confusion
• change title from Search Results to Clothes
  Gallery
  
• Dressing room changes?
• users liked the red curtain that concealed the
  model until a search was performed
  
• liked the Shopping Cart and Trash Can options
• were very confused by the Select All Clothes
  option
  
• designers just dropped the idea to reduce
  confusion

35
Discussion What to Do Next?

• Dressing room changes?
• so users can just select clothing on the model
  and put it in the shopping cart or trash can as
  desired
  
• add a Checkout button so the user can go ahead
  and buy what s/he has in his / her shopping cart
  (many users asked if such an option existed)
  
• A user also requested if it were possible to have
  a counter showing how many pieces of clothing
  were shown in the Search Results window (soon to
  be called the Clothes Gallery)
• this function will be added

36
Milestone 3 and 4

• Develop low-fi prototypes to support scenarios
• Explain the prototype and how it is suppose to
  work with storyboards (the designers model)
  
• Identify and recruit 3 evaluators
• Evaluate 3 scenarios of varying difficulty
• Prepare and conduct a user test (or evaluation)
• Discuss the results
• what the users said and did, positive or
  negative
  
• Discuss likely or potential changes to the design
  for the next low-fi iteration

37
Summary

• Advantages of low-fi prototypes
• takes only a few hours
• very cheap
• no expensive equipment or tools are needed
• requires few technical skills
• allows everyone in design team to actively
  participate
  
• can test multiple alternatives
• fast iterations
• note that the of iterations is tied to final
  quality
  
• users less likely to see design as fixed
• chauffeured testing enables real users to evaluate

38
Next Time...

• Low-fi storyboarding
• Read the readings from the internet listed in the
  syllabus for next class
  
• Managing Risk Using Low-Fidelity Prototypes
• Storyboarding Example
• Turn in Milestone 2