As UX professionals, we have a great many analytical and descriptive tools available to us. Hierarchical task analysis (HTA) is an underused approach in user experience, concerned with the logic or practice of the task. It involves an iterative process of identifying tasks, categorizing them, breaking them down into subtasks, and checking the accuracy of the decomposition. Hierarchical task analysis has been in use for a long time – since the 1960s or even earlier.
Information about tasks is collected from a variety of sources including conversations with users, observation of users working, job descriptions, and operating manuals. The aim of HTA is to describe the task in terms of a hierarchy of operations and plans. The goal is the desired state of the system, tasks describe the manner in which a goal may be achieved and operations are the lowest level units of behavior. Plans are also included in the representation. These specify the conditions under which each subtask needs to be carried out.
One of the standard ways of presenting an HTA is as a tree structure:
Image from the University of Cape Town, Computer Science Department
There may be some other notations you are familiar with where the order of appearance of boxes in the tree indicates ordering (probably left to right). This is not the case for HTA: the only thing that matters is the hierarchy. Some of the subtasks can then be decomposed into further subtasks (for example, formatting text, correcting text) and are numbered according to the order in which they are performed. These numbers constitute a plan for doing the task, which may also be described separately. As well as presenting the hierarchy, it is necessary to describe plans that define the possible ordering of activities. In this case, a suitable plan would be: Plan 0: Do 1, then 2, and 3 in either order, then 4.
Although tree structures are visually appealing – well, more appealing than the alternatives, anyway – they can be tedious to draw without a suitable tool. Therefore an alternative text-based notation that relies on indentation is often used. We will use this textual notation to expand the task description for the letter-writing task.
0: Write a letter and prepare for posting
1: Prepare for writing
1.1: Get paper
1.2: Get an envelope
1.3: Get a pen
1.4: Get address book (not explicitly stated, but clearly necessary)
2: Write the letter
2.1: Write own address
2.2: Write addressee's address
2.3: Write the date and "Dear..."
2.4: Write body text of the letter
2.5: Sign off
3: Prepare an envelope
3.1: Write name on the envelope
3.2: Write the address on the envelope
4: Put the letter in an envelope
4.1: Fold the letter
4.2: Place letter into an envelope
4.3: Seal envelope
Conclusion
As with all analytic and requirements gathering techniques, undertaking a task analysis is much more difficult and time-consuming than we can illustrate here. If you wish to find out more you can refer to the textbook Diaper: Task Analysis for Human-Computer Interaction, 1989. Focusing your attention on user tasks, and how tasks break down into sub-tasks, helps you to design systems that more accurately reflect what the users want to do. Providing them a better user experience.
Photo by Marvin Meyer on Unsplash
Comments