søren lauesen 1942born august 10th 1958(denmark’s computer runs) 1960high-school certificate...
TRANSCRIPT
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: [email protected] www.itu.dk/people/slauesen
User Interface Design1. Usability
Soren Lauesen, IT-University of CopenhagenE-mail: [email protected] 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