Send a client proposal Prepare content Review & approve Deliver Gather client info Draft scope Set pricing Internal review Get sign-off Final edits Format PDF Send to client Track response DESIGN GAP No interface support task-analysis · goal → sub-tasks → operations · hidden structure visible · design gaps identified before build

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.

Workflow DesignFeature ScopingNavigation DesignOnboarding DesignEnterprise UXProcess Automation

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.

Apply this when…

A new feature involves a multi-step workflow where the team does not have a clear picture of every step a user must complete
An existing interface is generating support tickets or usability complaints and the team needs to understand whether the interface is misaligned with the actual task structure
A product is replacing a manual or legacy process — task analysis reveals what the new product must accommodate, including undocumented steps
Feature scope is being debated and the team needs a principled way to determine what is in scope versus what the user handles outside the product
A workflow is being automated and the team needs to determine which steps can be automated, which require human judgment, and which depend on inaccessible information

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.

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.

01
Cognitive task analysis reveals knowledge that experts cannot articulate
Research by Gary Klein on naturalistic decision making established that expert performance in complex tasks relies heavily on tacit knowledge — procedures and judgments that experts execute automatically. A nurse administering medication knows the sequence of verification steps without being able to describe them unprompted. Task analysis surfaces this tacit knowledge by asking not just "what do you do?" but "what do you need to know to do this?" and "what would go wrong if you skipped this step?"
02
HTA and the plan-operation structure
Hierarchical Task Analysis (HTA) decomposes the overall goal into sub-goals, each sub-goal into operations, and describes the plan — the conditions and sequence — for achieving each. An HTA for "book a meeting room" decomposes into: check availability, check room capacity, reserve the room, notify attendees. Each sub-goal is further decomposed: checking availability requires knowing the duration, attendees' constraints, and available rooms. The HTA makes visible that "book a meeting room" is a tree of dependent sub-tasks, each of which the interface must support.
03
The most valuable findings are the steps nobody mentioned
The most important steps in a workflow are the ones users do not mention when asked to describe the process — steps so deeply automated that users do not register them as steps. A financial analyst who has reconciled accounts monthly for five years does not mention "opening the previous month's report for comparison" because that step has become part of the context, not a step within it. Task analysis surfaces these invisible steps by asking users to walk through the task while doing it.
04
Completeness, accuracy, and interface coverage
A task analysis is complete when every atomic operation has been identified. Accuracy is validated by having users review the map. Interface coverage assesses what proportion of identified steps the current or proposed interface supports — steps with no support are either done outside the product (a design gap) or done manually (an automation opportunity). A task analysis revealing twenty-three operations when the interface supports twelve identifies eleven design gaps.

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.

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.

Salesforce · Einstein Activity Capture
Task analysis reveals automation scope from the task structure — not from feature requests
MANUAL EMAIL LOGGING · 12 STEPS 1. Open email 2. ID contact 3. Find opportunity 5. Copy subject 6. Copy date 7. Navigate record 9. Attach to opp 11. Save 4. Summarise 8. Stage update 10. Update 12. Confirm Automatable (8 steps) Human judgment (3 steps) System overhead (1 step) 8 of 12 steps automatable · scope from task structure Salesforce Einstein · task analysis of manual email logging · 12 steps · 8 automatable · automation boundary from task structure
Task analysis identified exactly which steps to automate and which require human judgment

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.

✓ Reviewed before publishing✓ Your name on every example you submit✓ Violation or fix — both welcome

Seen Task Analysis skipped in a real product? Help grow the evidence base.

Where teams go wrong

Conducting task analysis as a desk exercise without user input. A task analysis by the design team in a conference room maps how the team imagines the task works, not how users actually perform it. The most valuable findings — invisible automated steps, undocumented edge cases, workarounds — are only discoverable by talking to and observing the people who perform the task regularly.
Decomposing to the wrong level of granularity. Too early stops at sub-tasks too complex to map to interface actions. Too deep produces a map of cognitive and motor operations too granular to be actionable. The right level is where each element can be directly assessed: "does the interface support this step?" A step like "verify the client's address" is right; "recall the client's name from memory" is too granular.
Using task analysis to justify building the current workflow rather than improving it. Teams that build an interface supporting every step exactly as it exists reproduce the inefficiencies and legacy constraints of the current system. The goal is to understand the task well enough to redesign it intelligently — which steps can be eliminated, automated, or restructured?
Not distinguishing between task steps and interface steps. Every step maps to one of three things: an in-product user action, an out-of-product user action, or a system action. Teams that do not make this distinction end up with an over-complex interface trying to support everything — including steps that should be automated or happen outside the product entirely.

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.

Run it right now

⏱ 10 minutes · Solo · No prep

The Step Decomposition

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.

10 minutes