i213: user interface design & development

Post on 31-Dec-2015

41 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

i213: User Interface Design & Development. Marti Hearst Thurs, Feb 22, 2007. Spotted by Mike Wooldridge. http://www.flickr.com/photos/cardhouse/397124663/in/photostream/. Spotted by Mike Wooldridge. http://www.flickr.com/photos/cardhouse/397123933/in/photostream/. Outline. Finish up HE - PowerPoint PPT Presentation

TRANSCRIPT

i213: User Interface Design & Development

Marti HearstThurs, Feb 22, 2007

Spotted by Mike Wooldridge

http://www.flickr.com/photos/cardhouse/397124663/in/photostream/

Spotted by Mike Wooldridge

http://www.flickr.com/photos/cardhouse/397123933/in/photostream/

Slide adapted from James Landay

Outline

Finish up HELow-fidelity prototypingInformal user interfaces

Adapted from slide by James Landay

Results of Using HE

Single evaluator achieves poor results– only finds 35% of usability problems– 5 evaluators find ~ 75% of usability problems– why not more evaluators? 10? 20?

• adding evaluators costs more• adding more evaluators doesn’t increase the number of

unique problems found

Adapted from slide by James Landay

Decreasing Returns

problems found benefits / cost

(from Nielsen)

Caveat: these graphs are for a specific exampleThis is a controversial point.

Why Multiple Evaluators?

Every evaluator doesn’t find every problemGood evaluators find both easy & hard ones

Comments from CHI-Web

From Gilbert Cockton (2/19/02):– Inspection methods are discount methods for practitioners. They

are not rigorous scientific methods.– All inspection methods are subjective.– No inspection method can compensate for inexperience or poor

judgement.– Using multiple analysts results in an inter-subjective synthesis.

• However, this also a) raises the false alarm rate, unless a voting system is applied b) reduces the hit rate if a voting system is applied!

– Group synthesis of a prioritized problem list seems to be the most effective current practical approach.

In-Class Heuristic Evaluation

Windows Character Map Program

Slide adapted from James Landay

Why Do We Prototype?

Get feedback on our design faster– saves money

Experiment with alternative designsFix problems before code is writtenKeep the design centered on the user

Slide adapted from James Landay

Fidelity in Prototyping

Fidelity refers to the level of detailHigh fidelity?

– prototypes look like the final productLow fidelity?

– artists renditions with many details missing

Slide adapted from James Landay

Low-fidelity Sketches

Slide adapted from James Landay

Why Use Low-fi Prototypes?

Traditional methods take too long– sketches -> prototype -> evaluate -> iterate

Can simulate the prototype– sketches -> evaluate -> iterate– sketches act as prototypes

• designer “plays computer”• other design team members observe & record

Kindergarten implementation skills– allows non-programmers to participate

Slide adapted from James Landay

Low-fi Storyboards

Where do storyboards come from?– Film & animation

Give you a “script” of important events– leave out the details – concentrate on the important interactions

Sketches for theInk ChatSystem

Paper prototyping

Main idea:– Sketch out prototypes of the interface on paper– Potential users “walk through” task scenarios using the paper

interface– A designer “plays computer”– Change the design on-the-fly if helpful

Widely practiced in industry– Sounds silly at first, but is surpringly effective– Helps people work together on the design

Readings by Rettig, Cooper, Klee, Spool’s group– This discussion primarily follows Rettig’s article

Slide adapted from James Landay

The Materials

Large, heavy, white paper (11 x 17)5x8 in. index cardsPost-it notesTape, stick glue, correction tapePens & markers (many colors & sizes)

Transparencies (including colored)Colorforms (toy stores)Scissors, X-acto knives, etc.

Slide adapted from James Landay

Constructing the Model

Set a deadline– don’t think too long - build it!

Draw a window frame on large paperPut different screen regions on cards– anything that moves, changes, appears/disappears

Ready response for any user action– e.g., have those pull-down menus already made

Use photocopier to make many versions

Slide adapted from James Landay

Preparing for a Test

Select your participants– understand background of intended users– use a questionnaire to get the people you need– don’t use friends or family

