Task Analysis

Goal

Task analysis describes how work gets done, from the overall goal down to the level of detail the purpose of the analysis requires. It shows which parts of the work call for training, a tool or automation. A task is an activity with a start and an end that can usually be observed.

HTA names the result each part of the work must achieve. The deliverable consists of a diagram and a table. The numbered hierarchical diagram carries a plan at each level. The table gives the reason for stopping and notes for each sub-goal.

According to Stanton (2006), HTA is also used to design and evaluate interfaces and to allocate functions between people and machines. It underlies job aids, error prediction and workload assessment. The Usability Body of Knowledge uses it to find inefficiencies in existing work that then feed the requirements of a product.

Usage

When to use it

• A process to improve: describe the real work before changing it and find its inefficiencies.
• Training needs: the original use; the difficult sub-goals become the content of the training.
• New software for an existing task: start from the user's goals rather than from the current screens.
• Partial automation: assign each sub-goal to the person or to the system.
• Costly errors: the stopping rule takes the analysis deeper on the sub-goals where the probability of failure times its cost is high.
• A procedure or job aid to write: the plans give the order and the conditions that the procedure or job aid sets out.
• Teamwork or a task shared with a machine: HTA describes both in the same notation.
• Remote teams: the analyst observes screen work through screen sharing and physical work on site.

When not to use it

• A task that does not exist yet: HTA describes existing work; sketch the future task by prototyping.
• A tree of functions or deliverables to break down: there are no goals or plans to describe; use functional decomposition.
• The physical layout of the workplace: HTA describes goals, not space; use workplace layout analysis.

Description

Origin and principles

HTA extends Taylor's scientific management and Gilbreth's time and motion studies. It later draws on control theory. Its plan derives from the TOTE unit (Test-Operate-Test-Exit) of Miller, Galanter and Pribram (1960): test the state, act, test again and exit once the goal is met. Kirwan and Ainsworth (1992, cited by Stanton) regard HTA as the best-known task analysis technique.

In 1971 Annett, Duncan, Stammers and Gray (cited by Stanton) set out the principles of HTA:

1. A task is an operation defined by a goal that can be measured in concrete terms.
2. An operation breaks down into sub-operations. Each has a sub-goal measured by a performance standard.
3. An operation includes its sub-operations. This inclusion forms a hierarchy. The sub-goals do not necessarily run in sequence.

Annett and his colleagues (1971) derive a writing rule from them: the analysis describes the sub-goal of each operation. Write "check that the delivery matches the order" rather than "open the Orders screen". A sub-goal leaves open how it is reached. The analyst can therefore compare two ways of working or hand a sub-goal to software without rewriting the hierarchy.

Plans

The plan is the control structure of a level. It states when each sub-goal starts and when the level ends. Every goal that has sub-goals carries a plan. The analyst reads the plans from the top down to the sub-goals they trigger. The analyst then climbs back up as each exit condition is met.

The original HTA had three rules: chaining (a fixed sequence), selection and concurrency. Shepherd (2001) distinguishes six types of plan: fixed sequence, contingent sequence, choice, optional completion, concurrent operations and cycles. A complex task combines several. Ormerod and Shepherd (2004) propose four plan models.

Each plan names its exit condition: the state that ends the level. "Exit when the customer has received the reply and the case is closed" is an exit condition. Without one the analysis loops inside a level.

The stopping rule

Any hierarchy could go down to the movement of a finger. To redescribe a sub-goal is to replace it with its sub-goals and their plan. The stopping rule sets how far the analyst redescribes. Annett and his colleagues (1971, cited by Stanton) state it as P × C. The analyst stops redescribing a sub-goal when the probability of failure (P) multiplied by its cost (C) is acceptable.

Annett (2004, personal communication to Stanton) presents P × C as a statement of principle rather than an exact calculation. The analyst therefore puts a figure on neither P nor C. For each sub-goal the analyst asks whether a trained person is likely to fail and what the failure would cost. When the analysis is done for training, the question concerns a person who has completed the planned training. A sub-goal where failure is unlikely or harmless stops at the first level. A sub-goal where an error leads to an unjustified refund of CHF 2'000 is redescribed.

