Most UX projects could use Task Analysis

What is Task Analysis?

On the surface a Task Analysis sounds quite simple: analysing the steps and processes needed to arrive at a particular outcome.

Beyond the surface an effective Task Analysis has so much more depth to it. And the outputs are some of the most useful UX artifacts we can create. When compared to something like personas (and even journey maps), a thoughtful Task Analysis can actually drive design decisions. It’s not something that’s made once, printed on a poster, and then left unreferenced on a wall somewhere.

I’m continuously shocked at how few UX teams include this tool as part of their core process.

When you look at a task from multiple angles you achieve something that’s difficult to grasp with other tools. You start to connect the dots between your users’ needs and the solutions you could design. You do this by analysing the goals that drive tasks, the contexts in which tasks are completed, the attributes of our users that affect tasks, and so much more.

With this article I hope to convince you to try Task Analysis on your next project.

The many faces of task analysis

While you may not sit down with the explicit purpose of doing a Task Analysis, there’s a good chance that you cover some aspect of it in your standard process. There are a lot of UX processes that in some way look at the outcomes that users are seeking and the tasks that they complete along the way. These include:

• Journey Mapping
• User Flows
• GOMS
• Jobs To Be Done
• Outcome Driven Innovation
• Activity Centred Design
• Requirements Gathering
• Hierarchical Task Analysis
• Cognitive Task Analysis

I believe it’s best to group all of these methods under the umbrella of “Task Analysis”. The “Jobs To Be Done” evangelists may protest that JTBD is nothing like Task Analysis but the exact same concepts have been around for a lot longer.

Each method has its pros and cons. In this article I am going to take a bird’s-eye view of the entire field – including the drawbacks. As I discuss in my article on analysing user interviews, there are some practical limitations when working in industry. We don’t want to get caught in analysis paralysis. Instead we want to focus on actually designing a better user experience.

Why task analysis is important

First and foremost a Task Analysis is one of the best methods for making design decisions. There are a myriad of ways that this can happen – here are just a few:

• Check each task against the Information Architecture to make sure that everything is covered (and even better: use these tasks to conduct a Tree Test of your IA)
• Look at the triggers for a task and see if the context from which a task is triggered could change your design
• Look at the desired outcomes a user might have for a task and see if that can be achieved in a different way (e.g. fewer screens or no screens at all)
• Look at the underlying goals that drive those outcomes and see if there are other ways you can help the user achieve those goals

Those last 2 points are often where we can have the most significant impact on the user experience. It’s where products can stand out from the competition. It’s where the Service Design feels “seamless”.

However, it’s also making the most of your time and being effective as a designer. So much UX research is spent speaking to users and creating insights. Yet not all insights lead to concrete design outcomes. A Task Analysis is a tool that makes it easy to trace a design decision to the research that was done to get there.

This is in stark contrast to many outputs from generative research (e.g. building personas) that rarely lead to design decisions. And if you structure your research with the intention of doing a Task Analysis, the quality of the data you capture will be much richer.

What about personas?

Personas may have their place in the UX process, but the time spent developing them could be better spent on a Task Analysis. There are certain aspects of a persona that might be useful for a specific task but that will naturally come out in the process of a Task Analysis anyway.

Here are some examples of where we can take just the relevant parts of a persona and factor them into our analysis:

• Online Shopping: consider someone who knows what they want vs someone who’s looking for ideas. We may craft 2 entire personas for that distinction but it would be better to simply treat them as 2 different objectives: “find a specific thing to buy” vs “find inspiration for something to buy” (or “find something to buy that solves problem X”).
• Student Enrolment: consider the diverse variables that might go into a persona, from whether they are postgraduate students, to their age, to which faculty they are in, to why they are studying that degree. Now consider the task of enrolling into subjects for a semester. In this case we may think of constraints on the task. Example constraints include: whether or not they have electives, maximum units per semester, whether they have previously failed any classes, etc.
• Finding a home loan: consider first home buyers vs someone selling their home and buying something new. Most of the “find a home loan” experience is identical for both types of users. We could simply identify the steps in the process that might be different for first home buyers, rather than have an entire persona describing irrelevant details of 2 individuals.

Think of all the time spent researching, analysing, and crafting personas. At the end of that process you have an overview of different archetypes of people but still no idea what you need to design. Now suppose that research time had gone into understanding the desired outcomes and tasks. You could have looked at each task through the lens of “what is it about a user that would affect how they complete this task”. Then not only would you have a sense of “archetypes” but you would also have concrete points to design around.

What’s involved in Task Analysis?

Let’s be clear: no research and analysis process is perfect. Like everything else Task Analysis can have some drawbacks:
There are a lot of ways of analysing your user’s tasks
There are a lot of aspects of a task that you can analyse
All of this can lead to “analysis paralysis”

