1. A software engineering perspective
User interface design
A software engineering perspective
Soren Lauesen
Slides for Chapter 1
November 2004
© 2005, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

2. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

3. User Interface The part of the system that you see, hear and feel.
Interactive computer systems
You initiate some action and system responds with some output
System prompts you to do something, and you have to respond with more inputs
These interactions take place through the user interface.
User Interface Design

4. User interfaces Technical interfaces
Slide 4
Fig 1.1A System interfaces
Courses?
User
interfaces
Accounting
system
Technical
interfaces
Factory
Hotline?
System
Manual?
User Interface Design

5. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

6. Design of user interfaces
In principle, it is easy to make a user interface.
Just make it possible for the user to see and change all the data in the system.
But it is not easy to make a user interface that is easy to use.
Ease of use is hard to define.
Ease of use is hard to evaluate.
User Interface Design

7. Easy to make a user interface: Just give access to the database
Fig 1.1B Quality factors
Slide 7
Easy to make a user interface:
Just give access to the database
Hard to make
a good
user interface
see, edit
create, delete
Database
Quality factors:
Correctness
Availability
Performance
Security
Ease of use
Maintainability
. . .
Functionality:
Necessary features
All factors important.
Hard to measure,
but possible.
User Interface Design

8. Usability motivations
Many interfaces are poorly designed and this is true across domains:
Life-critical systems
Air traffic control, nuclear reactors, power utilities, police & fire dispatch systems
High costs, reliability and effectiveness are expected
Length training periods are acceptable despite the financial cost to provide error-free performance and avoid the low frequency but high cost errors
Subject satisfaction is less an issue due to well motivated users
From Shneiderman, Ch. 1
User Interface Design

9. Usability motivations (cont.)
Industrial and commercial uses
Banking, insurance, order entry, inventory management, reservation, billing, and point-of-sales systems
Ease of learning is important to reduce training costs
Speed and error rates are relative to cost
Speed of performance is important because of the number of transactions
Subjective satisfaction is fairly important to limit operator burnout
User Interface Design

10. Usability motivations (cont.)
Office, home, and entertainment applications
Word processing, electronic mail, computer conferencing, and video game systems, educational packages, search engines, mobile device, etc.
Ease of learning, low error rates, and subjective satisfaction are paramount due to use is often discretionary and competition fierce
Infrequent use of some applications means interfaces must be intuitive and easy to use online help is important
Choosing functionality is difficult because the population has a wide range of both novice and expert users
Competition cause the need for low cost
User Interface Design

11. Usability motivations (cont.)
Exploratory, creative, and cooperative systems
Web browsing, search engines, artist toolkits, architectural design, software development, music composition, and scientific modeling systems
Collaborative work
Benchmarks are hard to describe for exploratory tasks and device users
With these applications, the computer should "vanish" so that the user can be absorbed in their task domain
User Interface Design

12. Usability motivations (cont.)
Social-technical systems
Complex systems that involve many people over long time periods
Voting, health support, identity verification, crime reporting
Trust, privacy, responsibility, and security are issues
Verifiable sources and status feedback are important
Ease of learning for novices and feedback to build trust
Administrators need tools to detect unusual patterns of usage
User Interface Design

13. Goals for our profession
Potential research topics
Reducing anxiety and fear of computer usage
Graceful evolution (novice to expert)
Specification and implementation of interaction
Direct manipulation
Input devices
Online assistance
Information exploration
From Shneiderman, Ch. 1
User Interface Design

14. Goals for our profession (cont.)
Providing tools, techniques, and knowledge for system implementers
Rapid prototyping is easy when using contemporary tools
Use general or self-determined guideline documents written for specific audiences
To refine systems, use feedback from individual or groups of users
Raising the computer consciousness of the general public
Many novice users are fearful due to experience with poor product design,
Good designs help novices through these fears by being clear, competent, and nonthreatening
User Interface Design

15. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

16. Responsibility? Programmers?
Slide 16
Fig 1.2 What is usability?
Max three menu levels
On-line help
Windows standard ??
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
Responsibility? Programmers?
Other developers?
User department?
Measurable
Priorities vary
Game programs:
a. ??
User Interface Design

17. Usability factors
Fit for use – the system supports the processes and tasks that the user needs to perform.
Ease of learning – the system is easy to learn for various groups of users.
Task efficiency – frequent users can perform their tasks efficiently.
Ease of remembering – occasional users find it easy to remember what to do.
Subjective satisfaction - how satisfied is the user?
Understandability – it is easy to understand the system’s behavior, especially in error cases.
User Interface Design

18. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

19. Usability problems
Anything about the application that hampers a user in performing his task.
Usability problems are a special kind of software defect. The system works as intended by the developer, yet the user finds it hard to get useful work out of the system.
User Interface Design

20. Fig 1.3 Usability problems
Slide 20
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.
Severity classes:
1 Missing functionality
2 Task failure
3 Annoying
4 Medium problem (succeeds after long time)
5 Minor problem (succeeds after short time)
Critical problem =
Missing functionality, task failure, or annoying
User Interface Design

21. Severity classes
Missing functionality – the system cannot support the user’s task.
Task failure – the user fails (knowingly or unknowingly) to complete the task on his own.
Annoying – the user complains that the system is cumbersome.
Medium – the user succeeds after stumbling around for a long time.
Minor – the user succeeds after a few attempts.
User Interface Design

22. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

