© Simeon Keates 2009 Usability with Project Lecture 2 – 11/9/09 Dr. Simeon Keates.

© Simeon Keates 2009

Usability with ProjectLecture 2 – 11/9/09Dr. Simeon Keates


The Personal Information Point

Output

Input


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


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?


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?


Back button…

Product 1

Product 2

Product 3

Product 4

Product 5

<Back

Here?


Back button…

Product 1

Product 2

<Back

Product 3

Product 4

Product 5

Or here?


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?


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*


What makes a good product? (source: Cooper “The inmates are running the asylum”)

Usa

bilit

y Utility

Design


Calculating the number of button presses


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


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


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)


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)


Different information architecture approaches

Simple lists• Simple list• Better list• Even better list

Scrolling

Product clusters

Directed search


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


How many button presses? – Ultra-simple list design

Product 1

Product 2

Product 3

Product 4

Product 5

Next page>



Product 6

Product 7

Product 8

Product 9

Product 10

Next page>



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]



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]



Do we believe this calculation?

What problems can you see with it?

Answer: No

Answer: Navigation is very naïve (only moves forward)

No error tolerance

No support for exploration


How many button presses? – A better simple list design

Product 1

Product 2

<Previous page

Product 3

Product 4

Next page>



Product 5

Product 6

<Previous page

Product 7

Product 8

Next page>



Total number of screens = 21 products ÷ 4 products per screen

= 6 screens total


Average = 3.5 button presses

[N.B. – still 3.5 for 23 products]



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]


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)


Improving the better simple list…

Product 1

Product 2

Product 3

Product 4

Product 5

Next page>


Improving the better simple list…

Product 6

Product 7

<Previous page

Product 8

Product 9

Next page>


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


Average = 3 button presses (was 3.5)

[N.B. – 3.5 for 23 products]


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]


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?

Answer: Consistency – one button changes its use


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

Designs all require users to understand

products from name only


Alternative information architecture approaches

Scrolling

Product family clusters

Directed search


Scrolling interface

Scroll up

Scroll down

<Back

Select

Help

Quit

Category 1

Category 2

Category 3

…


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)


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]


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


Improving the scrolling interaction

Can we improve this design by moving the larger categories to the top of the list?

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.


Improving the scrolling interaction

Q: Will reducing the product listing redundancy help?

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


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


A linear display

1

2

3

4

< >

5

6

7

8

< >

4 options 8 options

9

10

11

12

< >

New screen

12 options


An exponential display

1

2

3

4

< >

4 options

1314

1516

< >

16 (42) options 1314

1516

< >

64 (43) options


Clustering objects

Theoretically can display all 21 or 23 product within a depth of 2 screens – i.e. maximum of 2 button presses.


“Optimal” (mathematical) layout

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


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


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?

Answer: No.

There is no allowance for actual user behaviour in these calculations.

Q: Why not?


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


User mistakes


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…


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


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


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


Error classifications

None of these classifications are rigorously defined

No single accepted definition of each

Can define according to the project, for example…



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



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


PIP summary


Summary of the PIP exercise

Is this a suitable product design for selling National Savings products?

How would you improve its design?

Answer: No. [And for many more reasons than this…]


Designing for users


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?

Answer: It depends on what the issues are!


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?


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?

Answer: Ask them!

[most of the time]


Methods of learning about the users (source: Keates “Designing for accessibility”)

Private camera conversations Focus groups Interviews Field observation studies Ethnographical methods Questionnaires/surveys


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


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

Focus groups


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


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


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


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


Stable boys and the future of transportation…

User data gathering caveat


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


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!


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…


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


Exercise: Improving your web-site


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


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

© Simeon Keates 2009 Usability with Project Lecture 2 – 11/9/09 Dr. Simeon Keates.

Documents

Transcript of © Simeon Keates 2009 Usability with Project Lecture 2 – 11/9/09 Dr. Simeon Keates.