Again we need to consider the practical aspects of working in UX. We aren’t looking to develop a theoretical framework around how users complete these tasks. We are looking to make design decisions and we’re looking to do it quickly. If we make mistakes in the early part of the research we can do follow-up research later to fix any incorrect assumptions. But if we spend too long in research and analysis then decisions might get made for us or important work might be delayed.

So for practical purposes I will talk about the minimum things you should put in a Task Analysis and ideas on how to expand your analysis depending on your needs.

Let’s take a look at all of the possible things that we could include for any one task::

• The physical and cognitive steps that users need to go through (i.e. the description)
• Contexts, including: physical, emotional, and cognitive
• The level of knowledge users will have coming into the task (education, training, experience)
• Triggers
• Frequency and duration
• Sequence and ordering of tasks
• Complexity (this may not be obvious from the description)
• Dependencies (on tools, information, or other tasks that need to be finished)
• Desired outcomes and ultimate goals
• Potential choice architecture or expected user behaviour
• Artifacts which are produced as a result of the task
• Expected outcomes (including unhappy paths)

That’s definitely a long list. It should be obvious that looking at every single point for every possible task would be downright impossible.

At a minimum, a Task Analysis needs:

• Sequencing and ordering (consider linear vs non-linear tasks)
• Description of the task

If that is all you capture then it’s usually best to do a hierarchical task analysis. This can be done as a diagram or a spreadsheet. Diagrams are nice because they clearly show relationships and sequencing. However, a spreadsheet is more practical and easier to edit and share. It might help to start sketching a diagram and see if you need any more detail than that.

Beyond the tasks and their sequencing the next most important thing to consider is the desired outcome that drives those tasks. Desired outcomes are useful because we might be able to design for the outcome rather than the tasks that users complete to get there. For example, what the user wants is a job and some of the tasks involve looking for job ads. What if we could match them to an appropriate job opportunity without them having to look through ads?

After outcomes we consider the triggers for the tasks. Triggers affect designs for 3 reasons:

1. If our system directly causes the trigger (e.g. a user is approaching their data limit or a credit card payment failed) then we can factor in notifications and we can work out if there is an alternative to triggering action from the user
2. If the system is aware of the trigger (e.g. we know the user’s location, we analyse the content they add, we have integrations with another system) we can anticipate the user’s needs
3. If the trigger might be common we can adjust our Information Architecture and general wayfinding to account for this, e.g. someone changing their address in the system is triggered by them moving home. Is there something we can do to help the users understand what to do when they move home?

There are a lot of task attributes that we could continue to look at. Each of these attributes can be valuable but so is your time. It’s important to keep the entire list in mind but it’s not always possible to design an optimal experience for every situation. The more times you complete a Task Analysis the better you will get at anticipating what information you will need.

Goal hierarchies

An important aspect of Task Analysis is looking at the underlying goals that drive the tasks we are designing for. But as you’ll see this can pose a challenge. The best way to appreciate the challenge is with an example. This example is incredibly common in the “Jobs To Be Done” methodology and it can illustrate our challenge perfectly:

“User’s don’t want a 1/4 inch drill bit, they want a 1/4 inch hole”

1. The “job” that they need completed is to have a 1/4 inch hole in some object
2. The drill bit that your company sells is simply a tool to get them a 1/4 inch hole
3. But not so fast, they don’t actually want a 1/4 inch hole, they want to hang a painting
4. They want that painting to make their house look nice
5. They want their house to look nice to impress their friends
6. They want to impress their friends to feel a sense of social acceptance
7. They want social acceptance to feel a sense of belonging
8. They want a sense of belonging to feel satisfied with life

Well that certainly escalated quickly. Should a designer who works for a hardware manufacturer tell their employer to start offering customers mindfulness meditation classes? After all, it’s not the drill bit that they want but the feeling of being satisfied with life!

With this example it should be easy to see that we can’t look at goals from too high a level.

Even if we don’t go overboard there are still a myriad of problems:

• What if they want to hang shelves instead of a painting?
• What if the reason they want the painting is because it has sentimental value and reminds them of some past experience?
• What if they don’t want to impress their friends for social acceptance but because they want to convince people they are rich?

These variations add complexity to analysing goals. Additionally we may have multiple goals addressed by one task. Consider the goal “I want to feel confident that my money is safe”. This might involve tasks to do with 2-factor authentication and strong passwords. But those tasks address other goals too. Or you might see these as competing options for achieving the one goal.

