The 7 Steps of Hierarchical Task Analysis: Part 1

Hierarchical task analysis breaks your user’s actions towards a goal into a series of tasks. Tasks are further broken down into a series of sub-tasks, and so on, until you decide that you have gone far enough.  For instance, if the goal of your user is to prepare a financial report, sub-tasks might include tasks like "review the accounts" and "estimate revenues." Depending on the expected familiarity of your user with the task list you created, the selected tasks can be further broken down into sub-tasks. The terms task and sub-task refer to the same thing - a description of the user’s actions. The only difference between them is their relative place in the hierarchy of the analysis, just like the relationship between the terms parent and child.

A stopping rule is a guide for when to stop at a particular level of analysis. It reminds you of the how much detail you should include in your task hierarchy to solve a particular design problem.  If you over analyze your task structure, you might be wasting your time and ultimately delaying the completion of your analysis.  If your user’s goal is to operate your machine, then the obvious stopping rule would be stop breaking down tasks once the user has selected the design feature that accomplishes the task under consideration.  Some analysts have defined formal stopping rules for particular types of design problems, which we will discuss this later this blog series.  The way that sub-tasks are assembled to achieve the task goal is described in a plan - a succinct, logical statement of when sub-tasks are carried out. A plan describes the order and conditions under which sub-tasks are to be performed. For instance, if a task involving turning on four buttons in a fixed order, the plan might state: "Do tasks 1, 2, 3, 4 in order where each task describes the operation of a single button."

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

As tasks are recorded, further information, in addition to the actual task statements, such as the risks involved or the tools required can also be collected. These are called the task properties.  There are many ways of portraying the results of the analysis. The most common forms are:

  • An indented list of tasks indicating how the sub-tasks (child tasks or children) are related to their parent tasks;
  • Hierarchical diagrams showing the relationship between tasks;
  • Tables showing the information recorded against each tasks;
  • Lists of information compiled from the analysis for further use in other programs.


This is the sequence of steps normally followed in a Hierarchical Task Analysis:

  1. Decide on what to analyze, and how to analyze it.
  2. Collect any necessary information.
  3. Verify the information collected.
  4. Apply the task analysis notation.
  5. Communicate the results of the analysis.
  6. Use the results of the analysis.
  7. Maintain the task analysis.

Depending on the type of analysis being conducted, information collection can vary from brainstorming about what is known of the tasks to in-depth interviewing of a representative sample of users followed by second interviews to crosscheck information.

Information recording is more than simply writing down the results of the data gathering; it is a structured approach to portraying the information in order to show the relationship between the tasks and the recording of properties against each task. Structuring the information in this way allows the identification of gaps in the analysis. For instance, the analyst may notice that a task was mentioned but not in sufficient detail, requiring a return to the data gathering! stage.

In the later analysis stages, the key attributes of the information are teased out and made available to those people who will use it later in the project. The output can vary from textual lists of tasks to diagrams showing their relationships and tables documenting all of the tasks, their relationships, and the frequencies of important properties.