23. Usability testing One variant Method: think-aloud test
System under test:
Real system – carry out various tasks
Prototype – evaluate window contents and navigation
Team
Facilitator – talks with the user
Log keeper – records the test session
Observer – extra
User Interface Design

24. Fig 1.4 Usability test - think aloud
Slide 24
Purpose:
Find usability problems
I try this
because ...
User doesn’t
notice ...
Facilitator
Listens
Asks as needed
Logkeeper
Listens
Records problems
User
Performs tasks
Thinks aloud
User Interface Design

25. (Fig 1.4 cont.) Plan Carry out Reporting Test-users: Test-tasks:
Slide 25
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
Ask cautiously:
- what are you looking for?
- why ?
Help users out when they are surely lost
Reporting
List the usability problems - within 12 hours
User Interface Design

26. Planning the test Choose test users Choose test tasks
Typical users for the system.
Don’t select other developers (unless it is an application to be used by developers).
Choose test tasks
Real work situation – select some realistic scenarios for the user to perform.
Closed – preferably, a task should accomplish something useful – a complete function of the application.
Without hidden help – without hints on how to carry out the task.
If you are not familiar with the system, then you must also study the system yourself.
User Interface Design

27. Carry out the test Explain the purpose clearly to the user.
It is the system that is being tested, not the user.
Assign the task
Remind user to think aloud by explaining what he does and why
Observe and record the user’s actions and words.
Offer help when user asks for it.
As much as possible, leave user alone to struggle with the task.
User Interface Design

28. Reporting the results
Condense the issues found into a list of problems.
This should be done as early as possible, within 12 hours, while your memory is fresh.
User Interface Design

29. Fig 1.5 Heuristic evaluation
Slide 29
Fig 1.5 Heuristic evaluation
Purpose: Find usability problems
Usability specialist looks at system
using common sense
and/or guidelines
The specialist lists problems
(Consults with other experts)
Expert - reviewer
First law of usability:
Heuristic evaluation has only 50% hitrate
Actual
problems
Predicted
False problems
Missed problems
User Interface Design

30. Heuristic evaluation Engage a usability specialist as consultant.
Potentially more convenient that arranging for usability tests with real users.
Usability expert has lots of experience with user interfaces but often lacks the domain knowledge for the application.
May lead to a lot of false positives.
Usability specialist may point out problems that don’t really cause problems to real users.
Fixing these may be a waste of developers’ time.
Fixing these may actually make the system worse.
May fail to uncover serious usability problems arising from missing functionalities or complex scenarios.
User Interface Design

31. User review
Engage a domain expert as usability consultant and walk him through the scenarios.
Domain expert can point out missing functionalities and imagine complex tasks that might be difficult to accomplish with your user interface.
However, experts often miss the trivial things that trip the novice user.
User Interface Design

32. Outline What is a user interface? Usability motivations
Usability factors
Usability problems
Basics of usability testing
Usability measurements and requirements
User Interface Design

33. Usability measures
Task time – time it takes the user to complete the given task.
Problem counts – number of usability problems uncovered.
Keystroke counts – how many keystrokes, mouse clicks and other operations did the user employ in order to complete the task?
Opinion poll – user completes a questionnaire after usability testing.
Score for understanding – quiz the user about the system’s behavior.
Guidelline adherence – identify deviations from interface standards and guidelines.
User Interface Design

34. Fig 1.6A Measuring usability - task time (performance)
Slide 34
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
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!
Pros: Classic approach. Good when buying.
Cons: Not good for development.
Not possible early. Little feedback.
User Interface Design

35. Fig 1.6B Choosing the numbers
Slide 35
Why 20?
Cost versus reliability.
During development:
One, later two, later ...
Users: 20 bank customers ...
Measure: In 2 min?
Reqs: Task 1: 18 succeed.
Task 2: 12 succeed.
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.
User Interface Design

36. Fig 1.6C Measuring usability - Problem counts
Slide 36
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.
How to measure
What to measure
Requirement
Pros: Possible early - mockup sufficient.
Good feedback to developers.
Cons: Best for ease of learning.
Only indications for other factors.
User Interface Design

37. Fig 1.6D Measuring usability - Keystroke counts
Slide 37
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
Total task time
6 0.6 s 3.6 s
total system response time s
Total task time 11.6 s
Plus other
user actions?
Pros: No users needed.
Possible early - mockup sufficient.
Cons: Not sure users find the fast way.
Only task efficiency.
User Interface Design

38. Fig 1.6E Measuring usability - Opinion poll
Slide 38
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
Questionnaire agree neutral disagree
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: Doesn’t match objective evidence.
Only indications during development.
Little feedback to developers.
User Interface Design

39. Fig 1.6F Measuring usability - Score for understanding
Slide 39
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
Pros: Easy way to test understandability.
Best way to cover error messages.
Useful both early and late in development.
Cons: Only measures understandability..
User Interface Design

40. Fig 1.6G Measuring usability - Guideline adherence
Slide 40
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
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.
User Interface Design

41. Fig 1.6H Which usability measure?
Slide 41
Ease of remember
Subjective satisf.
Understandability
Ease of learning
Task efficiency
Fit for use
Development, early
Development, late
Buying a system
Task time
Problem counts
Keystroke counts
Opinion poll
Score for underst.
Guidelines
Highly useful
Some use
Indications
only ? ?
User Interface Design

42. Homework
Usability testing exercise is posted on Blackboard. It is due on January 18.
User Interface Design