In a blog post from last year, I shared my understanding of task prompting and what it aims to achieve. I explained how most tasks can be broken into smaller sub-tasks, or steps.
This week, I have been exploring a method called Hierarchical Task Analysis (HTA), which is a technique used to systematically deconstruct a task into its individual steps.
In this blog post I will show you an example of applying HTA, mentioning key aspects of the process, and clarify why it will be useful for my project.
The goal of HTA is to produce a task hierarchy of steps that must be completed in order to complete some high-level task. Take a look at the task hierarchy I made by applying HTA to the task of "make a mug of instant coffee" in Figure 1 below.
The combination of decomposing the task into individual steps and having plans of how to carry out those steps is key to HTA. Importantly, the plans describe when and under what conditions each step should be carried out, which is why each step is uniquely numbered. Sometimes steps can be missed out, like step 4. above. Sometimes steps must be repeated, though there is not an example of this in my task hierarchy.
Knowing when to stop is also an important part of HTA, and the stopping condition depends on the application. For example, I don't specify in step 3. to "pick up kettle", "pour water into mug", "put kettle back on stand" because I considered "pour water into mug" simple enough to stop. A line underneath a step shows that it is not broken down further.
HTA usually requires consulting various different sources and checking the results with experts to identify missing steps. However, this is in cases when the task is something like "deal with a chemical incident". I can carry out a first iteration for the simple tasks I am considering, and then consult others to check the output of my analysis.
That was a very brief overview of the key parts of HTA, and usually a more technical approach would be taken for more complicated tasks. If you are interested, check out this article for a good overview of its history and for further reading. I used the general framework in that article to come up with the task hierarchy above.
Carrying out HTA can help identify missing steps. For example, in my example above I have implicitly assumed that all the objects needed to make the coffee are readily available, like the mug, coffee, and teaspoon. Perhaps a more detailed analysis would have a "get items" step, with further steps to "find a mug", "get a teaspoon", "get coffee", and so on.
One thing I like about HTA is that it provides a quick illustration of how complicated (or simple) a task is. For me, it will be a useful tool for identifying the actions that need to represented in AR, like I mention in the summary of my research for this year. It will be easy to find the most common actions when I have a set of diagrams like the one above: I can simply look at the steps with lines underneath them.
There are also some extensions to HTA, like predicting errors in completing steps. I will explore these later in the project to see how this affects the design of what is seen in AR.