Task Analysis

37
Task Analysis

description

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 - PowerPoint PPT Presentation

Transcript of Task Analysis

Page 1: Task Analysis

Task Analysis

Page 2: 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

Page 3: Task Analysis

A Typical Transaction

HomeProducts page(Teddy bear, Lego, Barbie doll, Blocks, Scooter

Teddy bear

Order Form Verify PurchaseOrder Confirmation

Page 4: Task Analysis

Alternative A

HomeProducts page(Teddy bear, Lego, Barbie doll, Blocks, Scooter

Teddy bear

Order Form Verify PurchaseOrder Confirmation

The teddy bear is advertised on the home page.

Page 5: Task Analysis

Alternative B

HomeProducts page(Teddy bear, Lego, Barbie doll, Blocks, Scooter

Teddy bear

Order Form Verify PurchaseOrder Confirmation

A button on the products page takes us straight to the order form

Page 6: Task Analysis

Alternative C

HomeProducts page(Teddy bear, Lego, Barbie doll, Blocks, Scooter

Teddy bear

Order Form Verify PurchaseOrder Confirmation

A button on the home page takes the customer directly to the order form

Page 7: Task Analysis

Alternative D

HomeProducts page(Teddy bear, Lego, Barbie doll, Blocks, Scooter

Teddy bear

Order Form Verify PurchaseOrder Confirmation

A cookie tells us who the customer is, so one click on the home page buys the product

Page 8: Task Analysis

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

Page 9: Task Analysis

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

Page 10: Task Analysis

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.

Page 11: Task Analysis

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.

Page 12: Task Analysis

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"

1. Customer locates the search field2. Customer enters ISBN into search field3. Customer presses the search button4. System displays the description page for the book5. Customer verifies that this is the right book and presses the "order"

button6. Customer completes the order (see "complete order" use case)

Page 13: Task Analysis

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 displayed5b Customer locates the search field and returns to step 2.

Page 14: Task Analysis

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

Page 15: Task Analysis

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.

Page 16: Task Analysis

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

Page 17: Task Analysis

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

Page 18: Task Analysis

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.

Page 19: Task Analysis

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)

Page 20: Task Analysis

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.

Page 21: Task Analysis

Hierarchical Task Analysis

Page 22: 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)

Page 23: Task Analysis

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.

Page 24: Task Analysis

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"

Page 25: Task Analysis

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.

Page 26: Task Analysis

Programme Video-recorder to record Thursday's East-Enders

S e t the ye ar S e t th e m o n th

in cre m en t d ay d e crem en t d ay

S e t th e d ay

S e t th e d a te

Page 27: Task Analysis

Now you!!!

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

• Then try to improve on it.

Page 28: Task Analysis

Task Analysis for Website Design

1. List the primary user goals2. List the steps that a user must take to

accomplish the goals3. Optimise the procedure

– Minimise the steps– Improve consistency between similar procedures– Reduce user errors

Page 29: Task Analysis

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

Page 30: Task Analysis

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.

Page 31: Task Analysis

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.

Page 32: Task Analysis

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

Page 33: Task Analysis

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

Page 34: Task Analysis

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

Page 35: Task Analysis

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)

Page 36: Task Analysis
Page 37: Task Analysis

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