CSE 3345User interface design

A software engineering perspective

Chapter 8: Prototypes and Defect Correction

What Paper Prototyping Is Good For

• Concepts and terminology – Do the target users understand the terms you've chosen? Are there key

concepts they gloss over or misconstrue?

• Navigation/workflow – If there's a process or sequence of steps, does it match what users expect?

Do they have to keep flipping back and forth between screens? Does the interface ask for inputs that users don't have, or don't want to enter?

• Content– Does the interface provide the right information for users to make

decisions? Does it have extra information that they don't need, or that annoys them?

• Page layout – Although your scribbled screens may not be pretty, you'll still get a sense of

whether users can find the information they need. Do you have the fields in the order that users expect? Is the amount of information overwhelming, not enough, or about right?

• Functionality – You may discover missing functionality that users need, or functionality

you'd planned but users don't care about.

What Paper Prototyping Isn’t Good For

• Technical feasibility – Paper prototypes don't demonstrate technical capability. It's

possible to create a paper prototype that can't actually be implemented. There should always be at least one person involved who understands the technical constraints.

• Download time or other response time. – Because a person simulates the behavior of the computer, the

"response time" is artificial.

• Colors and fonts – If you really need to see how something looks on a computer

screen, (handwritten) paper prototyping can't show you that.

Procedure to Make a Paper Mockup

• Make a full graphical (hand drawn or tool-drawn) version of each page (window).– Pages should be drawn with empty data fields.

• Copy the pages and fill in the necessary data for the specific tests you plan to run.

• Make the necessary menus (drop-down and pop-up).• Make message boxes for all error and information

messages.– Make a few empty message boxes that can be customized

during testing

• Make drop-down lists for combo boxes and any other pieces of the interface that the user might see.

• A state diagram will often be helpful ….

Procedure to Make a Paper Mockup

FindRooms, Repair, Add ...FindGuest, FindStay ...

NewStay

NewGuest

OpenStay

AddServiceDelService ...

FindRoomsBook, CheckinPrintConfirm, CheckoutAddServiceLine ...

BookCheckin

Return

Return

Ret

urn

Rec

Bre

akfa

st

Return

EditService

FindRooms. . .

vwServiceListvwBreakfast

vwRooms

vwStay(new)vwRooms

vwFindGuest

vwRooms

vwStay(rec)

pSearch

pStay(new)

pStay(rec)

pBreakfast pServiceList

CancelStay

Good and Bad Error Messages

Good error messages are1. Friendly (don’t blame the user)2. Precise (what is wrong?)3. Constructive (what to do?)4. Prevented (cannot occur)

Example:User clicks Check Inon the Stay window

Be precise:

Be con-structive:

Evaluation and Usability Testing

• Make heuristic evaluations ahead of time to find potential problems.– Remember the first law of usability: Heuristic evaluation has only

a 50% hit-rate.

• Compose tests and metrics by which to measure success

• Run the usability tests.– Test team members …

• facilitator• log keeper• observer (optional support member)• user (actual user(s), not a developer)

• Record defects, evaluate results, fix agreed upon problems, re-test.

Evaluation and Usability TestingPlan testTest-users: choose actual users not IT professionalsTest-tasks: choose realistic scenarios the users will encounter in the real worldStudy system yourself: testers are not usually part of the actual design effort

Carry out testExplain purpose: - Find problems when using the system - System’s fault - not yoursGive task - think aloud, pleaseObserve, listen, note downAsk cautiously: - what are you looking for? - why . . . ?Help users out when they are surely lost

Evaluation and Usability Testing

• Planning the test tasks– Tests need to reflect real-world usage of the system.– Each test needs to reflect a real and meaningful unit of work.– Have an assortment of tests at various levels of difficulty.– Start with easy tests first.– The tests should be independent of each other.– The task needs to be stated without hints on how to carry

out the task.

Examples of Hidden Help

Version A:

John Simpson wants to check in. Find him on the FindGuest screen.

Double click to open his Stay screen.

Version B:

John Simpson wants to check in. He has stay number 710.

