Lecture 17 - University of...

November 4, 2014 CS 350 - Computer/Human Interaction 1

Lecture 17

● Questions about the group project?● Project work day on Thursday

– Groups must meet

– Can meet anywhere, including KC-136

– Instructor will be in her office to answer questions

– Instructor can provide sticky notes if want to create a WAAD

– Suggest: finalize a system concept statement and start creating usage scenarios


Outline

● Wireframes from last week● Chapter 10

– UX goals, metrics, targets

● Chapter 11– Breadth vs. depth

– Fidelity

– Interactivity

– Paper prototypes


Introduction: 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


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


UX measures

● General user experience characteristic● Measured with respect to interaction design● Obtain quantitative data

– Observable user performance

– User opinion

● TKS example– Initial user performance


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 is too late and too expensive


Depth and breadth of a prototype

● To be fast and changed easily, 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 a prototype


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

● Supports physicality as a primary characteristic of product or system

● Design comes alive in a 3D, embodied, and tangible way


Physical mockups forphysical 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 aneffective 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 paperfoundation “screens”

● Use full-size paper sheets that fit into easel


Paper cutouts on plastic forall moving parts

● Tape on full-size plastic “inter-action sheets” to lie over paper base


Making paper prototypes

● Be creative● Draw by hand● Use simple graphics or paint programs

– Import images such as buttons

– Resize, label, and print in color


Creative drop-down menus


Make highlights on plasticwith “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 imple-mented” message


Create a way to managecomplex 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

Lecture 17 - University of...

Documents

Transcript of Lecture 17 - University of...