© Simeon Keates 2009
Usability with ProjectLecture 2 – 11/9/09Dr. Simeon Keates
© Simeon Keates 2009Page 2
The Personal Information Point
Output
Input
© Simeon Keates 2009
Exercise - Background
The PIP has 6 buttons for input Those buttons can be used for any purpose you choose The LCD screen will display the output only• i.e. no touch input
Page 3
© Simeon Keates 2009
Exercise - Details
PIP is to be used to advertise National Savings products Go to: http://www.nsandi.com/products/index.jsp Review the products• NOTE: Including those no longer on sale!
Design a set of paper prototypes for how that information can be displayed on the PIP
Write a (very brief) summary report explaining your decisions
QUESTION – What do you think is the minimum number of button presses needed to help a novice user decide which product to invest in?
Page 4
© Simeon Keates 2009
Review of Wednesday’s exercise
All groups finished the task (Group 2?) Paper prototypes all looked appropriate Not all included max and min button press calculations None included an estimate of expected number of presses Variety of design decisions• Many opted for clustering of products• Two groups tried scroll bars• No group began with a simple list• Different navigation and clustering strategies• Where to put the back button?
Page 5
© Simeon Keates 2009
Back button…
Page 6
Product 1
Product 2
Product 3
Product 4
Product 5
<Back
Here?
© Simeon Keates 2009
Back button…
Page 7
Product 1
Product 2
<Back
Product 3
Product 4
Product 5
Or here?
© Simeon Keates 2009
Review of Wednesday’s exercise – in your own words
You have 5 mins to prepare answers to the following questions:
What was your approach to Wednesday’s exercise?
What did you find difficult?
How happy were you with your design?
How happy were you with your performance estimates?
If you had been given more time, what further information would you have gathered and/or done differently?
Page 8
© Simeon Keates 2009
Today’s lecture
Quite a bit of maths Quite a bit of information architecture (IA) Implicitly, quite a bit about design
Reason: While usability can be regarded as a separate discipline …it is more useful to consider it in the context of IA and design …not just that there *is* a problem …but *this* is what the problem is …and *this* is how you could fix it …and so is *this* …and *this*
Page 9
© Simeon Keates 2009
What makes a good product? (source: Cooper “The inmates are running the asylum”)
Page 10
Usa
bilit
y Utility
Design
© Simeon Keates 2009Page 11
Calculating the number of button presses
© Simeon Keates 2009
National Savings Products (current products - 12)
Premium Bonds – old-style Lotto NS&I Direct ISA – tax-free savings for workers NS&I Cash ISA – tax-free savings for workers Fixed Interest Savings Certificates – long term security Index-linked Savings Certificates- most long term security Children's Bonus Bonds – tax free savings for children Income Bonds – monthly income Guaranteed Income Bonds – fixed monthly income Guaranteed Growth Bonds – fixed return on investments Guaranteed Equity Bonds – low risk FTSE 100 tracker Investment Account – regular savings account with passbook Easy Access Savings Account – savings account with card and phone
Page 12
© Simeon Keates 2009
National Savings Products (withdrawn products – 9 or 12)
Pensioners Bonds Capital Bonds Ordinary Account Treasurer's Account SAYE Yearly Plan Deposit Bonds TESSA-only ISA FIRST Option Bonds National Savings Stamps Gift Tokens Fixed rate savings bonds
Page 13
© Simeon Keates 2009
National Savings Products – The on-line guide
I want: Tax-free investments (5 current products + 2 withdrawn) Guaranteed returns (4 current products + 2 withdrawn) High potential returns (2 current products) To save regularly (5 current products + 4 withdrawn) To save for a rainy day (5 current products + 7 withdrawn) To invest for a child (4 current products + 3 withdrawn) A monthly income (2 current products) Help to decide…
(from the home page)
Page 14
© Simeon Keates 2009
National Savings Products – “Help to decide” feature
Who are you saving for? • Myself• A child or grandchild
How do you want to save?• Lump sum • Save regularly• Flexibility to do both
Access to your money• Set term • Quick access
How would you like to receive your returns?• Interest paid out as monthly income • Returns left to build up (growth)
Page 15
© Simeon Keates 2009
Different information architecture approaches
Simple lists• Simple list• Better list• Even better list
Scrolling
Product clusters
Directed search
Page 16
© Simeon Keates 2009
Calculating the number of button presses
Assumptions: No errors are made User only selects the particular product of interest No exploration Random likelihood of product choice
What should we report? Easy: minimum and maximum number of button presses Slightly harder: Average number of button presses Harder (but more useful): Expected number of button presses
Page 17
© Simeon Keates 2009
How many button presses? – Ultra-simple list design
Page 18
Product 1
Product 2
Product 3
Product 4
Product 5
Next page>
© Simeon Keates 2009
How many button presses? – Ultra-simple list design
Page 19
Product 6
Product 7
Product 8
Product 9
Product 10
Next page>
© Simeon Keates 2009
How many button presses? – Ultra-simple list design
Total number of screens = 21 products ÷ 5 products per screen
= 5 screens total
Minimum of 1 button press, maximum of 5
Average = 3 button presses
[N.B. – still 3 for 23 products]
Page 20
© Simeon Keates 2009
How many button presses? – Ultra-simple list design
Assuming a random likelihood of product choice: 5 in 21 chance of 1 button press [i.e. 23.8%] 5 in 21 chance of 2 button presses 5 in 21 chance of 3 button presses 5 in 21 chance of 4 button presses 1 in 21 chance of 5 button presses
E(number_of_button_presses) = p(product being on page 1) * 1 + p (product on page 2) * 2 +
p (page 3) * 3 + p(page 4) * 4 +
p(page 5) * 5
Actual expected value = 2.6 button presses [N.B. - 2.82 for 23 products]
Page 21
© Simeon Keates 2009
How many button presses? – Ultra-simple list design
Do we believe this calculation?
What problems can you see with it?
Page 22
Answer: No
Answer: Navigation is very naïve (only moves forward)
No error tolerance
No support for exploration
© Simeon Keates 2009
How many button presses? – A better simple list design
Page 23
Product 1
Product 2
<Previous page
Product 3
Product 4
Next page>
© Simeon Keates 2009
How many button presses? – A better simple list design
Page 24
Product 5
Product 6
<Previous page
Product 7
Product 8
Next page>
© Simeon Keates 2009
How many button presses? – A better simple list design
Total number of screens = 21 products ÷ 4 products per screen
= 6 screens total
Minimum of 1 button press, maximum of 6
Average = 3.5 button presses
[N.B. – still 3.5 for 23 products]
Page 25
© Simeon Keates 2009
How many button presses? – A better simple list design
Assuming a random likelihood of product choice: 4 in 21 chance of 1 button press … 4 in 21 chance of 5 button presses 1 in 21 chance of 6 button presses
E(number_of_button_presses) = p(product being on page 1) * 1 + p (product on page 2) * 2 + …
Actual expected value = 3.1 button presses
[N.B. – 3.4 for 23 products]
Page 26
© Simeon Keates 2009
A better (?) simple list - discussion
Average number of presses now 3.1 (was 2.6)
However: Better navigability (can explore back and forward) Better error tolerance (can return to previous page)
Page 27
© Simeon Keates 2009
Improving the better simple list…
Page 28
Product 1
Product 2
Product 3
Product 4
Product 5
Next page>
© Simeon Keates 2009
Improving the better simple list…
Page 29
Product 6
Product 7
<Previous page
Product 8
Product 9
Next page>
© Simeon Keates 2009
How many button presses? – An even better simple list design
Total number of screens = 1 [5 products] + 1 [4] + 1 [4] + 1 [4] + 1 [4]
= 5 screens total
Minimum of 1 button press, maximum of 5
Average = 3 button presses (was 3.5)
[N.B. – 3.5 for 23 products]
Page 30
© Simeon Keates 2009
How many button presses? – An even better simple list design
Assuming a random likelihood of product choice: 5 in 21 chance of 1 button press 4 in 21 chance of 2 button presses 4 in 21 chance of 3 button presses 4 in 21 chance of 4 button presses 4 in 21 chance of 5 button presses
E(number_of_button_presses) = p(product being on page 1) * 1 + p (product on page 2) * 2 + …
Actual expected value = 2.9 button presses (was 3.1)
[N.B. – 3.2 for 23 products, was 3.4]
Page 31
© Simeon Keates 2009
An even better simple list
Number of button presses now 2.9 (was 3.1)
Is this a better design?
Which usable design principle from Wednesday did we break?
Page 32
Answer: Consistency – one button changes its use
© Simeon Keates 2009
Simple list performance
21 products 23 products
Average(median)
Expected Average(median)
Expected
Simple list 3 2.6 3 2.8
Better list 3.5 3.1 3.5 3.4
Even better list
3 2.9 3.5 3.2
Page 33
Designs all require users to understand
products from name only
© Simeon Keates 2009
Alternative information architecture approaches
Scrolling
Product family clusters
Directed search
Page 34
© Simeon Keates 2009
Scrolling interface
Page 35
Scroll up
Scroll down
<Back
Select
Help
Quit
Category 1
Category 2
Category 3
…
© Simeon Keates 2009
National Savings Products – Possible categories
I want: Tax-free investments (5 current products + 2 withdrawn) Guaranteed returns (4 current products + 2 withdrawn) High potential returns (2 current products) To save regularly (5 current products + 4 withdrawn) To save for a rainy day (5 current products + 7 withdrawn) To invest for a child (4 current products + 3 withdrawn) A monthly income (2 current products) Help to decide…
(from the home page)
Page 36
© Simeon Keates 2009
Calculating the number of button presses for scrolling
Minimum number of presses = 2 [ i.e. 1st category / 1st product ] Maximum number of presses:• Tax-free takes 0 presses to reach category • 1 press to enter category listing• 6 presses to reach final product [7 products]
• 1 press to select final product = 8 presses in total
• Guaranteed return: 8 presses [2nd category / 6 products] • High returns: 5 presses [3rd category / 2 products]• Save regularly: 13 presses[4th category / 9 products]• Rainy day: 17 presses [5th category / 12 products]• Children: 13 presses [6th category / 7 products]• Monthly income: 9 presses [7th category / 2 products]
Page 37
© Simeon Keates 2009
Calculating the number of button presses for scrolling
Average (median) number of presses = 9 presses
Expected number of presses:• Assume random chance of wanting a particular product• Assume random chance of wanting a particular category
• p( category ‘n’ ) = 1 in 7 [ i.e. 14.3% ]• p( product ‘m’ in category ‘n’ ) = 1 in no_of_products_in_n • i.e. p( product 1 in category 1 ) = ( 1/7 ) * ( 1/7 ) = 1 in 49 [ i.e. 0.020% ]• p(product 4 in category 5) = ( 1/9 ) * (1/7) = 1 in 63 [ i.e. 0.016% ]
• We then multiply the probability of each “product_within_a_category” by the total number of button presses required for each
Expected number of presses = 7.7 presses
Page 38
© Simeon Keates 2009
Improving the scrolling interaction
Can we improve this design by moving the larger categories to the top of the list?
Page 39
Answer: No. This would improve the number of presses if the likelihood of
selecting a particular category is directly proportional to the number of
items in it (7.6 button presses in descending size).
However, we made an assumption that each category was equally likely.
© Simeon Keates 2009
Improving the scrolling interaction
Q: Will reducing the product listing redundancy help?
Page 40
Answer: No.
Q: What will reduce the number of button presses?
Answer: Reducing the number of categories at the top level.
Additionally, reducing the number of categories AND reducing the product listing redundancy will give the best results (see later).
© Simeon Keates 2009
Clustering the products
Clustering the products is inherently faster
Linear list – each screen linearly increases the number of items available• i.e. adding an extra screen of 4 items increases the total number of products
by 4
Clustered/categorised list – each screen increases the number of items exponentially• i.e. adding an extra “screen” of 4 items increases the number of available
items by a factor or 4
Page 41
© Simeon Keates 2009
A linear display
Page 42
1
2
3
4
< >
5
6
7
8
< >
4 options 8 options
9
10
11
12
< >
New screen
12 options
© Simeon Keates 2009
An exponential display
Page 43
1
2
3
4
< >
4 options
1314
1516
< >
16 (42) options 1314
1516
< >
64 (43) options
© Simeon Keates 2009
Clustering objects
Theoretically can display all 21 or 23 product within a depth of 2 screens – i.e. maximum of 2 button presses.
Page 44
© Simeon Keates 2009
“Optimal” (mathematical) layout
Page 45
AB
DE
C
Top level
12
34
< 5
1112
1314
< 15
67
89
< 10
1617
1819
< 20
A
B
C
D
2122
23
<
E
Second level
© Simeon Keates 2009
“Optimal” layout
Minimum number of presses = 2 Maximum number of presses = 2
Expected number of presses = 2 • (c.f. 2.8 to 3.4 for list designs and 7.7 for scrolling)
Page 46
© Simeon Keates 2009
Interpreting the results
Scrolling appears to be worst choice “Optimal” layout appears to be noticeably fastest
Q: Do you think these results show the whole story?
Page 47
Answer: No.
There is no allowance for actual user behaviour in these calculations.
Q: Why not?
© Simeon Keates 2009
How might user behaviour affect the results?
The names of the products may be meaningless• Users end up having to explore for more detail
Not all products are equally likely• Some products may sell like hot potatoes, others sink without a trace• Designs should be optimised to put most popular products first
Product cluster/family names may not make sense
Users may think about their needs in different ways• By savings amount; by frequency of savings; by tax status, etc.• Designs ought to be sensitive to this
Users make mistakes• They may not want *that* product
Page 48
© Simeon Keates 2009Page 49
User mistakes
© Simeon Keates 2009
Why users make mistakes
The interface does not provide them with the correct information They do not read the information They are in a rush Their minds are on other things They’d really rather be:• watching the football• making a cup of tea• doing usability calculations…
And so on…
Page 50
© Simeon Keates 2009
What effect do errors have?
Errors are typically classified as follows:
Minor• Causes a minor annoyance or confusion• e.g. mistyping a name in a search field
Moderate• Causes an error• e.g. mistyping a credit card number in a payment field
Catastrophic / Showstopper• Causes a task failure• e.g. poor coding causing product purchase to fail and/or browser to crash
Page 51
© Simeon Keates 2009
Errors – Effects of frequency
Errors are also typically classified by their frequency:
Rare:• Occurs very rarely and/or only on some tasks
Occasional: • Occurs reasonably frequently and/or on several tasks
Frequent:• The majority of attempts to use the product for one or more tasks will
encounter this error
Always• Every attempt to use the product for one or more tasks encounters this error
Page 52
© Simeon Keates 2009
Error – effects of frequency on users
Errors can also be thought of by their effects on users:
Few users• Not many users affected
• (e.g. people who use their middle name)
Many users• Somewhere between “few” and “all”!
• (e.g. women who change their name after getting married)
All users• Everyone who attempts to use the product for a task
• (e.g. everyone who has a name…)
Page 53
© Simeon Keates 2009
Error classifications
None of these classifications are rigorously defined
No single accepted definition of each
Can define according to the project, for example…
Page 54
© Simeon Keates 2009
Error classifications
Website X defines user frequency as follows:• Class 1 - <10% - few• Class 2 - >10% & <85% - many• Class 3 - >85% - all
Website X also defines frequency as follows:• Class 1 - <10% of all (i.e. random) tasks and <20% on each specified task• Class 2 - <25% of all (random) tasks and <50% on each specified task• Class 3 – either >25% of all random tasks or >50% on each specified task
Page 55
© Simeon Keates 2009
Error classifications
Finally, Website X also defines errors as:
Class 1 – user recognises and corrects error on same page
Class 2 – user has to return to a prior page to correct the error
Class 3 – user fails to complete the task and does not get the free product
Page 56
© Simeon Keates 2009Page 57
PIP summary
© Simeon Keates 2009
Summary of the PIP exercise
Is this a suitable product design for selling National Savings products?
How would you improve its design?
Page 58
Answer: No. [And for many more reasons than this…]
© Simeon Keates 2009Page 59
Designing for users
© Simeon Keates 2009
Designing for user behaviour
The PIP exercise was primarily mathematical It gave us a mathematically good solution … but not necessarily a usable one
Q: How could we improve the design?
Page 60
Answer: It depends on what the issues are!
© Simeon Keates 2009
Questions about the design:
What are good product clusters/families?
Are each cluster types equally good?
Are the product names meaningful?
Is the navigation clear to the user?
Do we need to add a help facility?
Can we learn more about how users want to use the PIP?
Page 61
© Simeon Keates 2009
Finding out more about the users…
How would you find out more about who the users are?
How would you find out more about what they might want to use this product for?
How would you find out more about their actual functional needs?
Page 62
Answer: Ask them!
[most of the time]
© Simeon Keates 2009
Methods of learning about the users (source: Keates “Designing for accessibility”)
Private camera conversations Focus groups Interviews Field observation studies Ethnographical methods Questionnaires/surveys
Page 63
© Simeon Keates 2009
Private camera conversations
Method: User enters booth and talks privately to a camera
Advantages: No interference from interviewer
Disadvantages: Little or no control over what you actually get out of it
Page 64
© Simeon Keates 2009
Method: Find a collection of “interesting people” and have a structured or semi-
structured discussion
Advantages: Little chance of discussion drying up Group dynamics often spurs discussion in new directions
Disadvantages: Can end up being led by a vocal minority Depends heavily on skill of facilitator
Page 65
Focus groups
© Simeon Keates 2009
Interviews
Method: Interviewer asks structured or semi-structured questions to 1 or 2 users
Advantages: Highly controlled Quick, cheap Can be done remotely
Disadvantages: Interviewer can ‘lead’ the interviewees Again dependent on skill of interviewer
Page 66
© Simeon Keates 2009
Field observation studies
Method: Go watch the users attempt to accomplish a specified task or set of
tasks
Advantages: Most direct method of learning about issues faced by the users
Disadvantages: Can be costly (time + money) Typically learning about state of the world as it is, not as it could be
Page 67
© Simeon Keates 2009
Ethnographical methods
Method: Identify a small set of users, give them different media and ask them to
record their thoughts and observations for an extended period of time Use of “cultural probes”
Advantages: Can provide a very rich set of information
Disadvantages: No control over what comes back May be completely useless
Page 68
© Simeon Keates 2009
Questionnaires
Method: Give users pre-prepared questions to complete and return
Advantages: Easy to cover a large number of people
Disadvantages: Results are only as good as the questions that are asked Beware self-selecting respondents
Page 69
© Simeon Keates 2009
Stable boys and the future of transportation…
User data gathering caveat
Page 70
© Simeon Keates 2009Page 71
Case studies
Datarepresentation
Products/services
End-users
How to assessproducts/service
acceptability
How to capture &represent end-user
information
How to use theinformation toprovide correctproducts/services
How to assess datarepresentationacceptability
Informationusers
Representing the user data
© Simeon Keates 2009
Example methods of representing user data (source: Keates)
User models• e.g. Model Human Processor, GOMS, etc.• [more on these in later lectures]
Multimedia resources• Videos, audio tapes, diaries, web pages, etc.
Anthropometric data resources• E.g. ergonomics tables, etc.
User stories
Participatory design!
Page 72
© Simeon Keates 2009
Representing user data - Personas
In groups of 2:
Draft a persona for a user of the PIP in this example
Specify:
• Age
• Gender
• Living arrangements
• Income
• Reasoning for investing
• Favourite colour
• Favourite food
• One other characteristic…
Page 73
© Simeon Keates 2009
Personas
Can be very powerful method Can be constructed to be very memorable
Need to avoid being too “vanilla” Need to offer useful (and realistic) insights to designers
Need to be based on real target users
Page 74
© Simeon Keates 2009Page 75
Exercise: Improving your web-site
© Simeon Keates 2009
Improving your web-site – part 1
Look at your product selection page
Confirm that your products are in the correct families• HINT: Ask someone British if you are not sure!
Develop three (brief) target user descriptions (personas) for users of your site. Explain why each person would want to visit your site and complete this task.• NOTE – these are the users you will try to find for your user trial sessions
Estimate the minimum, maximum and expected number of button/key presses for the user to select their desired product
Page 76
© Simeon Keates 2009
Improving your web-site – part 2
Sketch at least one other layout for the 62 products• Suggestions: Simple list, menus, product families, etc.
Compare and discuss the merits of your original design and the alternative one sketched here
Q: How would your answer differ for 5 products and for 500 products?
Amend the design of your product page based on what you have learned this week
Page 77