Let’s be realistic, as designers we are often tasked with a narrow area of a product or service. if you’re designing a car dashboard you shouldn’t be suggesting that your company look at delivery services so that users don’t even need to use their cars. If you work for a company that sells coffee you aren’t likely to convince them to start selling devices to treat sleep apnea. Your job is narrow and the problems your company solves may be huge.

It can be helpful to look at higher level goals to develop more of an understanding of your users. But it can be impractical to spend too much time on these activities when you aren’t likely to be able to do anything about your discoveries.

System agnostic vs system specific

Next consider whether your Task Analysis should include tasks that are specific to the system you are designing. This may even be tasks specific to the type of system. For example: say you work for an online retailer, should your analysis include tasks related to finding clothes using an online store? Should you focus on tasks specific to the existing store you already have?

In general it’s best to start your analysis system agnostic and add system specific tasks as you. The reason you should be system agnostic is because you may come up with an innovative approach to solving a user problem based on the process the user would follow even if a computer wasn’t there. Essentially it helps to expand your thinking beyond the standard conventions and design patterns of your industry.

Now for the caveats:

• If you want to use your Task Analysis to inform user flows then you need to factor in how the user will navigate your system
• You will need to consider interactions patterns (e.g. search vs browse, tabs vs scroll). These interaction patterns are easier to develop if your analysis includes how people will interact with the system
• It can be incredibly useful to start system agnostic and more detail if you think it’s necessary
• Some tasks only come up in a system specific context (e.g. consider using search or filter in an online store)
• Analysing tasks is a great first step when preparing for user testing, which I discuss further in my article on how to analyse a usability test.

Research methods

Regardless of which research method you use there is one key question that you need to keep in mind: ”What is the user trying to achieve?”

You might start by asking a research participant how they would do something or to recall the last time that they did it. When they explain the steps it’s time to ask that question. This helps you to understand what it is that they actually want to do as well as the tasks involved in getting there.

Assuming you are trying to understand users’ goals then it can be helpful to drill down further and ask why they want that particular outcome. For more experienced researchers this is a good place to use the “trailing off” interview technique: for example, “it sounds like you put everything together into a list so that…”. This technique makes it seem like you are about to assume their answer but then you trail off and let them finish the answer on your behalf.

One important tool is to summarise the participants points about why they are completing a task and repeat it back to them. Then they can confirm or clarify.

Of course a lot of the above advice assumes you are conducting interviews. It can often be better to observe the user in context with observational or ethnographic research. You can also do this at scale with online diary studies and experience sampling.

If you already have designs then you can do your analysis as part of a User Test. Simply ask the participant to explain what they are planning to do and why. Just add interview questions into your test plan to understand why users are going through specific tasks.

It can also be helpful to write a draft Task Analysis based on stakeholder interviews, your industry experience, or even assumptions. This kind of analysis can help you work out where the gaps are in your understanding.

Regardless of what project you are working on research will be crucially important to understand what different types of users will do to achieve their myriad desired outcomes.

Analysing user research to produce a Task Analysis could be its own detailed article. Your best bet is to conduct a thematic analysis of your research notes. This can be done effectively with affinity mapping or even by tagging and filtering. Your analysis will be a lot easier if you make sure that discovering tasks is part of your research objectives. You can read more about the importance of this in my article on research objectives in UX research.

Structure

A quick side note: If you’ve already done research on User Journeys you can embed your task analysis at each stage of the journey. If you have Personas you could even use them to see if any of the tasks vary by persona. This can help you drill down on what aspects of a persona actually affect the User Experience at different stages of a journey.

A good starting point is a Hierarchical Task Analysis diagram. There is no one-size-fits-all solution for HTA diagrams so you can adjust them to suit your needs. You start at the top with some desired outcome and then break it down into a sequence of tasks and sub-tasks. Keep drilling down until you feel you have covered enough detail to be useful for your design.

Often the tasks involved in a particular activity are non-linear. For example, consider the tasks a user completes while driving a car. They make turns, track and adjust their speed, avoid accidents, slow down and stop to avoid obstacles, etc. Each of these tasks are themselves broken down into smaller tasks which might have their own analysis (or not, depending on the level of detail you want to get into).

One downside of a diagram is that it can be difficult to collaborate on. Frankly they can even be difficult to edit if you are working on them alone. Sometimes your best friend is a spreadsheet.

Another common tool is to base your analysis on Norman’s “7 Stages of Action” or Ulwick’s “Job Map”. These standard outlines of tasks are based on extensive research. Note: the steps need not be linear though most tasks usually follow this pattern in some way.

One challenge you will face is to decide how deep you want to go into each task. If we take a look at the “7 Stages of Action” or“Job Map” we could apply that standard template at several levels of hierarchy. For example, suppose you are conducting research into how people purchase homes.

