Task Analysis | Real-World .NET Applications

The primary purpose of task analysis is to compare the demands of the system on the operator with the capabilities of the operator, and if necessary, to alter those demands, thereby reducing error and achieving successful performance.

—B. Kirwan and L.K. Ainsworth in A Guide to Task Analysis

There are a number of techniques that fall under the definition of task analysis. They range from structured, standardized questionnaires to unstructured interviews with usability experts. For this book, I use the definition that I believe to be the most common, that task analysis is a structured method of hierarchically analyzing a single task in order to understand the interaction of its components.

This means that it's quite closely associated with contextual inquiry, and in fact, the data for it can be collected during a contextual inquiry process. It differs from that procedure in its degree of focus. While contextual inquiry attempts to understand the entire context that surrounds and informs a task, task analysis focuses on the task itself. What is the exact order of things? What are the tools involved? Where is there flexibility in the process? What kinds of information do people need and use at various parts of the task?

When Task Analysis Is Appropriate

Task analysis is best used when you already know what problem you're trying to solve and you want to know how people are solving it right now. This generally falls in the examination phase of a spiral development process or the requirements-gathering phase of a waterfall process. It requires that you know what the task is and, roughly, who your audience is. Although it can be done when there's already a solution of some sort under consideration, it should ideally be done before effort has been invested in features and technologies since it's likely to induce a lot of revision in the fundamental assumptions of how solutions should be implemented.

So if you've already decided that you're going to be selling supermarket-style groceries online, but you haven't yet built the ordering system, now would be a good time to find out how a grocery shopper picks out groceries. Again, you'll be looking for many of the same things as contextual inquiry: tools, sequences, organizations, interactions. But whereas that process investigates the decision-making process people go through in determining what they're going to eat, how they're going to get it, where they're going to get it, and so forth, task analysis will concentrate solely on the task of buying groceries in a supermarket.

In addition, although it can reveal places for interaction with advertising or promotion, the goal-oriented nature of the analysis makes the process better at uncovering opportunities for improving usability rather than promotion or advertising (Table 8.2). That said, there's still much untapped potential in the technique that can produce interesting results when applied to the domain of the entire user experience rather than just their immediate pragmatic goals.

Table 8.2: A TYPICAL TASK ANALYSIS SCHEDULE
Timing	Activity
t - 2 weeks	Organize and schedule participants.
t	Begin interviews.
t + 1 week	Complete interviews. Review videotapes and take notes.
t + 2 weeks	Begin results analysis.
t + 4 weeks	Complete results analysis. Present to development team. Distribute documentation.

How to Do Task Analysis

The form of task analysis described here is a somewhat relaxed combination of the two methods described as decomposition methods and hierarchical task analysis (HTA) in Kirwan and Ainsworth's A Guide to Task Analysis.

Preparation

The preparation for task analysis is almost identical to that of contextual inquiry. You need to pick a target audience, recruit them, and schedule them. You need to plan for the interview by learning the domain and to develop scenarios about how you feel the task will commence. Finally, you need to be organized in the way that you conduct the interview so that you have enough supplies, the right equipment, and the knowledge to use it.

Gathering the Information

The work published in Kirwan and Ainsworth's book was done before the advent of the Web, and it concentrates on installed software and the issues surrounding it. So although they discuss starting with published information and experts as sources for uncovering the actions that make up a task flow, you won't often find such sources for most Web-related work. Moreover, what's important is not how people are supposed to do their work, but how they actually do it. In Kirwan and Ainsworth's task domain, nuclear power and nuclear chemistry, safety requires that people follow the stated rules much more rigorously than for just about any other field. In modern software environments, direct observation is again the basis for data collection.

The interview format is much the same as contextual inquiry: the interviewer acts as an apprentice to the person performing the task, watching as the participant does the task and explains key elements. The apprentice watches and attempts to understand the nuances of the task, eliciting occasional explanations of motivations and options.

Where it differs from contextual inquiry is in terms of focus. Everything should be geared toward understanding how the participant performs the task at hand.

What do they see as the options at any given point?
What are the tools available?
How do they choose one over the other?
Where do they change their minds?
How variable is the process?
Where do they make mistakes? What are common mistakes?
What causes the mistakes, and how are they corrected?
What are the inputs to the process? The outputs?
What is the frequency and importance of the tasks they perform?
What are the risks of failure?

The kinds of information gathered should be similarly structured and focused as contextual inquiry, but with extra emphasis on sequence information and the exact tools used.

Here's a snippet of the notes from a session observing an interior designer picking out a couch (for an online furniture-buying tool).

"I get out my catalogs. I go to [manufacturer A] first, unless it's for a waiting room, then I go to [manufacturer B]. I have a big shelf of catalogs. Recently, I've been getting on the Internet, but I get better results on the catalogs. Hard to find things. Each Web site is so different, it takes time to find your way through the Web site."

