Hierarchical Task Analysis

Modeling The Workflow

As part of getting to know the user, one of the things that is important to understand is their tasks. This is because as designers, sometimes we need to create software to support what they are doing (e.g., in the case of assistive technology) or to make things more efficient (e.g., in the case of productivity software). We do this by analyzing and modeling the details of their tasks via task analysis. Task analysis is a method that lets us analyze a person's work, to explicitly identify what steps they carry out, what they work on, and what they must know in carrying out these steps. Our focus is on the user's actions.

For example, in order to clean the floors of a house, a person has to get the vacuum cleaner out, fix the appropriate attachments, clean one room at a time, empty out the dust bag if it gets full and reinstall it, put the vacuum away when done.

There are many approaches to conducting a task analysis. The one we are going to focus on is a task decomposition method called hierarchical task analysis (HTA). The important aspect is to decompose an overall task into smaller subtasks. The aims are to describe the actions that people do, organize them as subtasks (so into a hierarchy), and order them as needed. The analysis focuses on user actions, so it is not about the system or what the user is thinking about.

Text Or Diagram

The outcome of a HTA can be either a text description or a graphical diagram. The way to generate the hierarchy is to create a list of subtasks, group thrm into higher level tasks, and decompose lowest level tasks further. Due to its hierarchical nature, you might wonder when the decomposition needs to stop, or whether the current task you have at the lowest level is simple enough. This is somewhat subjective. Some heuristics can be used. First, you can see if all the relevant tasks have been decomposed. You can also check whether the tasks at the bottom level are all described with the same granularity. You may want to see if certain tasks are decomposed and certain ones not, and then try to balance them out to a similar number of subtasks. You might also want to see if you can make the description more generally applicable, so that the description is applicable to other users as well. Lastly, if you think that someone else reading the tasks at the bottom level can misinterpret what it means or can carry it out in multiple ways, that is likely to mean you should decompose the task further. Remember that HTA is not an exact science. Our goal is to model the user task so to better understand the details of what they do.

Cleaning Example

An example of a textual HTA using the previous cleaning example is shown below. You will note there are two parts of the example. First is a list of tasks and subtasks. The second part is a plan that explains the order of the tasks involved and possible conditions that might trigger a task (e.g., task 4).

A list of tasks related to cleaning the house, written and decomposed hierarchically. Two plans are listed to explain the relationships of these tasks, with respect to the order of task execution and if any task needs to be executed based on certain conditions.	A list of actions, observed chronologically. Note that the tasks under 3 are not necessarily in the same order that are decomposed in the analysis on the left. Also note that task 4 happened as needed, so it happened in between 3.3 and 3.2.

Example: Making Tea For Your Guests

Next, I want to show you a more complicated example. This example involves a host making tea for guests. In order to make tea, generally speaking, we need to boil water, clean out the pot if needed, put tea leaves in it, steep the leaves, and pour the tea. In our HTA diagram below, these are defined as the high level tasks (1-5). However, we can decompose these further as illustrated. Task 1 consists of 5 further subtasks done in order. Note that 1.5 has a condition that triggers it. Task 2 does not have any subtasks, and Task 3 has a sequence of three ordered subtasks. When a task is decomposed, an accompanying plan is present to explain the relationship of those tasks.

To explain the diagram further, Task 4 is a waiting task for steeping the tea and there are no subtasks. Task 5 is broken down into further subtasks. It is generalized so that Tasks 5.1 and 5.2 is repeated until every guest cup is filled. Although this plan indicates that 5.1 is done before 5.2, in general, that order need not be enforced because the tea could be poured before the milk. (That's just my opinion, but many tea snobs will disagree.) When all the cups are filled, the host asks each guest their sugar preference and adds sugar if wanted.

HTA Syntax Supported

As illustrated with the tea example, HTA supports different types of plans. Here is a summary of what you saw:

Relation to Interface Design

You can imagine that HTA is useful if you had to teach a robot how to do a task for you. But most of us aren't going to build robots. So let's go back to software. How might HTA help in software design? One obvious answer is that we often need to build software to replicate a human process (e.g., a series of calculations) so that it can be done faster. So if we provide the tasks in the wrong order, then the software will clearly be designed to produce incorrect output.

Try Out This Example

Now, consider another example where you have an app to create party/event invitations. It's a simple interface where on one page, it lists all the events you've created in the past. You can view or edit any one as desired. But to create a new event, you click the button at the bottom, and then a new page would show a blank form asking you for the details of that new event. Once you enter the details, you can submit it, and it shows up on the first page I just described. Below are two simple mockups corresponding to these pages.

Example (cont.)

Now, suppose we wanted to extend the functionality of this app by letting the user create multiple events because sometimes we want to create another event that is a repeated event, or an event that is similar to an existing one only to vary by location or something minor. What should we change in the interface to accommodate this new feature?

Here are two mockups to consider as possible alternatives. Option 1 on the left below lets you either create a new event (as before) by re-typing everything, or duplicate and modify a similar existing event. Option 2 on the right below also lets you either create a new event (as before) by re-typing everything, or choose to create some number of new events in advance and specify the details for all of them at once. This latter option would then create, say 4, identical events simultaneously. If minor details vary, then the user would have to modify each one of these newly created events individually. Give these two options some consideration. Which one would you say works better? Why?

My Interpretation

Personally, I found Option 1 simpler and more intuitive than Option 2. Ignoring the effort I would have to put in to create and modify the events, let's just look at how the tasks would be carried out using a task analysis. If I were planning an event, I generally would only plan one at a time. The only time I would plan multiple events at a time is if that event is recurring, like a weekly meeting. In that case, Option 2 sucks because I would have to create n identical weekly meetings but then go into each event individually to change the date. It's almost like the interface options at this point would force me to choose Option 1 for this scenario, because I would rather not do that much work upfront. And when it's not a recurring event, I just don't really plan ahead a lot to want n identical events in advance. My natural workflow is that I would have an upcoming event, invite people to it, then send it off. Therefore, Option 1 is more natural for the order of tasks explicated in this task analysis.