Prepare scenarios that are– typical of the product during actual use– make prototype support these (small, yet broad)

Practice running the computer to avoid “bugs”

Slide adapted from James Landay

Conducting a Test

Three or Four testers (preferable)– greeter - puts users at ease & gets data– facilitator - only team member who speaks

• gives instructions & encourages thoughts, opinions– computer - knows application logic & controls it

• always simulates the response, w/o explanation– observer(s) - take notes & recommendations

Typical session is approximately 1 hour– preparation, the test, debriefing

Slide adapted from James Landay

Conducting a Test (cont.)

Greet– get forms filled, assure confidentiality, etc.

Test– facilitator hands written tasks to the user

• must be clear & detailed– facilitator keeps getting “output” from participant

• “What are you thinking right now?”, “Think aloud”– observe -> no “a-ha”, laugh, etc.

Slide adapted from James Landay

Conducting a Test (cont.)

Debrief– fill out post-evaluation questionnaire– ask questions about parts you saw problems on– gather impressions– give thanks

Slide adapted from James Landay

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

Make changes & iterate

Potential difficulties

Content-centric Interfaces – Dynamic or static; both are ill-suited

• Use printed output for large sets of text

– For search/database applications• Have pre-planned searches

– Even though not very realistic• Write up search results on the fly

– Maybe have a printer nearby that can produced typed results• Bottom line: can only prototype the main interaction this way; search

needs to be hooked up to really test the search mechanism

Potential difficulties

Interfaces that use animation / dynamic graphics– IUE’s answer: maybe it isn’t all that usable to have

flash– Broader answer:

• Only testing the main functionality, not the finer points• The interface should also work without the flash

– Use transparencies, etc, for important rollovers.

Slide adapted from James Landay

Advantages of Low-fi Prototyping

Takes only a few hoursCan test multiple alternatives Can change the design as you test – If users are trying to use the interface in a way you

didn’t design it – go with what they think! Adapt!

Allows designers to work together

Examples from Prior Classes

Telebears example: interaction flow

Telebears example

Telebears example: Welcome, Registration time

Telebears example: Welcome, Not Registration time

Telebears example: Task 3: Plan Schedule

Telebears example: Task 2: Switching discussion sections

Telebears example: Task 4: Adding a course

Sho, Shamma, von Krogh, Johnstad

Sho, Shamma, von Krogh, Johnstad

Costa, Chopra, Orr, Stetson

Brandt, Falk, McMahon

Hernandez, Liang

Designing a content pageUsing low-fi techniques

Combine low-fi paper prototyping and card sorting– Idea from Peter Merholtz

Start with a page with all the features you might wantCut it up into pieces Have people arrange the components– One set of users sorts into groups, as in card sorting for

categories– Another set of users lays out the information in a way that

would work well for them given certain tasks.

Slide adapted from James Landay

Drawbacks of Current Tools

Require specification of lots of detail– must give specific instance of a general idea

• e.g., exact widgets, fonts, alignments, colors– designers led to focus on unimportant details– evaluators focus on wrong issues

Take too much time to use– poor support for iterative design

• sketched interface took 5 times longer with traditional tool (no icons)

Slide adapted from James Landay

DENIM: Designing Web Sites by Sketching

Early-phase information & navigation designIntegrates multiple views– site map – storyboard – page

sketch

Supports informal interaction– sketching, pen-based interaction

Slide adapted from James Landay

Designing Interfaces with Denim

1) Designer sketches ideas rapidly with electronic pad and pen– recognizes widgets – easy editing with gestures

2) Designer or end-user tests interface– widgets behave – specify additional behavior visually

3) Automatically transforms to a “finished” UI

Slide adapted from James Landay

Specifying Behaviors

Storyboards– series of rough sketches depicting changes in

response to end-user interactionExpresses many common behaviors

before after

Sequencing behavior between widgets

Slide adapted from James Landay

Denim Storyboards

Copy sketches to storyboard windowDraw arrows from objects to screens

Switch to run mode to testDenim changes screens on mouse clicks

Next Time

In-class project workCome prepared to work in class on your low-fi prototypes.

top related