HTA is a simple method of recursively decomposing complex tasks into sequences of subtasks and recording the results for future use and communication to others. It has been used successfullly for 30+ years and there is a wealth of information about it available on the Web.

For our purposes, HTA is an excellent tool to describe and document the operation of a product; i.e., the tasks and subtasks that users have to execute to achieve a goal through the use of a product.

Many errors relating to product use can be traced back to ineffective or poorly designed interfaces. And many of those interfaces were poorly designed because their designers did not think through properly the tasks a user would have to perform and the order in which they would have to perform them. Sometimes, product interface errors arise because different designers working together did not have a common mental model of how the product ought to be used.

HTA, when done well, addresses all these problems.

While HTA can be applied in principle to any task, it is most useful in organizing complex tasks that do not have obvious or trivial solutions. This is generally the case in design. This means, though, that you must pay attention to the level of detail of your HTA. HTA is most useful for large, or long, or complex “higher level” tasks. You know you've gone into too much detail with HTA if:

• you're breaking a task down into truly obvious or trivial subtasks, or
• you've exceeded the scope of your project or design brief, or
• the subtasks include decision-based branches (analogous to “if-conditions” in flowcharts).

The real benefit of HTA is that, once completed, it lets you focus your attention on smaller, relatively manageable tasks, and yet keep an eye on the “big picture” of the overall product you are designing.

The principal deliverable of HTA is a description of the different tasks a user may perform with a product, showing how the tasks relate to one another.

• This includes two kinds of information:
  • hierarchical information indicating which tasks are subtasks of which other tasks, and
  • sequential information indicating the general order in which tasks are supposed to be performed.

HTA descriptions are typically in the form of a tree-like diagram. However, for our purposes here, a nested list of properly identified tasks is all we need¹⁾.

First, we'll look at what a HTA listing looks like, and then at how we perform the analysis the listing for which is the end result.

A HTA is represented with a nested list of tasks, where each successive level of the hierarchy represents a finer level of detail.

We make one important assumption for HTAs in design: that every task has three general subtasks: an initialization or set-up task, a use task, and a finalization or take-down task²⁾. Each of these three tasks may have many subtasks of their own.

It is also the case that sometimes there will be alternative subtasks that can be carried out at some specific point in a larger task. This means we have to be able to distinguish between sequences of tasks that must all be executed in order, and sets of alternative tasks from which a user executes only one.

Finally, since individual tasks in a HTA will be referred to in subsequent design work, it is necessary to provide an easy shorthand to refer to them. We adopt a simple numbering scheme for this.

Here is a sample, incomplete HTA listing.

Refer to Figure 1, which shows a partial HTA listing for an elevator system. It is only a partial HTA so that we can focus on the listing's structure rather than its content.

• Ellipses show where parts of the HTA have been omitted for brevity.
• At the top of the HTA is the name of the system we are analyzing.
• Each level of indentation represents a more detailed level of the hierarchy.
• The top level of tasks shows the 3 basic tasks, from a engineering perspective: installing the elevator, using it, and finally decommissioning it at the end of its life (whether that is due to building demolition or major renovation is irrelevant at this point).
  • They are top-level tasks, so their numeric IDs are single integers.
    • In subsequent text we can simply refer to “Task 2” rather than “System Operation”.
  • These tasks are executed in series, so they are listed and numbered in sequential order.
• Each top level task is then broken down into subtasks. In figure 1, we only have some subtasks shown.
• The third level of the hierarchy shows the subtasks of Task 2, indented one more level.
  • Notice again the three main subtasks are indicated: starting up the elevator, use and maintenance, and shutting it down.
    • Starting up and shutting down the system might be necessary for some kinds of maintenance, or may occur before and after a major power shutdown or emergency situation.
  • The numbering scheme (2.1, 2.2,…) captures both the sequence of tasks and their location in the overall hierarchy.
• The fourth level of this example shows how we represent alternative sequences of subtasks for a given task.
  • We vary the numbering scheme, using lower-case letters to denote each alternative sequence (e.g., 2.2a, 2.2b, etc.).