Piso (1981) proposes a simpler test: stop when the sub-goal is clear to the analyst and to the subject-matter experts. Annett and his colleagues consider stopping one of the hardest aspects of task analysis. They prefer to stop early. On the diagram the analyst underlines the last sub-goal of a branch. In a list the line ends with "//". Functional decomposition asks the same question of depth for a tree of functions.

Running the analysis

Stanton adapts seven heuristics from Stammers and Shepherd to guide the analyst. He states that there is no single right way to carry out an HTA.

1. Define the purpose of the analysis. Training, interface design, function allocation or process improvement: the purpose sets the depth and the content of the notes.
2. Define the boundaries of the system. State where the task starts, where it ends and who takes part: one person, a team or a person working with software.
3. Cross-check several sources of information. Observation, interviews, manuals, demonstrations talked through by a subject-matter expert and simulation check one another.
4. Write the goals and sub-goals. Each sub-goal starts with an action verb that names a result. Patrick et al. (1986, cited by Stanton) add a performance standard and conditions: "record the complaint in the CRM on the day it arrives". Most analyses carry these two elements in the Notes column.
5. Keep between three and ten sub-goals under each goal. Patrick et al. advise four to eight. These are rules of thumb. The analyst groups the operations that belong together under one goal. Above ten sub-goals the analyst looks for a grouping. A goal never gets a single sub-goal, which would only restate it.
6. Link each goal to its sub-goals through a plan. Each plan carries its exit condition.
7. Stop when the analysis is enough for its purpose. The stopping rule decides each branch.

Collecting and analysing the data

According to Rosala (Nielsen Norman Group), the analyst first collects data through contextual inquiry, which observes and questions people at their workplace. The analyst also runs interviews, asks users to keep a diary or simulates the task. Another option is to observe a period of work and record the tasks with their duration and frequency. Rosala warns against relying on self-report alone or simulation alone. She asks for users to be observed in their work context. People who are interviewed often describe the written procedure or the task as they believe they do it. Workarounds and interruptions show up under observation. The interview explains what the observation has shown. Document analysis provides the prescribed procedure to compare with the real work.

To design training, Piso (1981) puts these questions to the sub-goals:

• What information is used to decide to act?
• When and under what conditions does the person decide to act?
• What are the consequences of the action?
• What feedback does the person receive?
• How often is the task carried out?
• Who carries it out?
• What problems can arise?

The analyst then examines the order of the sub-goals, their hierarchy, their frequency and their cognitive demand. When the task consists mainly of judging, diagnosing or deciding, Rosala points to a neighbouring branch: cognitive task analysis studies the mental processes and the decisions.

The diagram and the table

HTA delivers two representations of the same content. The diagram places the overall goal at the top with the number 0. Its sub-goals carry the numbers 1, 2 and 3. At the next level the sub-goals of 1 carry the numbers 1.1 and 1.2. Each plan sits in a box attached to its goal.

The table carries the reasons that the diagram does not show. In the format improved by Shepherd it has four columns: the number of the superordinate goal, the task component (an operation or a plan), the reason for stopping and notes on performance, training and further analysis. The original table recorded for each goal the input and feedback difficulties and the action difficulties.

Task analysis, functional decomposition and use cases

HTA sits next to functional decomposition and to use cases and scenarios.

The pitfalls

Describing actions. "Click Confirm" or "open the case file" turns the hierarchy into a flowchart that freezes the current way of working. Each sub-goal names a result to achieve: "check that the delivery matches the order" rather than "open the Orders screen".

Trusting self-report. An analysis built from interviews alone describes the prescribed work. The analyst observes at the workplace and cross-checks the sources.

Going down to the same level everywhere. A hierarchy of even depth signals an ignored stopping rule. A branch where P × C is low stops at the first level. The time saved goes to the branches where P × C is high.

Forgetting the plans. A tree without plans gives sub-goals without order or conditions. A plan without an exit condition does not say when the level is finished.

Analysing alone. HTA has no standard rules. Two analysts produce two different hierarchies for the same task (Usability Body of Knowledge). The subject-matter experts review the hierarchy. A second analyst checks it when the stakes justify it.

Letting the diagram and the table drift apart. A sub-goal renamed in one keeps its old name in the other. The analyst updates both in the same session.

Limitations

