User interface design A software engineering perspective Soren Lauesen Slides for Chapter 1 November 2004 © 2005, Pearson Education retains the copyright

User interface design A software engineering perspective

Soren Lauesen

Slides for Chapter 1November 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.

User Interface Design 2

Outline

• What is a user interface?• Usability motivations• Usability factors• Usability problems• Basics of usability testing• Usability measurements and requirements


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.


Outline



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.


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


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


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



• 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



• 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



• 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


Outline



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.


Outline



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.


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

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


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.


Outline



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


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


Prototypes

• A primitive version of a system.• Uses:

– Demonstrate technical feasibility.• Develop only the necessary technical portions.

– Check performance early in development.• Develop the performance-critical portions and simulate

heavy load.

– Basis for discussion with stakeholders.• Develop main screens. (“Demo” versions.)

Test usability of system.• Develop user interface portion.


Kinds of prototypes

• Paper prototypes– Hand-drawn mock-up – Tool-drawn mock-up

• Computer-based– Screen prototype– Functional prototype


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


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


Outline



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.


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

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


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

Usability Testing Exercise

March 6, 2006

5:30-8:30

PKI 269


Objectives

• Participate in and experience an actual usability testing session.

• Get a feel for how the Linked View Data Visualization requirements were interpreted and implemented by different students.


Usability test

• It is the system being tested, not you.• One-on-one between developer and user.• Developer is also facilitator/observer.• You will be asked to perform a set of tasks.• Remember to think aloud as you perform the

tasks.– Explain what you are up to and why.– This is your primary responsibility.

• Other things can be pointed out too– Point out anything that might be hard to understand or

inconvenient to use.– Point out style issues (color, placement of buttons) if they

hinder your understandability.– Be constructive (“I find it hard to read this” rather than “I

don’t like the way this was implemented”)


Usability test (con’t)

• Expect some crashes, some of these systems are not quite finished.

• Each testing period is 30 minutes long, but do not panic if you are running out of time– Remember: it’s the system being tested, not you.

• Short debriefing (Q&A) with developer after each session.


Cars data

• make - Make of car • model - Model of car • mpg - Miles/(US) gallon • cyl - Number of cylinders • disp - Displacement (cu.in.) • hp - Gross horsepower • drat - Rear axle ratio • wt - Weight (lb/1000) • qsec - 1/4 mile time • vs - V/S (???) • am - Transmission (0 = automatic, 1 = manual) • gear - Number of forward gears • carb - Number of carburetors


Usability data

• UserNo - ID for a particular user • TaskNo - Task # executed by user • Comp - 1 = user completed the task, 0 = user did not complete

the task • DurInMin - How long (in minutes) it took to complete the task • DurInSec - DurInMin * 60 • UProbs - number of usability problems recorded • Sev1 - number of severity 1 problems recorded (most severe) • Sev2 - number of Severity 2 problems recorded • Sev3 - number of Severity 3 problems recorded • Sev4 - number of Severity 4 problems recorded • Sev5 - number of Severity 5 problems recorded (least severe) • NoSev - 1 = observer did not record severity, 0 = observer

recorded severity


A demo

• Paper prototype• (If time permits) Ggobi system

• Task:– Use the system and answer the question, “Is there

a relationship between horsepower and weight?”– Use the system and answer the question, “For

cars with 6 cylinders, is there a relationship between horsepower and the quarter-mile time?"

Documents

User interface design A software engineering perspective Soren Lauesen Slides for Chapter 1 November 2004 © 2005, Pearson Education retains the copyright