Task Analysis
Task analysis breaks a user's goal into its component steps, decision points, and dependencies — revealing the full scope of what needs to be supported before any design work begins.
01 — TL;DR
Two sentences.
Task analysis is a structured research and design method for understanding the sequence of actions, decisions, knowledge requirements, and dependencies that constitute a user's goal — producing a hierarchical or sequential map of the task that reveals what the interface must support before any design decisions are made about how to support it. It exists because complex user goals are not single actions — they are composed of sub-tasks, conditional branches, knowledge dependencies, and handoffs between tools, people, and systems that are invisible until they are explicitly mapped.
The method has roots in human factors engineering and cognitive task analysis from the 1970s and was formalised for software design by researchers including John Annett and Dianne Ainsworth through Hierarchical Task Analysis (HTA). For product designers, the most useful insight task analysis provides is the scope problem: teams consistently underestimate the complexity of the tasks they are designing for because they experience those tasks from the outside — as a goal to be achieved — rather than from the inside — as a sequence of specific steps, each with its own knowledge requirements, error modes, and dependencies on prior steps.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when the task is a single action with no meaningful decision points or dependencies. Skip it when the team already has complete, validated knowledge of the task from prior research. Skip it when the research timeline is so short that a rapid workflow sketch would suffice. Skip it when the task is entirely novel — task analysis must be grounded in user research first, not conducted as a desk exercise.
03 — How It Works
The mechanism
Task analysis works by decomposing a complex goal into its constituent elements until each element is atomic enough to be directly mapped to an interface action, a knowledge requirement, or a system dependency. The decomposition reveals the task's hidden complexity — the steps that users perform automatically, the conditional branches in edge cases, and the information dependencies between steps that create sequencing constraints the interface must respect.
Starting point, not destination
Task analysis describes how users currently accomplish a task — it does not describe how they should accomplish it. A task currently requiring eleven steps because of legacy workarounds should not automatically produce an eleven-step interface. The analysis reveals what the task requires today; design decisions determine what it should require tomorrow.
04 — Real Example
Salesforce Einstein Activity Capture and the email filing task analysis
When Salesforce's team was designing Einstein Activity Capture — an automated system to log sales rep emails into Salesforce without manual data entry — they began with a task analysis of how reps were currently logging activities manually. The analysis revealed that "log an email in Salesforce" was a twelve-step process: opening the email, identifying the relevant contact and opportunity, navigating to the correct record, manually copying subject line and date, summarising content, attaching it to the correct opportunity stage, and updating related fields.
The task analysis produced two critical insights. First, the twelve steps each took four to seven minutes per email — a cost that reps systematically avoided by not logging emails at all. Second, steps three through nine required information that Salesforce could identify automatically from email metadata, and human involvement was only genuinely necessary for the content summary and opportunity stage update. The task analysis identified exactly which steps were candidates for automation and which required human judgment, scoping the Einstein feature directly from the task structure.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a workflow feature that clearly mapped the full task structure before designing — or one where obvious steps in the user's process have no interface support? Submit what you observed.
Seen Task Analysis skipped in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
Task analysis sits within the workflow and process analysis tradition — methods focused on understanding the structure of what users do rather than the quality of how they feel about it.
The most important pairing is task analysis with Contextual Inquiry. Task analysis provides the analytical framework for structuring observations into a hierarchical map; contextual inquiry provides the observational data that makes the map complete and accurate. Together they produce the most complete available picture of what users need to do — at the level of specificity required to drive interface design decisions.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
Pick one task in your product that users need to complete — not a simple single action, but a multi-step goal like "set up a new project" or "complete an expense report."
1. Without looking at the interface, write down every step a user would need to complete this task from start to finish. Describe what the user needs to accomplish, not what the interface does. Aim for eight to fifteen steps. Include decisions, information needs, and dependencies.
2. Now open the interface and go through the same flow. For every step you wrote, note whether the interface supports it directly, requires the user to work outside the interface, or the step is missing entirely. Mark each: Supported, External, or Missing.
3. Count the Missing and External steps. Any Missing step is a design gap. Any External step is a handoff friction point.
4. If more than two steps are Missing or External, you have found a task coverage problem that warrants discussion before the next sprint.