Gets four catalogs: A, B, C, D. Gets the [B] catalog. Looks in index for "couch," flips to couch section.

"I usually find a couple of options and weigh cost, availability, delivery, if there's something similar I've seen. You can't tell color from pictures, and they're often slow about getting fabric swatches. I talk to sales reps on the phone and try to get as complete a picture as I can. Some of the companies we don't do so much business with will come in and also try to sell me other stuff."

Marks several sofas with small notepads, in preparation to call the manufacturer about fabric/color availability.

"I know I can get this one pretty fast since I've gotten a couple before, but I'm not sure if they can offer it in the fabric we want. I'll make a note to ask about it. Sometimes they can make it out of a different fabric even if they don't officially offer it in that, but it depends."

"I total it all up. This is what we need, and this is what it will cost, and this is how long it'll take to get it made, assuming they have the fabric in stock. I'll fill out purchase requisitions, going through the catalog and picking out the options I want. I put together a description for the client. Project explanation, list of things to buy, schedules, and so on. I may not have time to explain it all to the client, so I have to make sure the write-up is clear enough."

"Different vendors offer different warranties. I don't shop for warranties, though, I shop for matches and manufacturing time. Cost is important, too, but once the client has signed off on a budget, that limits your options right there."

Prepares to call vendor.

How to Analyze Results

Task decomposition and hierarchical task analysis are complementary techniques. One describes the inputs, outputs, and triggers for the actions in a task while the other arranges the actions into a coherent flow. The order in which these two techniques are used depends on the primary needs. If you're mostly interested in how the components of a task fit together (for example, if you're looking for where a tool can optimize a task's speed), then start with HTA and flesh out key details with decomposition. If you're interested in making a tool that fits with existing practice, then start with decomposition and put the pieces back together in a hierarchical form.

Break the Task Apart (Task Decomposition)

Task decomposition is the process of breaking the task into its component actions. This is easier said than done. If someone is operating a control panel with a bunch of buttons and dials, then every time he or she presses a button or reads a dial, it's an action. But when that same person is shopping for a new car, the decomposition is more difficult since the steps taken—the choices, the capitulations, the comparisons—aren't nearly as obvious. In such situations, encourage the participant to speak all of his or her thoughts aloud and prompt him or her for explanations of specific actions.

Keep the end goal in mind since this will help you pick out the most relevant aspects of each action. If you have a specific tool or solution in mind, you can emphasize one or the other in your decomposition. Sometimes you can work backward from the solution you have in mind to the problem people are facing to see if one matches the other.

Describe each action. Kirwan and Ainsworth list several dozen categories that have been used to describe various facets of an action. Some common ones include

Purpose. Why is this action here? How does it move the task toward its goal?
Cues. What tells the person that it's time to perform this action?
Objects. What does the action operate on?
Method. What is the action?
Options. What other actions are available at this point? How did this action get chosen?

While you're describing the actions, do some error projection. Ask what would happen if the action weren't done or if there were an error. If there are enough actions with interesting error conditions, you can even make errors a separate category you use to describe each action.

For each action, provide answers in as many of these categories as you can. Often the process of describing an action will create questions and inspire new interpretation, so it can be useful to walk through the decomposition a couple of times to make sure that it's consistent and thorough.

Here is a snippet of the furniture-buying decomposition.

Prepare for decomposition by determining the categories that are likely going to be useful ahead of time and then creating forms that you fill out as you observe. That way, you know what information you have about each action and what else you need. In situations where there are a lot of actions in every task or they come quickly, this can be a pretty daunting method of working. In such situations, it may be better to observe the task closely and decompose it into its components later.

Action Name	Purpose	Cues	Objects	Method	Options
List requirements	Clarify choice categories		Word template: size (h,w,l), color, budget, style notes	Talk to client
Get available catalogs	List available options		Catalogs, requirements list	Compare options in catalogs with requirements
Set order for catalog perusal	Start with best-known/best-chance manufacturers	Knowledge of vendor's options	Catalogs, requirements list	Flip through catalogs, comparing options with requirements	Go to A first, unless it's a waiting room, then B
Mark items in catalog	Get primary candidates		Catalogs, requirements list	Visual inspection and comparison to list
Mark items that need follow-up	Separate items for further investigation	When it's not clear whether all options are available for a specific item	Catalogs, marked items	Visual inspection and comparison to list
Investigate marked items	Complete list of available options based on requirements	List of items for further investigation	Catalogs, list of items needing follow-up	Call reps
Total options	Make final list for client	All follow-up is completed	Completed options template, budget template, requirements list	Fill out budget template with options and costs

Guerilla Task Decomposition

