Søren Lauesen 1942Born August 10th 1958(Denmark’s computer runs) 1960High-school certificate 1962Employed at Regnecentralen 1965Masters, math-physics 1969External lecturer DIKU, computer science education 1973Employed at Brown Boveri 1975Employed at ILO in Ghana 1976Employed at DIKU 1979Business diploma, accounting 1979Employed at NCR's development centre 1985Employed at CBS, DØK education 1999Employed at the IT-University

User Interface Design 1. Usability Soren Lauesen, IT-University of Copenhagen

Extra 1: System development - bridging the gaps Users Programmers Business analysts Usability specialists User interface How and when? Project management 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 System Hotline? User interfaces Accounting system Technical interfaces 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 make a good user interface Quality factors: Correctness Availability Performance Security Ease of use Maintainability... Functionality: Necessary features see, edit create, delete Database

Max three menu levels On-line help Windows 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 learning c.Task efficiency d.Ease of remembering e.Subjective satisfaction f.Understandability Measurable Priorities vary Responsibility? Programmers? Other developers? User department? Game programs: a.??

Examples: The system works as intended by the programmer, 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: 1Missing functionality or bug 2Task failure 3Cumbersome 4Medium problem (succeeds after long time) 5Minor 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 User Performs tasks Thinks aloud Logkeeper Listens Records problems Facilitator Listens Asks as needed I try this because... User doesn’t notice...

Purpose: Find usability problems Extra 2: Usability test – with mockup User Performs tasks Thinks aloud Logkeeper Listens Records problems Facilitator Listens Asks as needed I try this because... User doesn’t notice... Redesign Test again

Plan Test-users: Test-tasks: Study system yourself Carry out Explain purpose: -Find problems when using the system -System’s fault - not yours Give task - think aloud, please Observe, listen, note down (test log) Ask cautiously: -what are you looking for? -why... ? Help users out when they are surely lost Test report List 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

Purpose: Find usability problems Usability specialist looks at system using common sense and/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

ATM Users: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 system Users: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 measure Risky!

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 customers should succeed. Task 2 harder. Open target Reqs:18 out of 20 must succeed within ____ min. We expect around 2 min. Specify how, what, and expectations. Wait and see what is possible.

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 to measure 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 time s3.6 s total system response time 8.0 s Total task time11.6 s Plus other user 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 agreeneutraldisagree The system was easy to learn The system is easy to use The system helps me... It is fun to use I 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 large PIN 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 and identify deviations from guideline X. (Or ask two experts 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 for use Ease of learning Task efficiency Ease of remember Subjective satisf. Understandability ?? Highly useful Some use Indications only Development, early Development, late Buying a system