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.
Fig 1.1A System interfaces

User Courses? Technical

interfaces interfaces Accounting
system

System
Hotline?

Factory
Manual?
Fig 1.1B Quality factors

Easy to make a user interface: Hard to make

Just give access to the database a good
Database
user interface

Functionality: Quality factors:

Necessary features Correctness
Availability
Performance
Security
All factors important.
Ease of use
Hard to measure, Maintainability
but possible. ...
Fig 1.2 What is usability?

Max three menu levels

On-line help ??
Windows standard

Usability factors: Responsibility?

Programmers?
a. Fit for use (adequate functionality)
Other developers?
Ease of use: User department?
b. Ease of learning
c. Task efficiency
d. Ease of remembering
e. Subjective satisfaction Measurable
f. Understandability Priorities vary

Game programs:
a. ??
Fig 1.3 Usability problems

Examples: Severity classes:

The system works as intended by the
programmer, but the user: 1 Missing functionality
2 Task failure
P1. Cannot figure out how to start the
search. 3 Annoying
Finally finds out to use F10. 4 Medium problem
(succeeds after long
P2. Believes he has completed the task, time)
but forgot to push Update.
5 Minor problem
P3. Sees the discount code field, but (succeeds after short
cannot figure out which code to use. time)
Critical problem =
P4. Says it is crazy to use six screens to Missing functionality,
fill in ten fields. task failure, or annoying
P5. Wants to print a list of discount
codes, but the system cannot do it.
Fig 1.4 Usability test - think aloud
Purpose:
Find usability problems
I try this User doesn’t
because ... notice ...

Facilitator
Listens
Logkeeper
Asks as needed Listens
Records problems
User
Performs tasks
Thinks aloud
(Fig 1.4 cont.)

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
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
Predicted False problems
problems

Actual Missed problems

problems
Fig 1.6A Measuring usability - task time (performance)

ATM
Users: 20 bank customers, random selection. How to measure
Task 1: Withdraw $100 from ATM. No instructions.
Measure: How many succeed in 2 min?
What to measure
Task 2: Withdraw as much as possible ($174)
Measure: How many succeed in 5 min?
Reqs: Task 1: 18 succeed. Requirement - target
Task 2: 12 succeed.

Internal ordering system

Users: 5 secretaries in the company.
Have tried the internal ordering system.
Have not used it for a month. What to measure
Task 1: Order two boxes of letter paper + . . .
Risky!
Measure: Average time per user.
Reqs: Average time below 5 min.

Pros: Classic approach. Good when buying.

Cons: Not good for development.
Not possible early. Little feedback.
Fig 1.6B Choosing the numbers

Why 20?
Cost versus reliability.
Users: 20 bank customers ...
During development:
One, later two, later ...
Measure: In 2 min?
Why 2 mins?
Best practice,
Reqs: Task 1: 18 succeed. ideal way ...
Task 2: 12 succeed. Why 18?
90% of customers
should succeed.
Task 2 harder.

Open target
Specify how, what,
Reqs: 18 out of 20 must and expectations.
succeed within ____ min. Wait and see what is
We expect around 2 min. possible.
Fig 1.6C Measuring usability - Problem counts

Users: 3 potential users. Think-aloud test.

Record usability problems. How to measure
Task 1: Order two boxes of letter paper + . . .
Task 2: ...
Measure: Number of critical problems per user.
What to measure
Number of medium problems on list.
Reqs: Max one user encounters critical problems.
Requirement
Max 5 medium problems on the list.

Pros: Possible early - mockup sufficient.

Good feedback to developers.
Cons: Best for ease of learning.
Only indications for other factors.
Fig 1.6D Measuring usability - Keystroke counts

Task 1: Withdraw a standard amount from ATM. How to

Task 2: ... measure
Measure: Number of keystrokes and mouse clicks.
Reqs: Max keystrokes 6 - incl. PIN code. What to measure
Total system response time max 8 s.
Requirement
Total task time
6 keystrokes @ 0.6 s 3.6 s
total system response time 8.0 s
Plus other
Total task time 11.6 s
user actions?

