The 7 Steps of Hierarchical Task Analysis: Part 5

This is the fifth in our series of blog posts to teach you the basics of Hierarchical Task Analysis.  In our last post of this series, we explained how to verify the information in your analysis. In this post we are going to focus on how to apply task analysis notation to your analysis.


This is the process of moving notes and other recordings of raw information to clear statements about tasks, sub-tasks, task plans, and task properties. This assemblage of organized information is then called the task hierarchy. The specific format of the hierarchy that you use will depend on the aims of your analysis, and what stage of the work you have reached.  The core parts of any representation are:

  • A brief statement of the tasks. Keep it short and simple - sub-tasks are generally listed under their parent tasks and indented to show their hierarchical relationship. Numbering conventions are sometimes used to emphasize the hierarchy (for example: 1, 2, 3 for the top level; 1.1, 1.2, 1.3 for the next level; and 1.1.a, 1.1.b for the next level..)
  • A short statement of how tasks fit together - the task plan.
  • Relevant properties recorded about the task - for instance the duration, the likelihood of success, the tool used or the operator, dependencies, frequencies. These aspects are described in more detail below. These are starting points for your analysis - many analysts develop their own style of expressing these core elements.


A task statement is a brief description of a single, goal-directed activity. A task might be high in the level of the hierarchy of tasks that you describe (drive the car), in which case it might require a detailed statement and additional sub-tasks to fully describe it. On the other hand, tasks that are lower on the hierarchy (turn the light switch on) might not need any further description. Task statements should be clear, complete, concise, and relevant to the action performed. They typically consist of a verb, an object and may contain qualifiers (e.g. open [verb] the box [object] half way [qualifier]).  The actual statement may follow a pre-defined format defined by your organization, such as limiting choice to a pre-set list of verbs and standard tasks. 

List the tasks in the same order as they are performed, including the sub-tasks (children) under each higher-level task (parent). Check that all of the sub-tasks when carried out fully meet the goal of the parent task and that the sub-tasks do not overlap with one another. For example, if the parent task is change a tire, all of the sub-tasks that are completed should result in the completion of the tire being changed, and the sub-tasks should not include steps related to other activities such as changing the fan belt.  The process of organizing the raw information into tasks and into sub-tasks will reveal how the specific steps clearly fit together in order to attain the goal of the higher level tasks and overall goal. 

In the analysis of complex tasks, the analyst’s challenge is to make concise task statements, simple plans (see below), and concise groups of sub-tasks. By doing this, the analyst highlights the essential parts of the task and makes the whole system easier to understand. For this reason, it is recommended that you create no more than 7 immediate sub-tasks for any task. 


Plans describe how sub-tasks are carried out to accomplish their parent task. The plan specifies the conditions when the sub-tasks are applicable and the sequence that the sub-tasks are performed in. They provide information about the temporal and causal relationships between different task elements. They are produced for all the immediate subtasks of a particular parent task.  The simplest way that tasks may be organized is for all of the subtasks to be undertaken sequentially. However, the plans can also describe relatively complex relationships between tasks.  

