cs 350 computer/human interactionuenics.evansville.edu/~hwang/s18-courses/cs350/lecture21...ticket...
TRANSCRIPT
CS 350 COMPUTER/HUMAN
INTERACTION
Lecture 21
Includes selected slides from the companion website for Hartson & Pyla, The UX Book, 2012. ©MKP, All
rights reserved. Used with permission.
Outline
■ Chapter 10: Metrics
– UX goals, metrics, targets
■ Chapter 11: Prototyping
– Breadth vs. depth
– Fidelity
– Interactivity
– Paper prototypes
2March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX goals, metrics, and targets
■ Used to guide evaluation
– User performance
– Emotional satisfaction
■ Unfortunately, often only one round of
evaluation
■ But the process of establishing metrics
and targets informs design
3March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX goals
■ High-level objectives
■ Stated in terms of anticipated user experience
– For all users in general
– For specific work roles or user classes
■ Extracted from contextual inquiry and analysis
■ Examples: ease of use, power performance for experts, avoiding errors for intermediate users, walk-up-and-use learnability, etc.
4March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX target table
■ Organize UX targets in a table
– Work role:user class
– UX goal
– UX measure
– Measuring instrument
– UX metric
– Baseline level
– Target level
– Observed results
5March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX measures
■ General user experience characteristic
■ Measured with respect to interaction
design
■ Obtain quantitative data
– Observable user performance
– User opinion
■ Ticket Kiosk System (TKS) example
– Initial user performance
6March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
TKS example
■ Work role:user class
– Ticket buyer: Casual new user, for occasional
personal use
■ UX goal
– Walk-up ease of use for new user
7March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Measuring instruments
■ Description of method of how the data is
gathered
■ Representative benchmark tasks to be
performed by user participants
■ TKS examples
– BT1: Buy special event ticket
– BT2: Buy movie ticket
8March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX metrics
■ Kind of value obtained for a UX measure
■ I.e., what is being measured
■ Objective, performance-based, and taken
while participant is doing benchmark task
– Typically time to complete task, error count
– Also, time spent on error recovery, number of
repetitions of failed commands, number of
commands
9March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
UX metrics
■ Subjective metrics represent numeric
outcomes from a questionnaire
– Usually simple statistic like average
■ TKS example
– BT1: Average time on task
– BT2: Average number of errors
10March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Baseline level
■ Minimum performance level
■ Often measured for the current system
– TKS example: time to do task at MUTTS
ticket counter
– Average of measured times
■ Ensures that metric is, in fact, measurable
11March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Target level
■ Quantitative statement of the desired
value for a UX metric
■ Achieving value indicates attainment of
user experience success
■ Quantification of the UX goal for each
specific UX measure and UX metric
■ Where not met become focal points for
improvement
12March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
TKS Example
■ BT1: Buy an event ticket
– Baseline level: 3 minutes (from MUTTS)
– Target level: 2.5 minutes
■ BT2: Buy a movie ticket
– Baseline level: < 1 error (almost never have
errors)
– Target level: < 1 error
13March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Observed results
■ Values measured while observing users
perform tasks during evaluation sessions
■ Allows direct comparison between
specified levels and actual results
14March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Introduction: Prototyping
■ A way to evaluate design before it’s too
late and too expensive
15CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Depth and breadth of a prototype
■ To be fast and easily changed, prototype
must be less than real system
– How to make it less?
– Focus on less than full fidelity of details
– Just breadth or just depth of tasks supported
16CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Depth and breadth of prototypes
17CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Horizontal prototypes
■ From Nielsen
■ Slice functionality by breadth
– Broad in feature coverage, less depth of
detail
– Good overview for top-down approach
– Will not support details of work flow
– Evaluation not too realistic (design still too
abstract)
18CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Vertical prototypes
■ Slice functionality vertically by depth
– As much depth as possible in current state
but only for few features
– But those features included can be
evaluated realistically
19March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
“T” prototypes
■ Most of user interface realized at shallow level (horizontal bar of “T”)
■ A few parts done in depth (vertical stems of “T”)
■ Nice balance, advantages of both
20March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Local prototypes
■ Small area where horizontal and vertical
slices intersect
■ Used to evaluate design alternatives
■ For particular isolated interaction details
21March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Local prototypes
■ Examples
– Appearance of an icon
– Wording of message
– Behavior of individual function
■ Good for when your design team just
cannot decide a small part of design
22CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Fidelity of prototypes
■ Reflects how “finished” prototype is
perceived to be by customers and users
– Not how authentic or correct underlying code
is
23CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Low-fidelity prototypes
■ Low fidelity can be paper prototype or
simple wireframe
■ Not faithful representations of details of
look, feel, and behavior
■ Give rather high-level, more abstract
impressions of intended design
24CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Low-fidelity prototypes
■ Appropriate when design details
– Have not been decided
– Are likely to change
■ Proven that test users can take them
seriously
■ Proven effective in design evaluations
25CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Testimonial
■ A former student, after doing project in
textbook author's course:
After doing some of the tests I have to concede that paper
prototypes are useful. Reviewing screenshots with the
customer did not catch some pretty obvious usability
problems and now it is hard to modify the computer
prototype. Another problem is that we did not get as complete
a coverage with the screenshots of the system as we thought
and had to improvise some functionality pretty quickly. I think
someone had told me about that . . . .
26March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Medium-fidelity prototypes
■ Sometimes you need a prototype with a level in between low and high fidelity
■ Usually means wireframes because wireframes can be made at almost any level of fidelity
■ Good for intermediate design and early detailed design
■ To show– Layout
– Breadth of user interface objects
– Some work flow
27CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
High-fidelity prototypes
■ Include details of appearance and interaction behavior
■ Required to evaluate design details
■ How users can see complete (in sense of realism) design
■ Still less expensive and faster than programming final product
■ Useful as advance sales demos
– For marketing
– As demos for raising venture capital
28CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Interactivity of prototypes
■ Another dimension for classifying types of
prototypes
29CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
“Click-through” prototype
■ Some ability to respond to user actions
■ Show interaction flow and some kinds of behavior
– Medium-fidelity prototype with some active links or buttons
– Allows sequencing through screens by clicking
– Usually no more functionality than that
■ Wireframes are good for this
30CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
A fully-programmed prototype
■ Expensive, limited call for this
■ Good if you really need full-system
operational prototype
31CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
“Wizard of Oz” prototypes
■ “Pay no attention to the man behind the
curtain”
■ Deceptively simple
■ Appearance of a high degree of
interactivity
■ Highly flexible prototype
32CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
“Wizard of Oz” prototypes
■ Simulate behavior
– In complex situations
– Where user inputs are unpredictable
■ Two connected computers, each in a
different room
– User’s computer connected to evaluator’s
computer
33CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
“Wizard of Oz” prototypes
■ Input actions sent to hidden person at evaluator’s computer
■ Sends appropriate simulated output back to user’s computer
■ Gives designers an idea of what
shoulda/coulda been done by the
interaction design
34CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Mockups for physical actions
■ Support physicality as a primary
characteristic of product or system
■ Design comes alive in a 3D, embodied,
and tangible way
35March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Physical mockups for physical interactivity
■ Example, handheld device
■ Mobile device that users might hold in
their hands
■ Or a system might be “physical” like a
kiosk
■ Good for evaluating emotional impact
36CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Physical mockups
■ Use materials at hand: cardboard, wood,
or metal
■ Glue on simulated buttons
■ Use real hardware controls such as push
buttons, tilt buttons, sliders
– Example: knobs and dials, rocker switch
– Example: joystick from an old Nintendo game
37CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Paper-in-device mockup prototype
■ Especially for mobile applications
■ Draw prototype screens on paper
■ Scan and load into device
■ Display as sequence of digital images in
response to user navigation
– Using touches or gestures that device
already can recognize
38CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Animated prototypes
■ Video animations, usually based on series
of sketches
■ Storyboard frames in “flip book” style
sequence on video
■ Can be very engaging and stimulating of
discussion
39CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Choosing right kind of prototype
■ Choosing the right
– Breadth
– Depth
– Level of fidelity
– Amount of interactivity
■ See text for this discussion
40CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Using right level of fidelity
■ For current stage of progress
■ Using right level of fidelity for design
perspective being addressed
– Ecological
– Interaction
– Emotional
41CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Paper prototypes
■ More flexible and nimble than any level of
programming
■ Paper prototypes for different stages of
development
– Design Reviews and Demos
■ No functionality or interaction
■ You are the driver; not user
42CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Paper prototypes
■ Paper prototypes for different stages of
development
– Hand-drawn paper prototypes
– Computer-printed paper prototypes
43CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
How to make an effective paper prototype
■ Start by setting a realistic deadline
– This activity can be a time sink
– Time management is essential
44CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
How to make an effective paper prototype
■ Gather a set of paper prototyping
materials– Blank plastic transparency sheets– Colored marking pens– Sheets of plain white paper– Scissors– Scotch tape– Wite-out– Ruler– Post-its
45March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
How to make an effective paper prototype
■ Work fast
■ Do not color within the lines
■ Use everything you have worked on so far
for design– Conceptual design– Design scenarios– Ideation– Personas– Storyboards
46March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Make an easel
■ To align screen and user interface object
sheets of paper and plastic
47March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Make underlying paper foundation “screens”■ Use full-size paper sheets that fit into
easel
48March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Paper cutouts on plastic for all moving parts
■ Tape on full-
size
plastic “inter-
action sheets” to
lie over
paper base
49March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Creative drop-down menus
50March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Make highlights on plastic with “handles”
51CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Make interaction sheets modular
■ Include only small amount on each sheet
■ Build it up with layers - the less you put on
each layer
– The more modular
– The more reuse you will get
■ Get modularity by thinking about what
needs to appear by itself
– Will every single detail on here always
appear together?
52CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Be efficient
■ Reuse at every level
– Make copies of screen objects, etc.
■ Cut corners when it does not hurt things
– Example, use same screen for months in a
calendar
– Regardless of whether days of week are right
53CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
Make prototype support key tasks
■ Has to support
planned
evaluation
■ Make a “this feature
not yet implemented”message
54March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Create a way to manage complex task threads
55March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21
Pilot test thoroughly
■ Test, test, and test
56CS 350 Computer/Human Interaction - Lecture 21March 27, 2018
What happens to the prototype?
■ Generally, all of the code is discarded
– Rarely is best software platform for fast mockups the best for software production
– Code is never production quality
– If it is, prototyping was done wrong
■ Implementation of product is expected to be faithful to the intent and behavior of the prototype
– Sequencing, connections, look and feel
57March 27, 2018 CS 350 Computer/Human Interaction - Lecture 21