Pros: No users needed.

Possible early - mockup sufficient.
Cons: Not sure users find the fast way.
Only task efficiency.
Fig 1.6E Measuring usability - Opinion poll

Ask 20 novice users to complete the questionnaire.

How to measure
Measure: Count number of entries per box.
Reqs: 80% find system easy to learn. What to measure
50% will recommend it to others.
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.
Fig 1.6F Measuring usability - Score for understanding

Ask 5 potential ATM users what these error

messages mean:
Amount too large How to measure
PIN code invalid . . .
Ask them also:
What would the system do if . . .
Measure: Assess answers on scale A-D. What to measure
Reqs: 80% of answers marked A or B. Requirement

Pros: Easy way to test understandability.

Best way to cover error messages.
Useful both early and late in development.
Cons: Only measures understandability..
Fig 1.6G Measuring usability - Guideline adherence

Ask an expert to review the user interface and

How to measure
identify deviations from guideline X. (Or ask two
experts to come up with a joint list.)
Measure: Number of deviations per screen. What to measure

Reqs: At most one deviation per screen.

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.
Fig 1.6H Which usability measure?

Development, early
Ease of remember

Development, late
Understandability
Subjective satisf.

Buying a system
Ease of learning
Task efficiency
Fit for use
Task time
Highly useful
Problem counts
Keystroke counts
Some use
Opinion poll ? ?
Score for underst. Indications
Guidelines only
 User interface design
A software engineering perspective
Soren Lauesen

Slides for Chapter 2

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.
Fig 2.1 The development process

Analysis
Traditional systems
Design development
Experts?
Guidelines? Program

Usability test? Test

Scaring results !
Too late to correct
Operation

Study users Analysis HCI classic:

and tasks
iterative design
Design prototype

Usability test Program

Fig 2.2 Hotel system

Task list Breakfasts 23/9

Book guest Room Buffet In room
Checkin 11 1
Checkout 12 2
Change room 13 1 1
Record services 15
Breakfast list ...
Fig 2.3A Hotel system prototype
(Fig 2.3A Cont.)
 Fig 2.3B Defect list for hotel system mockup
ID Defects in Find Guest/Stay window Novice B Novice M Receptionist Heur.
eval.
D1 The Stay concept is not understood by Medium Guesses Hit
ordinary users problem immediately
D2 Doesn't notice the Find button Task Medium Hit
failure problem.
D3 When you select a certain date, why Minor Hit
does the list show earlier dates too? problem
D4 Not visible whether the guests have Annoying Hit
been checked in or not
D5 How do you open the stay window from Medium Task Medium Hit
the Find guest/stay window? problem failure problem
D6 Tries Enter to search, but it opens a Medium
Stay window. Then tries F2
D7 Doesn't see that the guest is on the list Annoying Annoying
already.
D8 Doesn't understand why the list Medium
becomes empty (made a spelling error) problem
D9 Believes the task is complete when she Task failure
sees the guest on the list.
D10 Doesn't understand that the Stay screen Task failure Task
must be opened. failure
D11 Fills in all search criteria, believing they Minor Task
are data fields. problem failure
Fig 2.3C Hit-rate of Hotel System evaluation

Heuristic evaluation:
7 false problems
21 predicted
problems 8 likely, but not observed

6 hits
20 observed
problems 14 missed problems
Fig 2.4 Various prototypes

Hand-drawn Tool-drawn
mockup: mockup:
15-30 min 30-60 min

Which prototype
is the best?

Screen Functional
prototype: prototype:
1-4 hours 2-8 hours
(Fig 2.4 Cont.)
Full contents of a mockup
Empty screens for copying
Screens with realistic data
Screens to be filled in by user
Menus, lists, dialog boxes
Error messages
Help texts
Notes about what functions do
Handling a system
with 100 screens?
Accelerator effect:
If the central screens are good,
the rest are okay
almost automatically