Task Scenarios

1 Introduction

Task scenarios are stories.  A wide variety of styles and formats are used in software engineering, see [Alexander & Maiden] for examples.  Types of scenario used in interaction design include:

  1. Scene setting narratives
    • Used to convey the purpose and functionality of the proposed system to all of the stakeholders
    • May be employed in the concept or other project initiation documentation
    • May be elaborated by the inclusion of personae
  2. Task focussed
    • Has much in common with the software engineering concept of Use Cases
    • Essential or Abstract Use Cases, [Constantine & Lockwood] useful for initial functional design as a precursor to
    • Task Scenarios, the type described here, based on [Redmond-Pyle & Moore]

1.1 Task Scenarios

These give a detailed answer to the question: how is the user going to operate the thing you are to design?  It records descriptions of the users’ tasks to make clear:

  • what the user is trying to achieve (their ‘practical goal’)
  • the environment within which the user works (task context)
  • what the user actually does in detail

A general description of a task such as, “take orders placed over the phone” or “use the app to find the time of the next bus” need breaking down into the detailed steps that actually make up the task. The system you are designing must support these detailed steps, so they need to be documented and validated.

To make sense of the task it is necessary to understand what the user thinks they are trying to achieve by it, their ‘practical goal’.

It is also important to record details of the environment where the task is carried out. Is it an office setting, on the factory floor, using a lap-top while travelling, etc. This information may make a crucial difference to the design.

The recorded description takes two forms:

  1. Task Scenarios
  2. an Abstract Task Model (addressed on a following page)

Recording detailed scenarios is crucial in the design process.  It should be done at least for the main tasks. However as you will see, it can be labour intensive.  Once a number of scenarios have been recorded the documentation needs to be maintained, as details are corrected or added.  They take the form of bodies of text which have to be read sequentially to extract useful information.  A method of representing the scenarios in a more abstract form that deals with some of these issues will be covered in a following page.

2 Method

2.1 Overview

Here is my way of thinking about scenarios, summed up in this little verse of journalistic advice by Rudyard Kipling.

“I keep six honest serving-men
(They taught me all I knew)
Their names are ‘What’ and ‘Why’ and ‘When’
And ‘How’ and ‘Where’ and ‘Who’.”

  1. What – The work carried out; the title of the scenario
  2. Why – The goals of the task
  3. When – The circumstances in which this task is initiated and frequency
  4. How – The sequence of actions that make up the task
  5. Where – The environment in which the task is carried out
  6. Who – The user groups involved in the task

2.1.1 What

The name of the task expressed as how the user would describe what they are doing. E.g., on a travel agency web site ‘Booking a Holiday’, on a business system ‘Amending a previously placed order’.

2.1.2 Why

The practical goal sought by the person carrying out the task. E.g., ‘to have booked a holiday for two people in Ibiza during the last two weeks of August, paid a deposit and received confirmation.’

2.1.3 When

What circumstances cause this task to be carried out. E.g., ‘An order has previously been placed on the system and an amendment to this order has been received by email.’

2.1.4 How

The detailed steps that are needed to carry out the task. The idea here is to create a ‘script’ so that an actor following it line by line would actually carry out a correct instance of the task.

2.1.5 Where

Details of the location in which this task is carried out; its physical characteristics and the way that the work is carried out (individually, with others etc.)

2.1.6 Who

Which of the user groups you have identified actually carries out this task.

2.2 Task Scenario Format

This is how I suggest task scenarios can be documented. It is not necessary to include the ‘What, Why, Where …’ list on the left-hand side.
A simple task scenario example with the individual elements of text tagged to indicate their function.There are three sections:

  1. The meta-information about the task, (the what, why, where and who)
  2. A situation or set of circumstances for a task, described in terms of any inputs, the prior state of the system and the environment (when)
    • Should include the trigger that causes the task to be carried out, or depending on the prior state, a particular version of the task
  3. A script describing how a user performs the task on this occasion, (how)
    • The scenario is expressed in terms of a sequence of user actions on significant artefacts relevant to the task

2.3 The meta-information about the task (what, why, where and who)

2.3.1 What: Scenario Title

Will be used by design team members when discussing the design as a convenient way of identifying the scenario, so it should be succinct, descriptive and distinct (from other similar scenarios).

2.3.2 Why: The Practical Goal

