Task
Analysis
Primary Reference Sources
Kirwan, B and L.K. Ainsworth (1992) (Eds) A Guide to Task Analysis.
Taylor and Francis, London.
D Poulson (Ed), (1996) USERfit. A practical handbook on user-centred
design for Assistive Technology. European Commission, DGXIII TIDE Project
1062.
Summary Description
Task analysis is a term covering several techniques. Common elements for
the techniques is that they all describe interactions between humans and
their environments in a systematic way. Task analysis can be defined as
the study of what a user is required to do, in terms of actions and/or
cognitive processes, to achieve a system goal. Task analysis therefore
is a methodology which is supported by a number of techniques to help the
analyst collect information, organise it, and then use it to make various
judgements or design decisions.
Typical Application Areas
Task Analysis has classically been used in areas where it is possible to
define users’ actions at the computer in terms of specific goals for the
satisfaction of which the users interact with the software. For situations
where the users’ interest is likely to be unfocussed, such as browsing
or searching, task analysis may still be useful, but yield less tangible
results.
Benefits
It should be noted that even if not used in any formal way the principles
of task analysis can be of considerable value in focusing attention to
relevant issues to consider when designing products from the users’ point
of view.
Limitations
In the hands of inexperienced practitioners, too much level of detail may
be entered into; for systems with diffuse objectives, time may be wasted
by attempting to apply task analysis to intractable material.
Cost of Use
Although task analysis may be done cheaply by one experienced practitioner,
this is seldom recommended, and a combination of task analysis and some
other group-orientated method will be found to yield most benefit.
Costs of acquisition
Task analysis is still largely self-taught, although annual conferences
in the human factors area sometimes include tutorials on varieties or applications
of task analysis. Within the EUSC a number of partners are specialists
in this area (e.g. HUSAT
and SINTEF) and they would be able to
offer skills training and guidance.
Suitability for requirements engineering in telematics
The potential benefits are so great that all projects are recommended to
do at least some task analysis, even if at a relatively high level of abstraction.
See also Usability Context Analysis which contains
elements of task analysis.
Detailed Description of Method
Tasks can be analysed and described from different perspectives. They might
be described in terms of frequencies, logical dependencies, temporal dependencies
and in terms of both the human and contextual limitations. The relations
between the different constraining factors is also often rather complex.
This make a proper understanding of tasks without tools to guide the analysis
very difficult.
To design computer systems in a task based way four techniques are of
particular relevance:
-
Hierarchical Task Analysis (HTA) and Tabular Task Analysis (TTA)
-
Timeline Analysis (TA)
-
LINK analysis
INSERT FIGURE 1 HERE
Hierarchical Task Analysis (HTA) and Tabular Task Analysis (TTA)
Hierarchical Task Analysis (HTA), the most commonly used task analysis
technique, represents the relationships between tasks and subtasks. It
records system requirements and how these can be achieved, including the
order in which tasks and subtasks can take place. It can be recorded in
a tabular form and/or pictorially. If recorded pictorially it resembles
a tree with branches and sub branches as required.
Task analysis involves three closely linked stages: information collection,
information recording and analysis.
Information collection procedures include assessing existing documentation
(e.g. operations manuals, procedures, safety reports, previous task analysis
studies, drawings, screen pictures), establishing what people do in specified
circumstances (in both normal and abnormal situations), questioning/interviewing
(getting experienced personnel to describe what and how they do things,
what information they need, and how they determine if a task has been carried
out satisfactorily). Questioning can be formal/informal.
The results from the above information collection procedures should
be verified by other experienced personnel.
Information recording will initially be in note form. It will eventually
be translated into the final report. One information recording technique
is to draw a tree diagram of tasks in their relation to sub-tasks.
The aim of the HTA is to re-describe the task progressively as more
information is collected. Tasks are described in terms of elements which
are recursively broken down into sub elements and so on. The entries in
the boxes of the diagram are the names of the operations and consist only
of a few words.
Some tasks may be broken down into greater detail in sequence as a plan.
A plan describes how the task operations are put together as a complete
activity, or shows the circumstances under which one operation is performed
rather than another. Plans may be cross referenced and added to the hierarchical
table.
In addition, where operators are time dependent or time critical, e.g.
small time intervals or simultaneous actions required from an operator,
time may be added at the beginning of each action, starting at zero to
form a timeline analysis.
Information analysis is the final phase. The information gained is used
to yield the basic data for design decisions. For example, if a set of
displays is to be designed, then the focus will be on information flow
across the interface. These sources may then be used to guide design activity.
Another example would be the layout of a set of controls, where the
sequence of operations would be important. The sequences illustrated by
the task analysis would be isolated and used to guide decisions on optimal
layout, for example to minimise the amount of physical movement needed.
Timeline Analysis (TA)
TA is used to document the temporal aspects of tasks. It is well suited
to represent task dependencies and possible resource problems in performing
tasks. It is often difficult to collect the information needed to produce
a TA. In absence of observational data estimates or guesses of temporal
relations are used.
LINK analysis
LINK analysis is the simplest of the techniques. It simply demonstrates
the frequency of linkage between tasks. It might be used to identify how
and how often a user need to navigate from one interface element to the
other. The technique can easily be performed. It is most often based on
observational data.
The process of designing a system
The HTA methodology is a useful tool to support the design of computer
systems. This is particularly linked to the fact that the HTA provides
a consistent logical description of the interdependencies of tasks and
therefore provide a rational framework for description of possible user
interfaces. A typical process of task based design would imply several
steps.
First it is important to establish a description of the situation here
and now, This will serve as a communication tool with the users and the
user organisation and ensure that the starting point is a proper understanding
of the tasks as they are performed in the work system.
This preliminary HTA is transformed into a Tabular Task Analysis (TTA).
In this format judgements about the allocation of function between man
and machines is done. At the same time new tasks that are created by the
introduction of a new IT system is written in. We should like to stress
that this is not a detailed analysis down to keystroke level. It is possible
to construct the basic commands for the new system at this stage.
Based on the TTA a new HTA describing the dependencies of tasks interacting
with the new system is developed. This graphical description is used to
identify tasks that are performed many places in the system, tasks that
are linked to specific goals (i.e. start up, calculate data etc.) and tasks
that need further analysis. If done properly this format can be used to
describe the windows structure and dialogue elements of an interface.
Go to top of page
Go to Methods Table (by Lifecycle)
Go to Methods Table (by Special Needs)