Version C:

John Simpson arrives 23rd October. He says there should be two rooms for him.

If asked: He cannot remember his booking number (or stay number).

He lives 456 Orange Grove, Victoria Australia (can’t remember zip code)

He leaves 26th October.

Hotel System Paper Mockup

11

Hotel System Paper Mockup

12

Hotel System Tool-based Mockup

Menus

Drop-down lists

Message boxes

Platform surprises: Only main menus

Name part ?

Two Find buttons

Earlier: Free from + Free to

State shown

Tabs rather thanone long list

Buttons, not menus

Same window for create and edit

Hotel System Tool-based Mockup

One Find

Stays and guests

Live search

Two datesTwo dates

Expert users

Hotel System Final Product

Updates immediately,but no OK is scaring

Hotel System Final Product

Defects and Their Cure

• Create a list for recording defects. Include the following data for each defect.– Unique defect ID number– Description of the defect– Test case that revealed the defect– Proposed fix or resolution– Defect status (pending, rejected, ignore, training, done,

release x, duplicate). See page 284 for defect status definitions.

Fig 8.3A Defects and their cureDefects from early usability testID In Find Guest window Cure StatusD1 The Stay concept is not understood

by some usersPop-up texts helped somewhat. Trainingneeded in hotel procedures.

Training

D2 Doesn't notice the Find button Live search finally cured the problem. DoneD3 When you select a certain date, why

does the list show earlier dates too?Three changes: Two dates - one for arrivaldate and one for room search. Better labels.List all stays and all guests that match.

Done

D4 Not visible whether the guests havebeen checked in or not

The status is now shown on the guest list aswell as in the stay window.

Done

. . .

Defects detected during systematic designID Cure StatusD100

Do users understand that data in theBreakfast window automatically endup in the stay windows?

An OK-button helped. Automatic update ofany open stay window also gives somefeedback.

Done

D101

Receptionist should check creditcard or get deposit before check-in

Check-in insists on paymethod to be filled in.The rest of the credit checking is presentlymanual.

Release 1

D102

Do users understand that guestname and address is repeated in allhis stay windows - while paymethodis individual for each stay?

Mostly yes. No serious problem. Done

D103

How to show long stays or stays withmany rooms?

New presentation of room bookings gave thenecessary overview.

Done

. . .

Problems, Causes and Solutions

• Finding the cause of a user’s problem leads to finding a solution sooner.• Encourage the user to think out loud• Ask the user why he did something but only after the test

has been completed.

• Just because one user has a problem with some feature of the system does not mean it is a problem.• Run each test case with several users. Only when a

significant number of the users have a problem with a feature is it a problem.

User

Problem

Observation

SolutionCause

severity, time

Fig 8.4 Problem - cause - solution

ID Problem Observation Likely causes Potential curesTask: Check in

D7 Doesn't see that the guestis on the list already.

B: AnnoyingM: Annoying

Read top-down and stops atfirst seemingly relevantthing: name.Doesn't understand thatthey are search criteria.

Put list on top, criteria below.

Signal that it is a criterion, e.g. with(any).Live search to give immediatefeedback.

D8 Doesn't understand whythe list becomes empty(made a spelling error).

B: Medium problem Doesn't understand thematch principle.

Don't just make it empty - say why.Live search to catch the errorimmediately.

D9 Believes the task iscomplete when she seesthe guest on the list.

M: Task failure Lacks domain knowledge. Guidance on the screen?Tutorial or mini-course?

D10 Doesn't understand thatthe stay screen must beopened.

B: Task failureM: Task failure

Lacks domain knowledge.No signal that it is possible.

As D8.Show the state and an invitingbutton on the line.

D11 Fills in search criteria,believing they are datafields.

B: Minor problemM: Task failure

Doesn't relate it to theheading.The two things look alike.

As D7.Redesign so that search criteriaalso are data fields.

Paper Prototype Examples

Paper Prototype Examples

Paper Prototype Examples

Paper Prototype Examples

Other Resources

• Template for Usability Test Tasks• Rules for Usability Test Observers