Note to the reader:
This part of the field guide comes from our 2019 version of the UX Research Field Guide. Updated content for this chapter is coming soon!
Want to know when it's released?
Subscribe to our newsletter!
If you were not a ballerina, and you had to guess at how a ballerina might put on a brand new pair of toe shoes, what would you guess? Perhaps you’d imagine that she gets into her tights, slips on her shoes, ties those pretty ribbons around her ankles, and gets to it. You wouldn’t know, unless you asked, that a ballerina will first decide, then label, which goes on the left foot and which on the right. (They don’t come marked.) A ballerina will measure and indicate on the shoes where their own arch will land, and then go through a process of breaking the shoe in that area. They rip off tags and laces. They sometimes pull out insoles and add their own. A ballerina will sometimes sew an extra elastic band onto the front, or add their own ribbon. They might glue a piece of leather to the tip for traction. They stuff the toe with protective cushioning. And on it goes, until they’re ready to be used.
Task analysis is the research method whereby the steps in a process are revealed to someone who’s not in the know. The challenge can sometimes be that product-builders believe they’re in the know when they’re not, and so they think this sort of research isn’t necessary. In reality, how we think people do things is often not how they actually do them at all.
Task analysis is an effective way to find out what people who you hope will use your product are trying to achieve, how they go about achieving it, and how effective they are.
Some of the questions you can answer with task analysis include:
... and more.
"The task" can be any series of goal-directed behaviors involving your product, from the simple to the complex. Most tasks can be broken up into sub-tasks. Determining what counts as a task, and which tasks you want to analyze, will be your first order of business.
Short answer: before you create your user flow.
If users end up not using some feature of your product the way you anticipated or hoped, or if they can’t finish a process or achieve a certain goal, there’s a chance you missed something in task analysis.
Task analysis should be done near the beginning of the design or redesign process. It makes sense to understand the problem (which happens in the discovery phase) before creating the tasks to solve it. So, task analysis is a great approach to use in the early in the prototyping or research validation stage.
Once you find out a user’s most likely path from point A to B, you can base your design on their expectations rather than your own.
The data you’ll use to conduct task analysis can come from user interviews, observational studies, or some other method. You may be able to use data originally collected for another phase of the product development cycle, or you may have to target your research towards preparing for the task analysis specifically.
If you can answer the following questions, then you have enough information to begin a task analysis:
When it’s time to conceive of, design, or build a segment of user-flow, you might consider applying task analysis to that particular project.
There’s more than one approach, and none are wrong. The simplest to describe may be a Hierarchical Task Analysis. Choose that option, and you'll do the following:
If there’s one major goal (the task), break it down into subtasks. Each subtask needs its own goal.
To test it out, let’s make a peanut butter and jelly sandwich!
Goal: satisfy hunger and indulge childhood snack sentimentality
...and so on.
Tip: If your task contains more than eight subtasks, you are probably trying to analyze something that is too broad or complex. Drop down a level; promote your subtasks to tasks in their own right and do multiple analyses.
You might also be tackling a task that is too vague. For example, if the user's goal is "to be a good partner," that could mean almost anything and is thus impossible to study. Be aware that most people are really bad at articulating their own goals; they have their goals, and may know intuitively how to pursue them, and will certainly know when the goal is reached, but might not be able to state the goal coherently when asked. You might have to do some in-depth qualitative data analysis in order to extract usable goal statements from what your subjects have told you.
Your next step is to create a diagram of all the actions required for the task and each of its subtasks. Do not exhaust yourself by taking "all" too literally—use your judgment and the guidance of your data to determine which steps are pertinent. Your diagram should show how the tasks relate to each other and in what order (if it matters) they need to be done.
For example, with that peanut butter sandwich, subtask 1, "ingredient assembly," must go before subtask 2, "light toasting," otherwise you won't have any bread to toast. Within subtask 1, it doesn't matter whether you find the bread or the peanut butter first, but in subtask 2, the bread must go in the toaster before you turn the toaster on.
You can draw your diagram any way you like, provided it works for you and your team. There is no established standard. Sticky notes, perhaps stuck to a white board and connected by drawn lines, have the advantage of being easy to shuffle around as you develop your ideas.
Diagrams all by themselves don't tell the whole story and won't be useful to anyone who isn't already familiar with the task you are analyzing. So, as a companion to the diagram, write out the whole story in narrative form. Then each version of your output will complement the other.
Now, go share your diagram and your story with someone (or several someones) who aren't on your team but are familiar with the task you are analyzing. Get feedback on whether your description of the task and all its subtasks matches their understanding, and also on whether your description is clear and consistent. For example, are all your subtasks described to the same level of detail, or was one left vague? This is where you find out so you can fix it.
The other main type of task analysis is cognitive task analysis, which is like hierarchical, except in addition to looking at how the different steps relate to each other, you will also be examining how the user makes decisions at each step, how much cognitive challenge is involved in each step, and how the process might differ depending on the experience and knowledge level of the user.
You could also do a parallel analysis, meaning the same task is analyzed multiple times (by either method, or by both methods) to reflect the perspectives of different user groups, which you represent in your analysis by different personas. Perhaps one persona is a type 2 diabetic who uses sugar free jelly, and the other persona has a serious texture aversion to soggy bread, but likes honey. Sandwich making could look very different for each persona, and your product has to work for both of them. Another reason to do parallel analyses is to get the input of a second team. Each of you can do your own analysis and then compare.
Either way, you then write a final analysis that is informed by both versions.
Having created your diagram and written your story, what do you do next? How do you use the completed analysis to inform your design?
Basically, you look for places in the steps you have defined where you can help. With the peanut butter sandwich example, you could recommend spreading peanut butter on both slices of bread, to protect it from the jelly in the middle. Then, you can eliminate the entire light toasting subtask, if the purpose is to protect the bread from getting soggy. You’ve solved that problem another way.
Unless your user likes toast.
This is where some of the caveats come into play. The analysis must be from the perspective of your users (as revealed by your data), not from your own perspective.
Looking for places to help might be both easier and more rigorous if you develop a consistent method of annotating your diagram. For example, you might note which steps present problems for the user and which don't in your current solution, or which steps must, by their nature, be done by the user personally and which could be automated. Once your annotation is complete, you can clearly see which design challenges you have to tackle and which you can and should ignore. Cleaning the excess jelly off the knife could be automated, but the user does not regard having to lick the (dull) knife clean as a problem, so your annotation should make clear you don't need to build a de-jelly machine. A functional "light toast" setting on the toaster would be nice, though, if you’re making the toaster (partnership potential if not!)
Task analysis done wrong isn't helpful. Unfortunately, it's one stage of the product development cycle that many people like to do wrong (unintentionally, of course) or skip altogether. With that in mind, watch for the following common tendencies:
Many people skip or undervalue task analysis because they believe they already understand the problem the product has to solve. It's an incredibly common error in all sorts of contexts; assuming you know how another person thinks and feels, what they want and need, and what helps or hinders them, when you haven't bothered to ask. The reality is that feeling confident you know something and actually knowing it are two different things, and if you didn't ask or observe, then you don't know.
For example, online storefronts often have "shopping carts" because someone has assumed that online shopping works the same way a trip to the grocery store does. Actually, online shoppers use shopping carts in other ways than intended—to collect several items to be purchased at once. Instead, most people use shopping carts to assemble wish lists or to facilitate side-by-side comparisons. The typical shopping cart can therefore be a great solution to a problem most people don't have—and a poor solution to the problem they do have.
If you’re doing a product redesign, don't rely on established users for your task assessment. Established users have learned how to make your product work and won't give you much information on how it isn't working. Their muscle memory is not useful to you.
This is the most common pitfall to be found in standard approaches to mapping user workflows. Approach assessment with a neutral mind. “But this is how I would do it!” isn’t useful, even if you’re deeply enmeshed in the topic at hand. If you already have a favorite solution, you'll tend to design your research so as to confirm your opinion. The best thing for your customers and your company might be very different from what you think is the best way.
Focusing on the task means looking at how users try to accomplish a goal, not how users try to use an existing product. That means that sometimes you'll be studying the use of an earlier version of your product, or maybe an analogous product made by someone else, but in other cases you won't. You might instead look at how people use a brick-and-mortar equivalent of your online store, for example. Or if you’re very early on, how they accomplish a goal without anything like your solution.
Task analysis itself is comparatively easy. The difficult part is collecting the necessary data to begin with and avoiding all the downfalls covered under "Caveats." It is worth remembering that the reason the common mistakes are common is that intelligent, well-intentioned people make them, sometimes even after having been warned. Do not underestimate their allure. But, if used properly, task analysis can be the critical factor that will allow you to design a product people will want to keep using.
