Understanding what users are actually doing before you design how they'll do it differently

Task analysis is a research method for breaking down how users accomplish a goal into its component steps, decisions, and cognitive processes. Instead of asking users what they want, it documents what they do — in detail.

The distinction matters in practice. Users are often poor at describing their own processes in the abstract. When interviewed about a workflow, they tend to describe the ideal version — what they're supposed to do, not what they actually do. Task analysis captures the real version: the shortcuts, the workarounds, the moments where the system forces an unexpected detour, and the cognitive load that accumulates across a session.

Hierarchical Task Analysis (HTA) breaks a task into a structured tree of sub-tasks — what steps are taken, in what sequence, and with what dependencies. It's procedural and well-suited to mapping complex workflows before redesigning them, identifying redundant steps, and scoping the impact of proposed changes.

Cognitive Task Analysis (CTA) goes deeper, focusing on the mental processes behind each step: what the user is deciding, what information they need, and where errors are most likely. It's more appropriate for high-stakes, expert-user contexts — healthcare software, industrial control systems, financial tools — where cognitive demands are as important as the physical sequence of steps.

Most product teams don't need full CTA. HTA is sufficient for the majority of workflow design problems at growth-stage and startup scale.

HTA typically follows this process:

1. Define the goal — the outcome the user is trying to achieve, stated in their terms, not system terms
2. Observe users completing the task in context — Contextual Inquiry is the highest-fidelity approach; session recordings are a reasonable alternative
3. Document every step — including implicit ones that users take for granted and wouldn't mention in an interview
4. Identify decision points — where users have to evaluate a situation or choose between options
5. Map dependencies — which steps must precede others, and what breaks if they don't

The output is a structured diagram or table showing the full task hierarchy, decision branches, and failure paths — a reference document the design team can use throughout the project.

Interviews tell you what users think they do. Task analysis tells you what they actually do.

The gap between the two is where the most useful design insight tends to live:

• Workarounds users have built and no longer consciously notice — but which any redesign will break
• Steps they've automated through habit, which won't surface in conversation but will cause friction if the new design disrupts them
• Cognitive load concentrations — moments where multiple decisions happen simultaneously — that are invisible in a structured interview

This is particularly valuable for Design Handoff scenarios, where a team is redesigning an existing workflow used by people with deep expertise in the current system. Understanding what those users have adapted to is the baseline for knowing what you can safely change.

Task analysis is a front-of-project tool. It belongs before Wireframing, before flow diagrams, before any screen-level decisions. Its output — a detailed map of what users currently do and why — gives the design team the foundation to make deliberate choices about what to change and what to preserve.

It's especially valuable for complex B2B or enterprise redesigns, where users have years of practice with the current system and any change disrupts embedded muscle memory. Teams that skip task analysis in these projects consistently underestimate the disruption of their redesigns on expert users — and find out after shipping, which is a much harder time to fix it.