The practical goal or intended useful outcome is only one of a number of goal types that may be in play (see that section of the User Profile).  However it is the one most immediately relevant to the detailed actions that the user engages in and really relates to the intention forming stage of Don Norman’s ‘gulf of execution’. [Norman]  It is a specification of the new state of the external world that the user wishes to bring about.

2.3.3 Where: Environment

Relevant aspects of the environment may include:

  • Qualities of the physical location (e.g., outside in bright sunlight, in a moving vehicle, on a dirty and noisy factory floor, etc.).
  • The software platform (e.g. desk-top PC, mobile device, embedded system, etc.).
  • The number of participants in the interaction (e.g., sales person with typically two customers present, subject to oversight by a manager, in front of a audience, etc.).  Further details are given under the ‘user group’ heading below.
  • Urgency or duress involved in the interaction (e.g., responding to a demanding customer, soldier under fire, plant operator dealing with emergency, etc.).

2.3.4 Who: User Group

All of the users involved in the scenario interaction who may be any of:

  • Direct users – physically manipulating the system.
  • Indirect users – has their use of the system mediated by a direct user (e.g. a customer on the phone to a call-centre).
  • Remote users – receive printouts or other artefacts generated by the system.
  • Collateral users – receive unintended output from the system and may initiate unintended inputs.
  • Prohibited users – who must be prevented from using the system.
  • Support users – who maintain the system and deal with faults.

2.4 Circumstances pertaining at the commencement of a task (when)

This includes the status of any relevant data as already in the system or not, and the trigger that initiates the scenario.

2.5 Task script (how)

Task Scenarios are Concrete examples of individual tasks:

  • They contain example data
  • Where choices are made in the task, they follow one route only

Example data is included to make the account of the task more ‘real’ to the eventual reviewer, to distinguish different data driven variations of the task, and to confirm any recording of system data characteristics (data dictionary) already made.   E.g:

Where a customer’s name is entered, make up an example name (and think about the size of the field, any special characters used, etc). Could Swedish people use this service?  If so, then an example using hyphenation and an umlaut is: ‘Anna-Lisa Björling.’  This will have implications for the character set available, and the size of the field.

Following the idea of the scenario being captured as a script, it is important that it fully documents only one example of the task being carried out.  Only one route through the task is followed. If different routes (choices or sequences of steps) are possible, consider documenting different scenarios.

We will use the scenarios documented in this way to identify the data items that are manipulated through the interface that we will design.  We are interested in:

  • the names given to data items that the user recognises
  • any structure that data items possess, e.g., an address will be made up of house number, street, district, town, county, postcode
  • the actions applied to these data items described in ways that the user would recognise, e.g., the structured data item ‘booking’ may be; made, pencilled-in, confirmed, changed or cancelled.

The script should not refer to details of the interface yet to be designed.  We should record the actions necessary to perform the task without committing ourselves to particular ways of implementing it.  E.g., if a step in an on-line shopping process involves the user in choosing an item to purchase, we may actually implement this in any number of ways; the item could be selected from a pull down menu, presented as a button or link on a page, dragged and dropped into a representation of a shopping basket, etc.  As far as the description of the task is concerned, we record that the item is ‘selected’ but not how this is to be implemented.  We make that decision later during the design phase.

2.6 Task Scenario Notation

This is an example of a task scenario involving two users in different roles, one a direct and the other an indirect user.
An example Task Scenario based on an order-entry process involving a sales clerk and a customer.An arbitrary decision has to be made about how much detail of task elements peripheral to the manipulation of the computer system should be recorded. In this example, when the sales clerk answers the phone they may say something along the lines of: “Hello, Bert’s Car Spares here, John speaking, how can I help you?” Should this be recorded? Definitely if it plays a part in the task, e.g., if the customer needs to ring back and speak to the same clerk. However, if this is not the case, then it can be left out to keep the scenario simple.
Note that the answer the clerk gives to the customer’s question gives different information than was originally requested, i.e., the price including VAT. That this is usually the case would have been picked up from listening to sales clerks answering customer queries with the pre-existing system.  In this instance the clerk believes that he is talking to a private customer, whilst if a trade customer the price exclusive of VAT would be given.

2.7 Sources of Information

