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

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

is


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

kiosk

■ 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

easel


Paper cutouts on plastic for all moving parts

■ Tape on full-

size

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


Date post:	10-May-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

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

Documents