Task Analysis

1
Task Analysis
2
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

3
A Typical Transaction
Products page (Teddy bear, Lego, Barbie doll,
Blocks, Scooter
Teddy bear
Home
Order Confirmation
Order Form
Verify Purchase
4
Alternative A
Products page (Teddy bear, Lego, Barbie doll,
Blocks, Scooter
Teddy bear
Home
Order Confirmation
Order Form
Verify Purchase
The teddy bear is advertised on the home page.
5
Alternative B
Products page (Teddy bear, Lego, Barbie doll,
Blocks, Scooter
Teddy bear
Home
Order Confirmation
Order Form
Verify Purchase
A button on the products page takes us straight
to the order form
6
Alternative C
Products page (Teddy bear, Lego, Barbie doll,
Blocks, Scooter
Teddy bear
Home
Order Confirmation
Order Form
Verify Purchase
A button on the home page takes the customer
directly to the order form
7
Alternative D
Products page (Teddy bear, Lego, Barbie doll,
Blocks, Scooter
Teddy bear
Home
Order Confirmation
Order Form
Verify Purchase
A cookie tells us who the customer is, so one
click on the home page buys the product
8
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

9
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

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

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

12
Use Case Example (1/2)

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

13
Use Case Example (p2/2)

• Alternative 1 ISBN incorrectly enteredAt 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.

14
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

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

16
Now You!!!

• Write a use-case for buying a bunch of bananas
  using one of Tesco's new customer-operated
  checkouts.
• Compare results in pairs
• Plenary

17
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."
18

• Andy Dalreach needs a doctors appointment for
  his young daughter Kirsty in the next week or so.
  The appointment needs to be outside school-time
  and Andys core working hours, and ideally with
  Dr. Fox, who is the childrens 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.

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

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

21
Hierarchical Task Analysis
22
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)

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

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

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

26
Programme Video-recorder to record Thursday's
East-Enders
27
Now you!!!

• In pairs, do a task analysis on sending an email
  to me over the Napier system.
• Then try to improve on it.

28
Task Analysis for Website Design

• List the primary user goals
• List the steps that a user must take to
  accomplish the goals
• Optimise the procedure
• Minimise the steps
• Improve consistency between similar procedures
• Reduce user errors

29
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

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

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

32
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

33
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

34
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

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

36
(No Transcript)
37
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