This technique enables task scenarios to be succinctly represented on a diagram. Both task scenarios that have been documented and all others that are possible are captured.
Task scenarios are fundamental records of the way users will actually carry out tasks involving the system to be designed. They should show the full details of one example task being carried out. If every possible task sequence involving the system could be documented in this way then the procedural specification of interaction would be completely captured. However for systems having more than a very small number of possible variations on their use, full documentation is impractical. Assuming that choice points in an interaction that determine subsequent paths (scenarios) have only two possible outcomes, the number of scenarios increases by a power of 2 at each choice. At 3 choices there are 7 scenarios, at 4 there are 15, at 5 there are 31, and so on. The progression rises even more steeply when the number of possible outcomes at each choice point is increased. Also these are not just explicit choice points (say click a link, etc.) but entry of different values in input fields can affect the flow of control. As more is discovered about the tasks that the systems you are designing will support, the task scenarios already documented may require revisiting and amending.
The technique described here resolves this problem of an unwieldy scenario set by generalising the scenarios to produce a concise representation of all of that have been documented and those that have not. A useful bi-product is that commonalities in the scenarios underlying structure are brought out.
Behind this technique is a very particular notion of a human task as being goal-directed, and where the goal of the task can be satisfied by the achievement of subsidiary goals that shape the activity involved in the task. E.g., the goal of passing information by telephone, has the subsidiary goals of; getting a particular person on the phone; having a conversation with them and then; terminating the call. The goal of getting someone on the phone has the subsidiary goals of; finding their number; dialling the number and; establishing that the person answering is who is wanted; and so on.
A hierarchical task analysis to produce an abstract task model is carried out for each user class. The intention is to represent all tasks carried out by that class of users on one diagram.
2.1 Create the static hierarchical task decomposition
The analysis begins with identifying the main task carried out by the user. E.g. for a simple stock-control system (say for a small shop) where the user is responsible for inputting details of received stock, editing stock details (changes in price, specification, etc.), and fulfilling orders, the main task could be described as ‘Maintain Stock Records’ with as subtasks, ‘Receive Stock’, ‘Edit Stock Details’ and ‘Fulfil Order’. The tasks should be named in ways that are recognisable to the user.
Each of these first-level subtasks is examined to identify the second-level tasks of which they are composed. This breakdown of tasks can be represented conveniently as a nested list, e.g.:
Ellipsis (‘…’) indicates incomplete sections.
2.2 Add the dynamic plans
In our example task, note that of the subtasks of ‘1 Receive Stock’, the task ‘1.3 Create New Stock Record’ would only be carried out if the subtask ‘1.2 Identify Received Item’ revealed that this was indeed new stock of a type not previously carried. So far the nested list has only contained information about the static hierarchical relationship of tasks and subtasks, i.e., that a particular task is composed of particular subtasks. That a task is carried out only under specific circumstances is information about the dynamic aspect of the analysis; the plan that the user will have for carrying out the task. We can add this to the model as a ‘Plan’:
Note that the plan explicitly rules out impossible scenarios such as updating the stock record before identifying the received item.
Explore the full space of possible scenarios. For each task with descendent subtasks you should ask;
- Is a particular sequence of subtasks required?
- Are any subtasks optional and if so, under what conditions?
If you discover possibilities that are not captured in the validated task-scenarios, it will be necessary to check their appropriateness with appropriate stakeholders.
2.3 Use a diagrammatic representation
Building up the analysis as a nested list is convenient initially, particularly if using a word-processor, but as it flows over more than one page, interpreting it becomes difficult. An alternative diagrammatic representation is usually better.
This example fragment was created in Microsoft® Visio® using a Jackson Structured Programming template. Other tools are available.
Whether represented as a nested list or diagram, the task analysis is always a work in progress. It can be deepened indefinitely, but there is no point in taking it further than is useful (and encountering ‘paralysis by analysis’). The point at which the analysis stops, the ‘leaves’ of the (upside down) ‘tree’, should represent simple chunks of activity, typically entering data into the system or receiving data from it. When it has been agreed not to deepen a particular task, this can be indicated by drawing a line beneath it, as 1.2 in the diagram above.
It is possible to modularise the diagram, expanding elements that might be extensive on additional sheets. The diagram is kept clearer and less cramped. The task to be expanded in a separate diagram is indicated by a triangular tab, as 1.3 in the diagram above.
It is important to include significant task elements that are not carried out in the software to be designed, e.g. ‘1.1 Unpack Received Stock’. Their ‘off-line’ status can be indicated by shading.
The basic idea of hierarchical task analysis (HTA) is deceptively simple. To carry it out effectively requires the exercise of judgement and the development of an aesthetic that can distinguish between a better representation and a poorer one. This can only be gained by experience: so practice. What follows are some tips and suggestions to assist you in carrying out an HTA.
- Initially consider three possible types of descendent subtasks at each level:
- Initiation; setting up to start the task
- Process; actually carrying out the work of the task
- Termination; on completion of the task, distribution of the result and tidying up
- For a particular task any of these may be so trivial that they can be ignored. Alternatively more than three subtasks may be identified in the expansion.
- A descriptive name for a subtask should not contain the conditionals ‘and’, ‘or’, ‘if’, etc. Conditions are expressed in the dynamic plan statement.
- Leaf subtasks typically consist of input or output of data, calculation, comparison or other data manipulation.
- Typical tree depth is 5 to 7 levels. If you find your tree is narrow and deep, or shallow and wide, then you may be conflating the static and dynamic aspects by mistakenly producing a flowchart N.B. the sequence of execution of subtasks is not indicated by their order in the diagram but by the associated plan.
These are not hard and fast rules!
2.5 Validate the diagram
Just as task scenarios are only useful if they have been validated by appropriate stakeholders, so with the hierarchical task decomposition diagram. Whilst the analysis and drafting of the diagram may take some skill to carry out, very little training is required to read it. It can be ‘walked through’ with appropriate stakeholders to ensure the task it models is valid.
It is not recommended that the diagram is simply handed over for comment; the viewer may not have seen anything like it before and misunderstand the detail. Instead walk through previously recorded scenarios to confirm that they have been transposed correctly, also explore any additional flexibility that the model contains; sequence and optionality of subtasks, etc.
3 Appropriate use of this method
This method should be applied after a basic set of task scenarios have been developed. It is likely to be useful if the complexity of the system and the number of scenarios required to capture it is relatively high. For an extremely simple task that has largely been captured by a small set of documented task-scenarios, it may not be worth doing.
There are other aspects of tasks that the method described so far does not deal with, particularly chronology;
- tasks may be carried out in parallel
- progression may be suspended pending the availability of resources, completion of associated tasks, etc.
- tasks may have duration constraints imposed on them, e.g. if not completed in a set time they may be abandoned
- changes in priorities my require suspension of one subtask and initiation of another
Also cooperation between users working together on the same task has not been addressed.
If you are working on a system where these aspects are significant, then the basic analytic and documentation techniques described may be adapted to record them (make up a new notation, use colouring, add notes, etc.). Alternatively other task analysis and documentation methods in the literature may be consulted.
The approach presented here has been described as ‘technical’, in contrast to ‘conceptual’ and ‘work process’ approaches [Crystal & Ellington]. The conceptual approach to task analysis is addressed in a following section on the user conceptual model. The more nuanced work process approach may be more appropriate for the analysis of tasks carried out in particularly complex contexts.
4 Resources and Tools
For tools to support this activity look under the Resources menu.
The Interaction Design Association’s take on task analysis: www.interaction-design.org/literature/article/task-analysis-a-ux-designer-s-best-friend