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

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.

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

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

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

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

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

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

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

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

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

Observed results

■ Values measured while observing users

perform tasks during evaluation sessions

■ Allows direct comparison between

specified levels and actual results

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

Depth and breadth of prototypes

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)

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

“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

Local prototypes

■ Small area where horizontal and vertical

slices intersect

■ Used to evaluate design alternatives

■ For particular isolated interaction details

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

Fidelity of prototypes

■ Reflects how “finished” prototype is

perceived to be by customers and users

– Not how authentic or correct underlying code

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

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

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 . . . .

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

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

Interactivity of prototypes

■ Another dimension for classifying types of

prototypes

“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

A fully-programmed prototype

■ Expensive, limited call for this

■ Good if you really need full-system

operational prototype

“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

■ 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

■ 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

Mockups for physical actions

■ Support physicality as a primary

characteristic of product or system

■ Design comes alive in a 3D, embodied,

and tangible way

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

■ Good for evaluating emotional impact

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

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

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

Choosing right kind of prototype

■ Choosing the right

– Breadth

– Depth

– Level of fidelity

– Amount of interactivity

■ See text for this discussion

Using right level of fidelity

■ For current stage of progress

■ Using right level of fidelity for design

perspective being addressed

– Ecological

– Interaction

– Emotional

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

Paper prototypes

■ Paper prototypes for different stages of

development

– Hand-drawn paper prototypes

– Computer-printed paper prototypes

How to make an effective paper prototype

■ Start by setting a realistic deadline

– This activity can be a time sink

– Time management is essential

■ 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

■ 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

Make an easel

■ To align screen and user interface object

sheets of paper and plastic

Make underlying paper foundation “screens”■ Use full-size paper sheets that fit into

Paper cutouts on plastic for all moving parts

■ Tape on full-

plastic “inter-

action sheets” to

lie over

paper base

Creative drop-down menus

Make highlights on plastic with “handles”

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?

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

Make prototype support key tasks

■ Has to support

planned

evaluation

■ Make a “this feature

not yet implemented”message

Create a way to manage complex task threads

Pilot test thoroughly

■ Test, test, and test

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

CS 350 COMPUTER/HUMAN INTERACTIONuenics.evansville.edu/~hwang/s18-courses/cs350/lecture21...Ticket...

Documents