• The fifth level of the hierarchy shows the typical, so-called “mixed use” sequence for the elevator.
  • In this case, the three main subtasks are calling the elevator (initialization), riding it (use), and exiting it (finalization).

At the fifth level, the task breakdown has gotten sufficiently detailed that we probably should switch from a HTA to a usage scenario. We say “probably” because every design situation is different, and different teams may approach a given situation in different ways.

HTAs are best performed, at least initially, when grounded in a specific context. For this course, this means already having a reference design to analyze. You might later change the HTA to reflect corrections to problems you've identified in the reference design.

For most teams, the best way to build a HTA is to just pick a task - any task - that relates to the design or design goal, and then build up from there. For each subsequent task, decide if it's a subtask, a supertask, or some unrelated task that will have to be accommodated later possibly in a different HTA.

For instance, consider the kitchen blender shown in Figure 2.

If this were the reference design, how might the development of a HTA proceed?

There will be an initialization task. Assuming the blender has already been purchased and brought home, the initialization task could likely involve subtasks like “unboxing” it, reading the instructions³⁾, registering the product online for warranty purposes, finding a spot for it on a kitchen counter, etc.

There will be a use/maintenance task. This will include setting up the blender for use, actually using it, and then cleaning it and putting it away. Each of these tasks may well have their own tasks. This will vary from team to team, and will also depend on the scope of your design brief and the complexity of your reference design.

You can also break up major tasks to be refined by individual team members and parallelize the task. For instance, say there are four major tasks to be refined in a team of five people, four team members can each take a some time to decompose one of the major tasks, and the fifth member will be in charge of putting them altogether in one complete HTA, and make sure they're all internally consistent.

Don't worry about working “linearly”; that is, don't think you must proceed sequentially through the decomposition process. You can create the HTA in random bits and then stitch it all together later. Since the human brain tends to think non-linearly anyways, forcing yourself to think only in linear sequences can actually slow you done a lot.

Figure 3 shows a fairly complete HTA listing for a human-powered urban vehicle. Some notes are in order.

• Without knowing the precise design brief for this project, we can still intuit certain features of the design situation from the nature of the HTA.
• There is a distinct focus on usage and maintenance stages of the product's life cycle.
  • This is not a reflection on the amount of effort that would go into these stages in real life.
  • However, this is a good representation of the primacy of use in design; especially so for students not yet well versed in manufacturing, recycling, etc.
• There is apparent repetition of subtasks in the two usage tasks (commuting and running errands).
  • The repetition is not actual, because the designers in this case recognize that the steps in each task will be quite different.
  • For instance, returning home after a long day at the office will involve significantly different steps and context compared to returning home after shopping for groceries.
• Some tasks may not require much more work.
  • For instance, task 2cc.2 may well be noted by the designers as existing outside the scope of the design of the HUV itself and thus require no further work.
    • This would only apply if the scope of the design brief accommodates it. It could, alternatively, require that any product be designed specifically to accommodate professional technicians; in this case, this step would have to be expanded upon.
• The tasks and steps of interest to the designers are only those involving the HUV itself.
  • For instance, task 3.3 need not include subtasks or steps such as finding a new vehicle. It might, however, include subtasks or steps relating to cleaning up where the HUV used to be stored once it has been gotten rid of.

The deliverables for a HTA include:

• a properly formatted HTA listing, and
• optional explanatory notes to be added at the discretion of the design team.
  • These optional notes are typically used to be clear about the specific tasks in given nodes of the HTA diagram.

HTA, as used in this course, does not directly involve user groups or personas. HTA is meant to capture the causal ordering of tasks. For instance, to staple sheets of paper together, the act of stapling makes no sense if you did not first get the sheets organized that need stapling. You can't drive a car without first starting it; you can't exhale without first inhaling; and you can't turn off what isn't already on.

This does not mean, however, that we're ignoring users. HTA sets up a framework of operation that's independent of users, and is therefore fundamentally limited in its usefulness in design. That framework is nonetheless HTA's greatest strength for designers, because it provides them with a valuable tool to help focus their attention on specific tasks that must be done by specific users in later stages of designing.