HTA describes existing tasks. It does not predict how a person will carry out a new task (Usability Body of Knowledge). Miller and Vicente (2001, cited by Stanton) note that it describes neither physical objects nor the propagation of effects. Nor does it cover causal understanding or social and organisational knowledge. Stanton disputes part of this criticism.

According to Stanton, the basic approach can be learnt in a few hours. Skilled use takes a few months of practice under the guidance of an expert.

AI considerations

A speech recognition tool transcribes the interviews and the recorded observation sessions. A language model reads these transcripts, the manuals and the procedures. It proposes a first hierarchy of goals and plans. It rewords each sub-goal with an action verb and adds a standard and conditions when the analysis calls for them. It checks the structure: three to ten sub-goals per goal, no goal with a single sub-goal, an exit condition in every plan and the same numbering in the diagram and in the table.

The model does not see the work. It draws its sub-goals from the manuals and from what people said. It thus reproduces the self-report bias that Rosala warns against. Each proposed sub-goal remains a hypothesis that the analyst checks through observation. The stopping rule belongs to the subject-matter experts, because a model does not know what an error costs in the department under study.

The recordings show people at work. Article 328b of the Code of Obligations (CO) limits the data an employer processes about a worker to data that concern their suitability for the job or that are necessary to perform the employment contract. Article 26 of Ordinance 3 to the Employment Act (OLT 3) prohibits systems intended to monitor the behaviour of workers at their workplace. The team informs the people concerned and obtains their consent before recording. It links each observation to a sub-goal rather than to a person. An external model receives only transcripts without names. The team deletes the recordings once the hierarchy is validated.

Examples

The customer service department of an online retailer in the canton of Vaud trains its new staff to handle complaints. The analysis is therefore done for training. Goal 0 carries its standard: five working days. The analyst redescribes sub-goals 2 and 4. The others stop at the first level.

Sub-goal 3 runs only if a document is missing. Only plan 0 carries this condition. Plan 0 combines two models: fixed and contingent. The redescription of 4 shows the sign-off that catches a costing error above CHF 200. The sign-off brings P × C down to an acceptable level.

Visualisations

The hierarchical diagram of complaint handling shows the goals, the plans and the stop marks. The table of the example carries the reasons for stopping and the training notes. The plan models form a table. The P × C grid places sub-goals 1, 2, 4 and 5 by the probability and the cost of failure. A table compares HTA with functional decomposition and use cases.

Cost

Tooling

A whiteboard or sticky notes are enough to build the hierarchy with the subject-matter experts. A word processor in outline mode produces the indented numbered list, which is equivalent to the diagram. A spreadsheet holds the table: one row per component with the decimal numbering in the first column. Diagramming software such as draw.io, Visio or Lucidchart draws the tree for a presentation.

A recorder and a transcription tool support observation and interviews with the consent of the people recorded. For screen work, screen recording shows the real order of the sub-goals.

Sources

• Neville A. Stanton, Hierarchical task analysis: Developments, applications, and extensions, Applied Ergonomics 37(1), 2006, p. 55-79 (postprint, Brunel University London): the origin and uses of HTA, the three principles, the plan types and plan models, the P × C stopping rule, Piso's test and questions, the seven heuristics, the form of sub-goals, Shepherd's table and the criticism by Miller and Vicente. The works of Miller, Galanter and Pribram (1960), Annett and Duncan (1967), Annett, Duncan, Stammers and Gray (1971), Piso (1981), Patrick et al. (1986), Kirwan and Ainsworth (1992), Shepherd (2001), Miller and Vicente (2001), Annett (2004) and Ormerod and Shepherd (2004) are cited after Stanton.
• Maria Rosala, Task Analysis: Support Users in Achieving Their Goals, Nielsen Norman Group, 2020: the definition of task analysis and of a task, data collection and then analysis, the warning against relying on self-report alone or simulation alone, cognitive task analysis.
• Usability Body of Knowledge, Hierarchical Task Analysis, UXPA: the use of HTA to find inefficiencies in existing work; the limitations of the technique.
• Ordinance 3 to the Employment Act (OLT 3), SR 822.113, art. 26: the prohibition of systems intended to monitor the behaviour of workers at their workplace.
• Code of Obligations (CO), SR 220, art. 328b: the restriction of processing a worker's data to their suitability for the job or to the performance of the employment contract.