1. 1 CSE 3345 User interface design A software engineering perspective Chapter 1: Usability

2. 2 User Interface The User Interface is the part of the system that you see, hear and feel. –The UI accepts commands, displays results and displays status Technical Interfaces may exist between various SW and HW components and do not involve the (human) user. Software engineers are notorious for putting more emphasis on TI design than on UI design. They are both equally important.

3. 3 Courses? Manual? Fig 1.1A System interfaces System Hotline? User interfaces Accounting system Technical interfaces Factory

4. 4 User Interface All interactive computer systems should be easy to use. That is to say they have high usability. Contrary to popular belief, usability can be defined and measured. Quality factors in IT systems –correctness –availability –performance –security –ease of use (usability) –maintainability

5. 5 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

6. 6 Usability Factors Usability consists of six factors –Fit for use (supports the user’s needs) –Ease of learning –Task efficiency –Ease of remembering –Subjective satisfaction –Understandability (can the user formulate an accurate mental model) A dilemma - Usability is most accurately measured once the system is completed. Unfortunately, it is usually too expensive to make major changes at that stage of the project.

7. 7 Max three menu levels On-line help Windows standard ?? 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.??

8. 8 Usability Problems A usability problem is anything that hampers the user in carrying out a task. –A usability problem is a special kind of defect Usability problems are just as serious as other types of defects Systems with usability problems cannot be successfully mass marketed

9. 9 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 2Task failure 3Annoying 4Medium problem (succeeds after long time) 5Minor problem (succeeds after short time) Critical problem = Missing functionality, task failure, or annoying

10. 10 Usability Testing Usability testing involves non-traditional testing techniques such as … –Think-aloud test –Real system tests –Prototypes and mock-ups Test team members … –facilitator –log keeper –observer (optional support member) –user (actual user(s), not a developer)

11. 11 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...

12. 12 Plan test Test-users: choose actual users not IT professionals Test-tasks: choose realistic scenarios the the users will encounter in the real world Study system yourself: testers are not usually part of the actual design effort Carry out test Explain purpose: -Find problems when using the system -System’s fault - not yours Give task - think aloud, please Observe, listen, note down Ask cautiously: -what are you looking for? -why... ? Help users out when they are surely lost Report test results List the usability problems - within 12 hours (Fig 1.4 cont.)

13. 13 Heuristic Evaluation With heuristic evaluation a usability specialist reviews the user interface for perceived faults. Problem with HE: usability specialists are not true users. –What a usability specialist perceives as a problem a true user may not. –What a true users perceives as a problem may not be a problems to a usability specialists. Heuristic evaluation is not a substitute for usability testing.

14. 14 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

15. 15 Usability Measurements and Requirements All software systems are developed to meet a set of requirements. Types of requirements.. Functional requirements Non-functional requirements Usability requirements Usability requirements must be stated using a metric that can be tested against. Typical metrics… Time for user to complete task (aka performance measurement) Problem count (the number of problems a user encounters while carrying out a task) Key stroke count (not always helpful) Opinion poll

16. 16 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!

17. 17 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.

18. 18 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

19. 19 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 6 keystrokes @ 0.6 s3.6 s total system response time 8.0 s Total task time11.6 s Plus other user actions?

20. 20 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 Pros:Widely used. You may ask for any usability factor. Cons:Doesn’t match objective evidence. Only indications during development. Little feedback to developers. 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

21. 21 Opinion Polls Second law of usability: There is little correlation between subjective satisfaction and objective performance (evidence). Subjective satisfaction can be influenced by external factors. –The gender of the tester –Personal issues at home –Degree of job satisfaction –Friendliness of tester –Testing environment (are coffee and snacks available?) SOFTWARE USABILITY MEASUREMENT INVENTORY –SUMI Questionnaire ExampleSUMI Questionnaire Example

22. 22 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..

23. 23 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.

24. 24 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 The bottom line: There is no single best usability measurement, a combination of complementary measurements is required, and that combination will vary from project to project.