user interface design a software engineering perspective soren lauesen slides for chapter 1 november...
Post on 20-Dec-2015
237 views
TRANSCRIPT
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 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
Outline
• What is a user interface?• Usability motivations• Usability factors• Usability problems• Basics of usability testing• Usability measurements and requirements
User Interface Design 5
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 6
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
User Interface Design 7
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 8
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 9
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 10
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 11
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 12
Outline
• What is a user interface?• Usability motivations• Usability factors• Usability problems• Basics of usability testing• Usability measurements and requirements
User Interface Design 13
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 14
Outline
• What is a user interface?• Usability motivations• Usability factors• Usability problems• Basics of usability testing• Usability measurements and requirements
User Interface Design 15
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 16
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
User Interface Design 17
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 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 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 20
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 ...
User Interface Design 21
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.
User Interface Design 22
Kinds of prototypes
• Paper prototypes– Hand-drawn mock-up – Tool-drawn mock-up
• Computer-based– Screen prototype– Functional prototype
User Interface Design 23
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
User Interface Design 24
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 25
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 26
Outline
• What is a user interface?• Usability motivations• Usability factors• Usability problems• Basics of usability testing• Usability measurements and requirements
User Interface Design 27
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 28
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!
User Interface Design 29
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.
User Interface Design 30
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
User Interface Design 31
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?
User Interface Design 32
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
User Interface Design 33
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..
User Interface Design 34
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.
User Interface Design 35
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
User Interface Design 37
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.
User Interface Design 38
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”)
User Interface Design 39
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.
User Interface Design 40
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
User Interface Design 41
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
User Interface Design 42
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?"