Hierarchical Task Analysis (HTA) is a method for decomposing complex tasks involving human-product interactions.
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:
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.
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 need1).
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 task2). 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.
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.
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 instructions3), 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.
2cc.2may well be noted by the designers as existing outside the scope of the design of the HUV itself and thus require no further work.
3.3need 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:
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.