There are a number of sources of information to feed into the scenario writing process;

  • Any existing analysis and requirements documentation
  • User profiles
  • Observation of users
  • Manuals, training materials, etc.
  • Forms, documents and any other artefacts used in the task

If some preliminary systems analysis has already been done details may already have been recorded. However it is important to check that the data items identified are named using the terminology actually used by the users that you will be designing for.

In creating user profiles and identifying user classes you will start to record the task that users carry out. Also in documenting task scenarios you may identify different user groups that you were not previously aware of.

Observing real users actually carrying out the task using the pre-existing system is the best source of information and should be made use of if at all possible. Unfortunately it is not always possible; access to the physical location of the task may not be allowed for security or health and safety reasons, there may be company politics that prevent it (particularly if some of the people you wish to observer may be made redundant as a result of the system you are developing) or you may be developing a completely new system supporting a task that no one currently does for you to observe.

Manuals and training materials are also useful, but do not rely on the information that they contain exclusively. They may be out of date, or more often will describe the task in a ‘perfect’ way that is not realised in practice. Often compromises and short-cuts will be used in real life.

Collect any copies of forms and other paper documentation used in the task, in particular filled-in forms. Look for annotations and markings on the form that convey additional information. If forms contain information about real people (customers, staff, etc.) then there may be data protection issues to be dealt with and the forms may need to be anonomised before you can see them.

2.8 Point to note

Give your scenarios good descriptive names. You will need to refer to them in meetings of the design team, so making it easy to identify and distinguish specific scenarios is important.

Make sure to record the meta-information about the scenario, the what, why, where and who.

Where a data item is mentioned, give an example.

Where multiple users are involved in a task, identify them by their role names.

Record actions of the user and their inputs to and receipt of output from the system.

  • Input of data to the system
  • Receipt of data from the system
  • Transfer of data: to other users, documents, systems, etc.
  • Manipulation of data; calculation, comparison, etc.
  • Access to other resources: documents, notice boards, other people, etc.

Do not record the hidden computational processes of the system. This is particularly important for software professionals to bear in mind, as the temptation to start ‘programming’ will be strong.  (A software engineering Use Case should complement the Task Scenario, filling in the system actions.)

Do not give details of the interface that is to be designed.  Keep your description of manipulation of data via the interface implementation neutral.  However this does not apply when part of the task involves using a pre-existing computer system that will not be redeveloped. Then precise details of the manipulation of the pre-existing interface must be recorded. This may have a very strong influence on your design.

Note details of the task context, including:

  • Physical environment
  • Frequency of task
  • Time constraints
  • Concurrency with different tasks
  • Concurrency with different versions of the same task
  • Prioritisation and scheduling
  • Resource conflicts
  • Individual or group activity
  • Known problems or error situations
  • Criticality (Life & Death, Economic Consequence, Legal Consequences, Data Corruption, etc.)

These notes will be significant when creating appropriate usability requirements.

3. Validation of the recorded scenarios

It is important that documented scenarios are validated by the intended or surrogate users where at all possible.  Failing that stakeholders in the project should review them.  Ask them to read through the scenario and tell you if they notice anything wrong or unusual, e.g., the scenario is not formally incorrect, but they just wouldn’t do it that way.

Where issues are raised, the scenarios should be modified and possibly, different scenarios added, before they are again reviewed by that user and then ideally by additional users.

4. Appropriate use of this method

This is one element of the overall process that should not be skipped.  Whilst you may believe that you fully understand the detailed steps of the task you are designing for, the discipline of writing out the steps almost invariably leads to deeper insight and reveals detail that would otherwise be missed.

5. References

Alexander, I. & Maiden, N.  (2004) Scenarios, Stories, Use Cases : Through the Systems Development Life-Cycle, John Wiley & Sons

BS EN ISO 13407:1999 The Human-centred design process for interactive systems.

BS ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) — Version 1.4.2

Constantine, L. L. and Lockwood, L. A. D. (1999) Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design, Addison-Wesley Professional.

Norman, D.A. (1988) The Design of Everyday Things, MIT Press

Redmond-Pyle, D. & Moore, A. (1995) Graphical User Interface Design and Evaluation (GUIDE): A Practical Process, Prentice-Hall.

Preece, J., Rogers, Y. & Sharp, H., (2002) Interaction Design: Beyond human-computer interaction, John Wiley & Sons.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s