Task Analysis
Background
• Only the simplest websites consist solely of
static pages
• For a website to be worth building, it must at
least return its own financial investment
• This usually means handling money
• This usually means a series of tasks involving
different pages
• Task analysis is about streamlining the action
A Typical Transaction
Home
Order Form
Products page
(Teddy bear,
Lego, Barbie doll,
Blocks, Scooter
Verify Purchase
Teddy bear
Order
Confirmation
Alternative A
Home
Order Form
Products page
(Teddy bear,
Lego, Barbie doll,
Blocks, Scooter
Verify Purchase
Teddy bear
Order
Confirmation
The teddy bear is advertised on the home page.
Alternative B
Home
Order Form
Products page
(Teddy bear,
Lego, Barbie doll,
Blocks, Scooter
Verify Purchase
Teddy bear
Order
Confirmation
A button on the products page takes us straight
to the order form
Alternative C
Home
Order Form
Products page
(Teddy bear,
Lego, Barbie doll,
Blocks, Scooter
Verify Purchase
Teddy bear
Order
Confirmation
A button on the home page takes the customer
directly to the order form
Alternative D
Home
Order Form
Products page
(Teddy bear,
Lego, Barbie doll,
Blocks, Scooter
Verify Purchase
Teddy bear
Order
Confirmation
A cookie tells us who the customer is, so one
click on the home page buys the product
Task Analysis
• Helps people achieve their goals more
efficiently
• Gives information to support a context-based
help system
• Helps generate a system which is easy to use
and learn
• Helps to decide on the functionality to be built
into the system
Task Analysis
• Tries to answer the question, "Does the design
support the task?"
• Indicates areas for QA and testing
• Helps determine how important each action is
• Helps measure whether the final design is
successful
Task Analysis
• The actions on a single web page are usually
fairly simple (although the construction of the
page may not be), so why do all this analysis?
• The reason is that a site is built from a number
of pages.
• We need to look at the system represented by
the site
• Some pages may be unnecessary.
• There may be improvements to be made.
How we do it
• Combination of:
• Use Cases (UML people call them use cases,
HCI people call them scenarios)
• Then Hierarchical task analysis (HTA), which
isn't as hard as it sounds.
Use Case Example (1/2)
•
•
•
•
1.
2.
3.
4.
5.
6.
Use Case: "Buy a Book"
Description: Customer orders a book, using the ISBN
Actors: Customer, system
Additional Use Cases Needed: "Complete Order"
Customer locates the search field
Customer enters ISBN into search field
Customer presses the search button
System displays the description page for the book
Customer verifies that this is the right book and presses the
"order" button
Customer completes the order (see "complete order" use case)
Use Case Example (p2/2)
• Alternative 1: ISBN incorrectly entered:
At step 5 the customer realises that this is the wrong book
5a Customer sees wrong book displayed
5b Customer locates the search field and returns to step 2.
What's in a Use Case? (1/2)
•
•
•
•
•
Name in Verb-Noun format
Version
Goal – what is to be accomplished
Summary – overview of what it does
Actors – primary actors act on the system,
secondary actors are acted on.
• Preconditions
• Trigger – what causes the sequence to start
What's in a Use Case? (2/2)
• Basic course of events – what usually happens
• Alternative paths – what can happen
• Postconditions – system state after the
sequence
• Notes – explanations which did not fit the
categories
• Author and date.
Now You!!!
• Write a use-case for buying a bunch of
bananas using one of Tesco's new customeroperated checkouts.
• Compare results in pairs
• Plenary
Scenarios
• HCI enthusiasts like to write stories of how a
system could be used, called Scenarios, e.g.:
"A man wearing an overcoat and a backpack came
up to the machine and stared at it for two or three
minutes. Whilst he was doing that a couple of
younger men came up behind him and were trying
to look over his shoulder. Finally he put his hand in
his pocket and inserted some money. He pressed
two buttons, B and 7, and watched as a packet of
crisps was deposited in the tray."
Andy Dalreach needs a doctor’s appointment for his young daughter
Kirsty in the next week or so. The appointment needs to be outside
school-time and Andy’s core working hours, and ideally with Dr. Fox, who
is the children’s specialist. Andy has already picked up a leaflet from the
medical centre introducing the new online appointments system and
obtained his ID and password from the receptionist. He uses a PC and
the Internet at work, so has no difficulty in running up the appointments
booking system. He logs in. Two drop down boxes allowing him to select
one or more doctors and dates are displayed, He chooses to see free
times for Dr. Fox for the next two weeks. The free times are displayed as
a simple calendar. The appointment slots are highlighted as Andy moves
his mouse over the screen. As instructed by a short note at the top of the
screen, he clicks on a time that suits him. A pop-up message asks him to
confirm the time and date. Andy does so, and sees that the time he has
chosen is now greyed-out on the calendar. A further pop-up message
asks him if he would like an email reminder of the appointment and/or a
printout of the time and date. Andy selects ‘no’ for email because his
mailbox is always overfull and prints out the appointment.
Things to note
• Relevant information about the user
• Details of interaction sequence and presentation
• Often give names to the participants in a scenario to
make the interaction seem more real
– But not essential
• A concrete example of the system being used, not a
generalised account of all the possible functions and
alternative results
• Complementary tool to personas (of which much more in
Interaction Design module)
Limitations of Use Cases
• Will not tell us if a scenario is inefficient
• Will not tell us whether or not humans are
capable of the operations.
• Will not tell us how much training is needed
• If the task is mission-critical or safety-critical,
needing efficient, error-free performance, use
Hierarchical Task Analysis.
Hierarchical Task Analysis
Task levels
• Tasks are divided into:
• User Level
– ("buy a book")
• Application Level
– (The screens/pages needed to accomplish the
purchase of a book)
• Platform Level
– (Clicking on menus and text fields)
Task levels – User Level
• At user level, we view what the user's goal is
and what triggers the user towards attaining
that goal. The goal need not be accomplished
solely through your own technology – a book
may be bought in the shop round the corner
instead.
Task levels – Platform Level
• Platform level task procedures are usually
imposed by the interface. The interface
provides a set of Lego blocks for building, such
as text fields and pull-down menus.
• These are usually generic to the medium. In
high-street shopping they could be "park car",
"walk into shop", "ask assistant for book"
Task levels – Application Level
• This is the bit we have to think about
• Platform level operations are combined as
efficiently as possible into user level tasks.
• There is no one answer.
Programme Video-recorder to
record Thursday's East-Enders
Set the date
Set the year
Set the month
Set the day
increment day
decrement day
Now you!!!
• In pairs, do a task analysis on sending an email
to me over the Napier system.
• Then try to improve on it.
Task Analysis for Website Design
1. List the primary user goals
2. List the steps that a user must take to
accomplish the goals
3. Optimise the procedure
– Minimise the steps
– Improve consistency between similar procedures
– Reduce user errors
Capturing an existing task
• Before trying to improve on it, you may want
to know how a task is done today,.
• An instruction manual is a good start, but
people often vary procedures in ways of their
own.
• It's no good asking them – they'll:
– Give you the answer they think you want to hear
– Not remember all the steps
Capturing an existing task
• Sit beside a user and watch them while they
interact with the system. Video might help. A
talking protocol might help.
• Alternatively, get the user to train you how to
use the system. They are the experts – they
do it every day.
How far do you decompose a task?
• ... A good question. It is possible to
decompose a task infinitely into tiny tasks.
• Follow your instinct.
• Perhaps a good point to stop is at mouse
movements or keystrokes.
• If someone else can do the task, based on
what you have recorded, stop there.
Goals of Task Analysis
• Brevity and Clarity
– Aim for tasks with a maximum of 20 steps, though
a maximum of 15 is better
– If it is difficult to describe on paper, it is probably
too difficult for users to do.
• Minimise the number of screens needed
Human-Error Tolerant Design (1/2)
• Financial and medical web applications are
examples of applications where errors could
be dangerous, costly or irreversible.
• Here are some aspects to address:
– Prevention – design the user interface to minimise
the chance of error. This is the best of all the
solutions
– Reduction – be explicit about what an action will
do. Teach user how to recover from errors
Human-Error Tolerant Design (2/2)
– Detection and Identification – the system shows
the user what they have done, so the user can
reverse the action if it was wrong
– Recovery – system allows rapid error recovery and
resumption of task (i.e. not just abort)
– Mitigation – people will always make errors, so
system is designed so that an error cannot cause a
disaster
Example of poor design
• On next page:
– trunking end-caps are designated by the dimensions
of the trunking they fit. E.g. 16 x 38 or 50 x 50.
– However, the product list gives part number but not
dimensions.
– If you want dimensions, you need to open the part
details in a new tab.
– This is probably because the part details are in a
different database.
(search-list-detail pattern)
Bibliography
• Benyon, D., Turner, P., and Turner, S. (2005)
Designing Interactive Systems, Addison
Wesley, Harlow, UK.
• Brinck, T., Gergle, D., and Wood, S. T. (2002)
Usability for the Web: Designing Web Sites
that Work, Morgan Kaufmann, San Francisco,
USA