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

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

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)

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