Søren Lauesen

1942 Born August 10th1958 (Denmark’s computer runs)1960 High-school certificate1962 Employed at Regnecentralen1965 Masters, math-physics1969 External lecturer DIKU,

computer science education1973 Employed at Brown Boveri1975 Employed at ILO in Ghana1976 Employed at DIKU1979 Business diploma, accounting1979 Employed at NCR's

development centre1985 Employed at CBS, DØK

education1999 Employed at the IT-University

E-mail: slauesen@itu.dk www.itu.dk/people/slauesen

User Interface Design1. Usability

Soren Lauesen, IT-University of CopenhagenE-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen

Extra 1: System development - bridging the gaps

Users Programmers

Businessanalysts

Usabilityspecialists

User interfaceHow and when?

Projectmanagement

Course focus: Production systems for professionals,e.g. hotel reception, health records, call center . . .

Less focus on: Public sites, Facebook, games . . .

Courses?

Manual?

Fig 1.1A System interfaces

SystemHotline?

User interfaces Accounting

system

Technicalinterfaces

Factory

All factors important.

Hard to measure,

but possible.

Fig 1.1B Quality factors

Easy to make a user interface:Just give access to the database

Hard to makea good user interface

Quality factors:CorrectnessAvailabilityPerformanceSecurityEase of useMaintainability. . .

Functionality: Necessary features

see, edit

create,

delete

Database

Max three menu levelsOn-line helpWindows standard (or WCAG10 from W3C)

??

Fig 1.2 What is usability?

Usability factors:

a. Fit for use (adequate functionality)

Ease of use:b. Ease of learningc. Task efficiencyd. Ease of rememberinge. Subjective satisfactionf. Understandability

Measurable

Priorities vary

Responsibility? Programmers?

Other developers?

User department?

Game programs:

a. ??

Examples:The system works as intended by theprogrammer, but the user:

P1. Cannot figure out how to start the search. Finally finds out to use F10.

P2. Believes he has completed the task, but forgot to push Update.

P3. Sees the discount code field, but cannot figure out which code to use.

P4. Says it is crazy to use six screens to fill in ten fields.

P5. Wants to print a list of discount codes, but the system cannot do it.

Fig 1.3 Usability problems

Severity classes:

1 Missing functionality or bug

2 Task failure

3 Cumbersome

4 Medium problem (succeeds after long time)

5 Minor problem (succeeds after short time)

Critical problem =Missing functionality, task failure, or cumbersome- to many users

Purpose:Find usability problems

Fig 1.4 Usability test - think aloud

UserPerforms tasksThinks aloud

LogkeeperListensRecords problems

FacilitatorListensAsks as needed

I try this because ...

User doesn’tnotice ...

Purpose:Find usability problems

Extra 2: Usability test – with mockup

UserPerforms tasksThinks aloud

LogkeeperListensRecords problems

FacilitatorListensAsks as needed

I try this because ...

User doesn’tnotice ...

RedesignTest again

PlanTest-users:Test-tasks:Study system yourself

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

Test reportList the usability problems - within 12 hours

Fig 1.4 (cont.) Usability test – check list

Fig 13.5B Test tasks - 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.

Fig 13.7B Log from usability test

Fig 13.7C Test report

Room allocation system, hand-drawn mockup, version 6.Usability test 5. Jan 1995. Test users: HR and SLObserved problems (with severity class)P1. (HR, SL: Minor)

In RoomRequests: Not obvious what #hours means. (It means number of hours per week.)P2. (HR, SL: Cumbersome)

A request line concerns an interval of weeks. There is a need to split it in two or more to reflectseveral intervals of weeks. Possible with cut and paste, but a split-function might be convenient.

P3. (SL: Minor)In RoomRequests: If there are empty lines, you should be able to fill them in without first usingNewRequest.

P4. (SL: Medium)RequestDetails: Hard to see the new data, e.g. "count", because the old data from the request lineare here too, but in a new way. You cannot see what is new and what is old.

P5. (HR, SL: Minor)When copying a request line: The copy will often conflict with the new line. Important to allowcopying and then correct the copy. Suggestion from HR: don't warn until you leave the line.

P6. (HR: Task failure)In RoomRequests: The labels Class/Responsible and Course/Activity are not intuitive. Class andCourse are also easy to mix up.

P7. (HR: Medium; SL: Minor)Course screen: "Requested" not intuitive.

P8. (HR: Medium)Requesting additional rooms (team exercises) in connection with lectures hard to figure out.Attempts in vain through Rooms.

Purpose: Find usability problems

Usability specialist looks at systemusing common senseand/or guidelines

