(based on Clayton Lewis and John Rieman's handbook, Task Centred Interface Design shareware from:

ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book/chap-2.v-1)

Tasks

Hierarchical task analysis: goals, preconditions, steps…

The rationale here is similar to Cooper's thinking on personas, as discussed last week. Many people call these concrete tasks scenarios although Lewis and Rieman use scenario to refer to the working through of the concrete task using the new interface. I'll use scenario to mean concrete task, and workedscenarioto refer to the conjunction of scenario and interface. Clear??? Not very.

Example: a concrete task or scenario based on a Traffic Modelling System

On an existing model, change the speed limit on Lewes Rd west from Coldean Lane to The Avenue. Calculate the changes this would make to flow of traffic entering Lewes Rd from The Avenue assuming speeds on Lewes Rd from 30 to 50 mph in increments of 5 mph and display the results in parallel. This is needed for a council meeting the next day.

• tells what the user wants to do, not how they’ll do it
• is very specific
• it describes a complete job
• checking the edges of a job, i.e. inputs and outputs, interaction with others, context
• it concerns a centrally important task, not one of marginal significance

Help Desk operator retrieves details of previous call from Dave from University of Brighton computing centre about the missing cable for the colour scanner they had delivered on 24 September 2000.

Orders clerk notes Mrs Yvonne Brown’s order for a pair of Nike trainers size 4 white, from p. 511 of the Spring catalogue, # 2345564/678, enters her name for the Prize Draw and notes that as the dog has eaten her catalogue she needs a new one. Tells Mrs Brown whether or not her previous payment has been received.

Prospective student finds the name and telephone number of person responsible for Postgraduate study in the School of Information Technology.

Customer tries to buy a Cheap Day Return from Brighton to Gatwick at 08.55 am for self and 13 year old daughter.

Employee reserves two seats for Reservoir Dogs at 7.30 on Thursday night. Customer wants places by the aisle. Phone call made at 7.00 - payment by Visa card.

Concrete tasks work as a good decision-making system for design. Decisions are not abstract (e.g. let’s have modes) but concrete (when user has chosen the rectangle tool, clicking in the drawing area will mean "make another rectangle" not "select").

Worked scenario = scenario + interface design

They spell out what a user would do and see when carrying out a task with the system. Represented mostly as storyboards in early phases.

Example of worked scenario for an ATM :

Use them later in prototyping, usability specification and evaluation stages.

Possible objections (from L & R)

"This example task idea seems crazy. What if you leave something out? And won’t your design be distorted by the examples you happen to choose? And how do you know the design will work for anything other than your examples?"

Th equick answer is that at least we'll be sure that the design will work for at least one example, which is more than could be guaranteed without precise scenarios. However, further steps to safeguard the project coudl include:

Cooper Interaction Design company site. Two chapter's of Alan Cooper's The Inmates are Running the Asylum are available on-line here, and there is a good stock of design resources.

An interesting paper, User-Generated Scenarios for Requirements Specification and Design Rationale, by Dennis C. Neale and Jonathan K. Kies, of HCIL at Virginia Tech.