• You could treat the entire process “purchase a home” as the desired outcome and map tasks necessary to achieve it
• You could also treat any one step of that process as its own desired outcome, e.g. “assemble a list of properties to inspect”
• You could also look at the underlying goals at different levels, for example whether they want the home to live in or rent out, then even further on why they want those things.

Task Analysis Templates

HTA Diagrams and Job Maps are great but sometimes a simple spreadsheet with all of your tasks is the easiest way to go. Below are 6 examples of how to structure your Task Analysis, include a link to a Google Sheets document that you can copy and modify for your own use.

Outcomes & Tasks

The most basic template is simply to list the desired outcomes a user may want to achieve and then the tasks necessary to get there. The tasks may be completed in a linear order or they may happen in any order. If you feel the tasks sequencing needs more detail you can add notes to the analysis.

Link to template: simple Task Analysis template

Task Triggers

We can extend our basic template by adding triggers. In this example the triggers are against the desired outcome. But there are circumstances where the individual tasks themselves have triggers that you need to document.

Link to template: Task Analysis with triggers template

Job Stories

In a typical Task Analysis you look at what the user needs to do. For example, with a navigation app the user would need to make turns at the right time to get to where they are going. In a Job Story we flip the script and instead focus on what the user needs. So instead of saying that they need to make a turn we would say that the user needs to know when and where to make a turn.

A Job Story takes the format of: When _, I want to __, so that I can ___. The typical description of a Job Story calls the “I want to” part the “motivation” and the “so that” part an “expected outcome”. To me the “so that” part sounds more like a motivation. Consider this example: “When I am following my navigation, I want to know when and where to turn, so that I don’t miss a turn”. The motivation is the desire not to miss a turn.

Link to template: Job Stories template

Segmenting by type of user

Sometimes you might want to segment your analysis by some attribute of a persona. However, in a lot of cases there is no need to segment your analysis because different types of users will have different desired outcomes.

For example, an online retailer might look at (a) users who know exactly what item(s) they want to buy, (b) users who know the kind of thing(s) they want to buy, or (c) users who have no idea what they want. It’s easy to think of a situation in which one person might be in all 3 modes during a single visit to an online store (think Christmas shopping for their family). In this case the desired outcomes could be: (a) “Find a specific item I know I want”, (b) Work out which item I want to buy from what is available, or (c) Find inspiration for what to buy.

Other times it might make more sense to just do different analyses for each type of user (e.g. buyers or sellers in an online marketplace).

When should you add user segment? When there is a big overlap between users but some tasks are highly specific.

Consider designing a project management app: All users should be able to see their tasks for the day but only some users may be able to create a project or add new tasks.

Link to template: Task Analysis with user segmentation template

GATOR method

Many years ago I developed the GATOR method using terminology from Activity Centred Design. This method blends the system agnostic and system specific analysis. You start with general goals and you have a set of activities that users are involved in to achieve those goals. Each activity is based on a set of tasks. Each task then has one or more “operations” which the user completes on your system. Each operation has some “result”.

GATOR: Goal | Activity | Task | Operation | Result

This can be useful when you want to map out your design in detail before you get started. With GATOR you plan the operations that your system needs. It also helps you to see how far removed each operation is from the users’ actual end goals.

Link to template: Task Analysis GATOR Method template

Task-Outcome Canvas

The final template is what I call the Task-Outcome Canvas. This is useful for when you want to bring out the detail for some particular outcome. This could be useful if there are a lot of things to consider when designing for some tasks.

Link to template: Task-Outcome Canvas Template

Making design decisions

I’ve already mentioned how important it is that UX research leads to tangible design decisions. We never want to conduct research just to produce a report that sits in a shared drive that no one ever reads. Ultimately you want your work to help improve the user experience.

Here are a few key ways you can use your Task Analysis to help you and your team make design decisions.

• Use your tasks as inputs into a Card Sort
• Design your Information Architecture around the goals and outcomes of the user
• Use your tasks as the basis of a Tree Test
• Evaluate designs and prototypes against how well it helps users achieve their desired outcomes
• Use your tasks as the basis for a test plan for user testing
• Create a feature roadmap based on which features address your users outcomes and goals, then prioritise your roadmap based on the tasks you want to support rather than the features you want to add
• Try to eliminate screens from your UI by finding some other way of addressing your users’ outcomes rather than making them complete the required tasks
• Use your users’ higher level goals to brainstorm opportunities for innovation

A final piece of advice: I use the term “Task Analysis” because it’s the original terminology for this type of UX analysis. Yet it’s not the most exciting of term and sounds fairly academic. Meanwhile “Jobs To Be Done” is a growing buzzword in the UX industry. You might find more people respond better if you frame your analysis in terms of JTBD.