The specialist lists problems(Consults with other experts)

Fig 1.5 Heuristic evaluation

First law of usability: Heuristic evaluation has only 50% hitrate

Actual problems

Predicted problems

False problems

Missed problems

Expert - reviewer

ATMUsers: 20 bank customers, random selection.Task 1: Withdraw $100 from ATM. No instructions.Measure: How many succeed in 2 min?

Task 2: Withdraw as much as possible ($174)Measure: How many succeed in 5 min?Reqs: Task 1: 18 succeed.

Task 2: 12 succeed.

How to measure

What to measure

Requirement - target

Fig 1.6A Measuring usability - task time (performance)

Pros: Classic approach. Good when buying.

Cons: Not good for development.Not possible early. Little feedback.

Internal ordering systemUsers: 5 secretaries in the company.

Have tried the internal ordering system.Have not used it for a month.

Task 1: Order two boxes of letter paper + . . .Measure: Average time per user.Reqs: Average time below 5 min.

What to measureRisky!

Users: 20 bank customers ...

Measure: In 2 min?

Reqs: Task 1: 18 succeed.Task 2: 12 succeed.

Fig 1.6B Choosing the numbers

Why 20?Cost versus reliability.During development:One, later two, later ...

Why 2 mins?Best practice,ideal way ...

Why 18?90% of customersshould succeed.Task 2 harder.

Open target

Reqs: 18 out of 20 mustsucceed within ____ min.We expect around 2 min.

Specify how, what, and expectations.Wait and see what ispossible.

Users: 3 potential users. Think-aloud test. Record usability problems.

Task 1: Order two boxes of letter paper + . . .Task 2: . . .

Measure: Number of critical problems per user.Number of medium problems on list.

Reqs: Max one user encounters critical problems.Max 5 medium problems on the list.

What to measure

Requirement

Fig 1.6C Measuring usability - Problem counts

Pros: Possible early - mockup sufficient. Good feedback to developers.

Cons: Best for ease of learning.Only indications for other factors.

How to measure

Task 1: Withdraw a standard amount from ATM.Task 2: . . .

Measure: Number of keystrokes and mouse clicks.

Reqs: Max keystrokes 6 - incl. PIN code.Total system response time max 8 s.

How tomeasure

What to measure

Requirement

Fig 1.6D Measuring usability - Keystroke counts

Pros: No users needed. Possible early - mockup sufficient.

Cons: Not sure users find the fast way.Only task efficiency.

Total task time6 keystrokes @ 0.6 s 3.6 stotal system response time 8.0 sTotal task time 11.6 s

Plus otheruser actions?

Ask 20 novice users to complete the questionnaire.

Measure: Count number of entries per box.

Reqs: 80% find system easy to learn.50% will recommend it to others.

How to measure

What to measure

Requirement

Fig 1.6E Measuring usability - Opinion poll

Questionnaire agree neutral disagreeThe system was easy to learnThe system is easy to useThe system helps me . . .It is fun to useI will recommend it to others

Pros: Widely used. You may ask for any usability factor.

Cons: Little correlation with objective evidence.Only indications during development.Little feedback to developers.

Second law of usability

Ask 5 potential ATM users what these error messages mean:

Amount too largePIN code invalid . . .

Ask them also:What would the system do if . . .

Measure: Assess answers on scale A-D.

Reqs: 80% of answers marked A or B.

How to measure

What to measure

Requirement

Fig 1.6F Measuring usability - Score for understanding

Pros: Easy way to test understandability.Best way to cover error messages. Useful both early and late in development.

Cons: Only measures understandability..

Ask an expert to review the user interface andidentify deviations from guideline X. (Or ask twoexperts to come up with a joint list.)

Measure: Number of deviations per screen.

Reqs: At most one deviation per screen.

How to measure

What to measure

Requirement

Fig 1.6G Measuring usability - Guideline adherence

Pros: Adherence helps users switch between systems.Company-specific guidelines for internal systems can help even more.

Cons: Cannot guarantee high usability.Developers find guidelines hard to follow- examples help best.

Fig 1.6H Which usability measure?

Task time

Problem counts

Keystroke counts

Opinion poll

Score for underst.

Guidelines

Fit

fo

r u

se

Eas

e o

f le

arn

ing

Tas

k ef

fici

ency

Eas

e o

f re

mem

ber

Su

bje

ctiv

e sa

tisf

.

Un

der

stan

dab

ilit

y

??

Highly useful

Some use

Indicationsonly

Dev

elo

pm

ent,

ear

ly

Dev

elo

pm

ent,

lat

e

Bu

yin

g a

sys

tem