There are various types of plans: The following list describes the basic structures that plans can take. Every HTA Plan must adhere to at least one of these structures, and many plans will be a hybrid of two or more of them:

  • Fixed sequences - Complete tasks in a simple linear sequence. Series of elements are undertaken sequentially so that completion of each element acts as the cue to initiate the next one. This represents the simplest way of organizing tasks, and it is so common that specific plans are not always given when a set of tasks are all organized in this way. The sequence of operations is fixed do 1, 2, and then 3.
  • Constrained Linear Sequence - This is a linear sequence of elements in which progression to the next element also depends upon certain additional conditions being met. The most usual constraints upon starting the next element will depend upon the state of the system, and these could include waiting for particular parameters to come within limits, or waiting for a specific system state, such as a valve finishing closing. E.g. Do Step 1, and then when pressure falls to 100 psi, do Step 2. It is also possible to write plans where not all of the sub-tasks are carried out for a particular task, depending on the start condition (if x, do 1, 2, then 4; but if y, do 1, 2 then 3). 
  • Unordered list/ variable sequence - do all steps in any order In an unordered list. The only requirement is that a number of elements have to be undertaken, but the person is free to undertake them in any order that is appropriate at the time. This would be typified by undertaking a short series of prestart-up checks. IE." Do 1, 2, and 3 in any order." An unordered list represents the most flexible way of organizing tasks, but it is always necessary to question whether the task organization is truly unstructured, or whether there is either an inherent, or a preferred structure. For example, although no task order may be specified, imposing a standard order of working may reduce the risk of elements being missed, and thus be preferable if other initiation cues are poor. Equally, if in any order implies that the operator must make a judgement, this should be made more explicit because it entails a decision-making skill.
  • Concurrent operations - do at the same time In this condition the sub-tasks listed can be done at the same time. An example of this type of task with concurrent sub-tasks would be man front desk, carry out filing, and monitor visitors at the same time.
  • Optional completion - do any steps from a given list. Any of the sub-tasks can be carried out in order to accomplish the goals of the main task. For example, to close the door either push the door, press the door-closed, or lean against the door. In this type of branching, a person is free to adopt different approaches, with no guidance to indicate which might be most appropriate for a particular situation. When such situations are identified, it will be important to ascertain whether the different approaches are genuinely similar in terms of their functional result. If any of the options are preferable in some circumstances, the tasks should be re-organized, by providing guidance or training, in order to alter this to a normal conditional branch.
  • Cycles - all of the sub-tasks in the plan are to be repeated until a given condition is attained. For example, check quality of product then add product to the box until the box is full. The best way to represent cycles is to create a plan based on the finished condition. “Until the box is full do check product then add product to box." Forms of looping include Condition Attainment Looping and Continual Looping. In Condition Attainment Looping, a person continues to undertake a limited sequence of elements until particular conditions are met ( Do 1, then 2 and repeat until pressure stabilizes). This includes many monitoring and control tasks, which are undertaken intermittently in parallel with other tasks. In their simplest form, this may involve only a single task, which is repeated at appropriate times as determined by other task demands, etc. However, in other situations the background task may involve a sequence of elements (Do 1, then 2, and repeat at least once every 5 minutes when time is available). In such tasks, it is often important to describe whether the elements must be done contiguously as a single block, or whether they can be interleaved with other unrelated elements when opportunity permits.
  • Choices - In these tasks, actions are carried out according to a plan until a decision point is reached within the plan. For instance, to sell a product: greet the customer, decide on the type of customer, then (if the customer is browsing) provide support. Alternatively, if the customer is intent on buying, make a sales pitch.
  • Contingent sequences - At each branch point, a person must select which element to undertake next, based upon the conditions that pertain, or the success (or otherwise) of a previous action. IE. "Do Step 1 if there are no alarms, otherwise do Step 2." Here, tasks are carried out once the system has reached a particular state, tasks are not carried out just because the previous task has been completed. For instance, in shaping a piece of wood, a carpenter must monitor the planning action until the required level is reached then sand the wood. Again, branching conditions are used to create this type of plan.
  • Branches within plans - It may seem difficult at times to write short task statements and even harder to write clear, concise plans. This is an indication that there may be a need to change the analysis by creating new tasks or re-arranging the current task hierarchy. This involves a re-organization of your conception of the task, and it may feel painful, but a simpler analysis will usually be more useful in the end. The process of unraveling a complex analysis may identify confusions and problems in the current way of carrying out a task.


Producing the basic analysis of an overall activity by determining the list of tasks, sub-tasks, and plans may provide enough information for the next step in the project. However, some projects may require an in-depth analysis and more detailed information. The collection of task properties, pre-defined categories of information about each task, enables this more in-depth analysis.  Here are some examples of task properties:

  • Cues that trigger the task
  • Standards to which the task is to be performed (e.g. accuracy, speed...)
  • Task output
  • Tools and equipment used to carry out the task
  • Job aids used or required for better performance
  • Manual(s) used / Screen(s) used
  • Supervisory actions to ensure good performance
  • Physical demands while carrying out the task
  • Relevant environmental conditions
  • Location where the task is carried out
  • Context emergency and normal operations
  • Description and amount of training required
  • Task complexity
  • Skill, knowledge, and experience required
  • Hazards and potential safety consequences of incorrect performance
  • Potential business costs of incorrect performance
  • Probability of errors
  • Task difficulty and frequency
  • Operator / Role / Source where the property information came from

Properties can also be used to create database references. For instance, you may want to link a task to a particular item in a database by recording key (e.g., a unique number) as a task property of that database record. 


One of the most time-consuming aspects of task analysis is keeping track of the task number - the number used to identify the particular task or sub-task and locate it within the hierarchy. Some analysts use conventions about the numbering style to reflect the level of the task in the hierarchy. For instance, they use single digits for the top most levels, one decimal place for the next level down, and characters for the lower levels.


Let's look at our example, fully annotated.  First let's look at the task hierarchy:

Screen Shot 2018-07-18 at 3.01.00 PM.png

and now let's look at the properties:

Screen Shot 2018-07-18 at 3.01.33 PM.png


You're almost done now! I hope you are beginning to see how even a simple task analysis can bring important information to the surface.  Without a systematic analysis, we might not have learned that our customers have trouble finding the display button.  If we hadn't thought about how frequently the task was performed, we might not have thought about emailing our customer when daylight savings time changes are needed with a link to our training video. 

Our next blog post will move on to the next step in Hierarchical Task Analysis: communicating the results of your analysis.