In many situations, it's not practical to do this level of task decomposition because of resource or time constraints. In such situations, you can use a more informal version of this process. Use the basic ideas of task decomposition, but instead of going all the way to the atomic task and filling out all the facets, concentrate on larger ideas and use only the facets that you think are most important. If after several interviews, you feel that you can write down the basic tasks, do so on Post-its, create some preliminary organization, and flow with them. Then, as you interview more people, you can adjust these to fit your new information. This is not as thorough of a process, but it can be a lot faster.

Put It Back Together (Hierarchical Task Analysis)

HTA consists of taking the individual actions that make up a task, putting them in a hierarchy, and creating rules for how to move through the hierarchy. The final product is a flowchart that details the sequence that leads up to every action, the choices that are made, and the consequences of actions.

HTA doesn't have to be done following task decomposition. It's possible to do hierarchical task analysis by just sitting down after having interviewed and observed users doing a task. The procedure is a top-down analysis method, which is essentially a formalization of the process that interaction developer, information architects, and technical writers go through when they stand up at a whiteboard and try to understand how something is done.

Start with a goal. This can be the person's ultimate goal ("Furnish the house"), but abstract end goals often require analysis that's too involved for straightforward task analysis. You may want to start with something more direct ("Get list of available couches") and work down from there.
Determine the subgoals for that goal. Subgoals are all the things that have to happen before the main goal can be met. For example, if your goal is to get a list of available couches, you may need to get a list of couches from the catalogs and a list of couches that are not listed (or unavailable) from furniture company representatives. You should rarely have more than three or four subgoals for every goal. If you do, you may want to create a couple of intermediate goals that will subsume several of the intermediate tasks.
Determine how those actions have to be arranged and create a plan for how they flow together. This includes determining which ones have to follow which others, which are optional, which can be swapped out for each other, and so forth. When goals don't have a natural flow, pick one that seems to work and adjust it later if it turns out to be awkward.
Repeat the decomposition with each goal and subgoal until you are down to individual actions.

The end result is a diagram in the familiar "boxes and arrows" style, where a single goal has been turned into a goal tree, with all the subcomponents of every goal beneath it and linked to it, creating a procedure for accomplishing that goal (Figure 8.2).

click to expand
Figure 8.2: Couch-buying analysis diagram (segment).

When you've formally decomposed a task, the procedure is nearly identical, except rather than making up the list of goals and relationships on the fly, you use the ones that you've extracted from your interviews. The procedure to do this is a bottom-up method similar to the way an affinity diagram is created in contextual inquiry.

Start by ordering and clustering actions into groups that are all associated with the same result. Actions that occur in parallel are optional or are alternatives for each other and should be labeled as such.
Label the clusters with the results. These are the subgoals.
Order and cluster the subgoals in terms of what ends they achieve.
Label these clusters. These are the goals.
Repeat until all the actions have been clustered and all the clusters have been ordered and labeled.
Create a diagram by organizing the subgoal clusters underneath the goal clusters and linking these with arrows that show how goals are related to their subgoals.

This procedure produces diagrams identical to Figure 8.2.

Checking for Diagram Validity

Once you have your diagram, you can check it for validity and completeness using a technique mutated from the function analysis system technique(FAST, also described in Kirwan and Ainsworth).

The boxes in the chain abovea given box in the hierarchy answer the question "Why do I _______________?" where _______________is what's written in the box. So using the example, when asking "Why do I talk to reps about unlisted options?" the diagram answers "Because you need to know what items are available that aren't in the catalog so that you can make a complete list of all available items to make a list of viable options for the client recommendation."
Boxes belowa given box answer the question "How do I _______________?" So asking the question "How do I get items from a catalog?" is answered by "Find the highest-priority catalog that hasn't been examined and pick items from it while noting down which ones require more research."
Items with arrows only go in one direction (generally "how"). If you can answer both of the above questions for every box, your diagram is complete.

When you've completed a task analysis diagram, walk through it with a few people who know the task to make sure that it matches their experience and that the sequences, tasks, and goals are familiar to them from their experience.

Granted, this particular method can be time consuming and may be unable to capture the subtlety of certain tasks, but it forces deep consideration of the task that can reveal the true nature of underlying processes and can disentangle complex interactions. It's much easier to create a product that works the way that people do when you've understood how they behave. Task analysis provides a specific framework for matching people's existing behavior and satisfying their immediate needs. Moreover, it can demonstrate weaknesses and redundancies in the product since it had been described before the analysis was done: there may be tasks people are trying to accomplish that the product was not originally envisioned to assist in, or there may be inefficiencies in the way that people currently perform their tasks that the product can streamline.

The task analysis diagram, if accurate, allows developers to have a consistent road map and a thorough checklist of everything that the product needs to do (the list of goals) and the order in which it needs to be done (the task flow).