4 - Task Analysis for Interface Design

Foundations of Task Analysis

1

Foundations of Task Analysis

▶

Task analysis is one of the most foundational practices in user experience and interface design. At its core, it is a disciplined method for understanding what people actually do when they try to accomplish something — breaking down human activity into its constituent parts so that designers can build systems that support, rather than obstruct, real-world behavior. Before a single screen is sketched or a navigation structure is proposed, task analysis asks a deceptively simple question: what does the user need to do, and in what order? The answers to that question shape almost every meaningful design decision that follows.

Because task analysis grounds design in observed and documented human behavior, it acts as a corrective against one of the most persistent dangers in interface design: the assumption that users think about a problem the same way the design team does. Designers, developers, and product managers all carry mental models shaped by deep familiarity with the system they are building. Task analysis forces a shift in perspective — away from the system's internal logic and toward the user's lived experience of trying to get something done.

What Task Analysis Is

Task analysis focuses on the observable actions users take to achieve a defined goal. Rather than asking "what features should this interface have?" it asks "what does a user actually do, step by step, to reach a desired outcome?" This behavioral orientation is what distinguishes task analysis from other early-stage design activities like stakeholder interviews or market research. Those activities tell you what people want; task analysis tells you how they go about getting it.

The process is structured and systematic. A designer or researcher identifies a meaningful goal — say, booking a flight, filing an expense report, or editing a photograph — and then maps out every action a user must perform to complete that goal. These actions are organized into sequences, hierarchies, or flows depending on the method used. The resulting documentation is not a design artifact in itself; rather, it is a pre-design artifact: a factual record of user behavior that design decisions should be traceable back to.

One of the most important functions of task analysis is that it produces shared reference documents that cross-functional teams can all work from. A UX designer, a front-end developer, a content strategist, and a product owner may all interpret a design brief differently. But a well-constructed task analysis gives everyone on the team a common, neutral description of user behavior that is not yet colored by any particular design solution. This makes it an especially powerful communication tool in multidisciplinary environments where misalignment between disciplines can be costly.

Because task analysis is grounded in observable behavior, it also helps teams avoid building interfaces around assumptions. For example, a team building a document management system might assume that users always know which folder they want to save a file into before they save it. A task analysis might reveal that users frequently search for the right folder after opening the save dialog — a discovery that would significantly affect how the interface should be structured. Without task analysis, that assumption might go unchallenged until usability testing or, worse, after launch.

The Role of User Goals

Central to any task analysis is a clear understanding of user goals. A user goal describes a desired outcome — a state of the world the user wants to bring about. Critically, a goal is not an action or an interface element. "Click the Submit button" is an action. "The form is submitted" is a system event. "My expense report has been approved so I can be reimbursed" is a user goal. The distinction matters enormously, because designing for goals rather than actions keeps the interface oriented toward what actually creates value for the user.

Goals must always be expressed from the user's perspective, not the system's. A system might have an internal goal of "write a validated record to the database." The corresponding user goal might be "save my work so I don't lose it." These two framings can lead to very different design decisions. The system-centric framing might result in a rigid save workflow with strict validation before any record is committed. The user-centric framing would more likely lead to auto-save features, draft states, and gentle rather than blocking validation — because the user's underlying concern is continuity and safety of their work, not database integrity.

Identifying user goals early in the design process prevents one of the most common and expensive forms of misalignment in product development: building an interface that is internally consistent and technically sound but that does not match what users are actually trying to accomplish. When the interface structure reflects the system's architecture rather than the user's goal structure, users find themselves forced to learn the system's logic just to accomplish something simple.

An important nuance is that multiple user types may share a goal but follow very different paths to achieve it. Consider the goal "find out the status of my order." A technically confident user might navigate directly to an account dashboard and scan a data table. A less experienced user might use a search bar and type in their order number. A user who received an email confirmation might click a tracking link directly. A task analysis that only accounts for one of these paths will produce an interface that serves only a subset of the actual user population. Documenting goal-sharing across different user types is therefore an essential part of building an inclusive interface.

Why Task Analysis Informs Interface Structure

The connection between task analysis and interface structure is direct and practical. When a task is broken down into its sequential steps, that sequence suggests a natural order in which interface elements should be presented to the user. If step three of a task requires information that was entered in step two, the interface should not bury step two in a different section or require the user to navigate away and return. The task sequence is, in effect, a prototype of the information architecture.

Task analysis also surfaces decision points — moments in a task where the user must choose between two or more different paths depending on their situation or intent. A decision point is a signal to the designer that the interface must provide clear branching options, explicit labels, and often feedback to help the user understand which branch is appropriate for them. For example, in a tax preparation workflow, a user might reach a decision point where they must indicate whether they are filing as an individual or a business. That single decision point might lead to entirely different sets of subsequent screens. Identifying it early through task analysis means the designer can plan for that branching deliberately rather than discovering it mid-prototype.

When a task is broken into subtasks, those subtasks often suggest natural candidates for screens, panels, workflow stages, or grouped form sections. A task like "set up a new employee account" might decompose into subtasks such as entering personal information, assigning a role and permissions, setting up login credentials, and sending an invitation. Each of these is cohesive enough to represent a distinct step in a multi-step form or wizard, and grouping them this way in the interface reflects the natural structure of the task rather than an arbitrary organizational decision.

Perhaps most valuably, task analysis identifies the steps that are most likely to produce errors. When a step requires the user to recall specific information from memory, combine information from multiple sources, perform a calculation, or make a judgment call under uncertainty, that step is a candidate for additional interface support: inline help text, validation, smart defaults, autofill, or confirmation dialogs. Without task analysis, these high-risk steps might look identical to low-risk steps in a wireframe, and the need for additional support might not become apparent until testing.

Observable vs. Cognitive Steps

One of the most important conceptual distinctions in task analysis is between observable steps and cognitive steps. Understanding both — and capturing both in an analysis — is what separates a superficial account of a task from a genuinely useful one.

Observable steps are actions that can be seen, heard, or otherwise directly measured. Clicking a button, entering text into a field, selecting an item from a dropdown, scanning a barcode, pressing a key — all of these are observable. They can be timed, counted, and compared. An interface can be directly evaluated on how well it supports these actions: is the button large enough to click accurately? Is the field labeled clearly enough to know what to type?

Cognitive steps, by contrast, involve mental processes that are not directly visible. Judging whether a result set matches what was intended, recalling an account number from memory, deciding which of three similar options best fits the current situation, interpreting an error message, understanding what a technical term means — these are all cognitive steps. They are embedded in the task just as surely as any observable action, but they leave no visible trace in interaction logs.

The danger of ignoring cognitive steps is that it produces interfaces that are technically functional but cognitively demanding. An interface in which every button works perfectly and every form submits without errors can still be exhausting and error-prone to use if it forces users to hold too much information in working memory, make too many ambiguous judgments, or recall information they have no way of knowing in advance. Classic examples include interfaces that require users to remember and re-enter information they provided on a previous screen, or systems that present status codes without translating them into plain-language meanings.

Different task analysis methods emphasize these two dimensions to different degrees. Methods derived from industrial engineering, such as Hierarchical Task Analysis, tend to focus heavily on observable actions and are well suited to tasks with clear, repeatable physical steps. Methods rooted in cognitive science, such as Cognitive Task Analysis or GOMS (Goals, Operators, Methods, and Selection rules), explicitly model the mental operations a user must perform and are better suited for tasks with significant judgment, problem-solving, or memory demands. Choosing the right method — or combining methods — requires understanding what kind of task you are analyzing and which dimension is most likely to drive design decisions.

To illustrate the difference concretely, consider a user who needs to transfer money between two bank accounts using a mobile app. The observable steps might include: open the app, navigate to the transfers section, select the source account, select the destination account, enter the amount, review the summary screen, and confirm the transfer. A purely observable analysis might stop there. But the cognitive steps running alongside those observable actions are equally important: recognizing which account is which when both are labeled with partial account numbers, deciding whether the available balance shown is sufficient for the transfer, judging whether the transfer will arrive in time given an unfamiliar processing time estimate, and verifying that the summary screen reflects the intended transaction before confirming. Each of these cognitive steps is a design opportunity — for clearer account labeling, for balance visibility, for plain-language processing time explanations, and for a confirmation screen that makes the critical details easy to verify at a glance.

The following table summarizes the key differences between observable and cognitive steps, and their implications for interface design:

Dimension	Observable Steps	Cognitive Steps
Definition	Visible, measurable physical actions	Internal mental processes not directly visible
Examples	Clicking, typing, selecting, scrolling	Recalling, judging, interpreting, deciding
How captured	Direct observation, interaction logging	Think-aloud protocols, interviews, cognitive walkthroughs
Risk if ignored	Interface may require unnecessary physical effort	Interface may be cognitively overwhelming despite being mechanically usable
Design response	Reduce clicks, improve affordances, streamline navigation	Provide reminders, defaults, plain language, progressive disclosure
Dominant analysis methods	Hierarchical Task Analysis, workflow diagrams	Cognitive Task Analysis, GOMS, think-aloud studies

Together, these four foundational ideas — what task analysis is, how user goals anchor it, why it shapes interface structure, and how it must account for both observable and cognitive steps — form the conceptual bedrock on which all specific task analysis methods are built. A designer who internalizes these principles is equipped not just to apply a particular technique, but to adapt their approach to the demands of any design problem they encounter.

NotesCovers all four subtopic clusters in depth with practical examples throughout. The money transfer example near the end concretely illustrates the observable/cognitive distinction. The summary table provides a quick comparative reference. Tone is instructional and explanatory throughout, appropriate for a foundational module.

2

Videos on This Topic

▶

Task analysis is the practice of breaking down what people actually do to accomplish a goal, step by step, before deciding what an interface should look like. Instead of starting with screens, buttons, or layouts, you start with the user's goal and the sequence of actions, decisions, and judgments that lead to it. Once that structure is clear, the interface can be organized to match it rather than forcing users to reorganize their work to match the software.

This topic sets up the vocabulary you will use for the rest of the module. A goal is the end state the user wants; a task is the work done to reach it; and tasks decompose into subtasks and operations. Some of those steps are observable (clicking, typing, scanning a label, picking up a document), while others are cognitive (recalling a value, comparing options, deciding whether an action moved them closer to the goal). Observable steps can be watched and timed; cognitive steps have to be inferred through questioning, think-aloud protocols, or structured inspection, which is why task analysis uses more than one method.

As you watch the videos below, focus on three things. First, notice how each one separates the user's goal from the mechanics of the path taken to reach it. Second, watch for where the invisible, in-the-head work shows up — the moments where a user has to know, remember, or decide something. Third, think about how each representation (a journey, a flow, a walkthrough question set, an interaction cycle) could be converted into a hierarchical breakdown of the kind you will build later in this module.

3

Video 1: User Journeys vs. User Flows (And When to Use Each)

▶

NNgroup · 3:47 · 25,219 views · 1y ago · captions — Watch on YouTube

About this video

This short Nielsen Norman Group video contrasts two common ways of documenting a user's process: user journeys, which track a broader experience toward a goal, and user flows, which trace the specific step-by-step path through a system. Based on its title and description, it explains what each artifact captures, how they differ in scope and level of detail, and how teams use them together.

Why this video

It directly supports the subtopics on user goals and on why task analysis informs interface structure, since both artifacts are goal-anchored decompositions of a process, and NN/g is a long-standing authority on UX method definitions.

4

Video 2: Cognitive Walkthroughs Help Assess Interface Learnability

▶

NNgroup · 4:45 · 14,522 views · 3y ago · captions — Watch on YouTube

About this video

A cognitive walkthrough is a task-based inspection method in which evaluators step through a task as a new user would and ask, at each step, whether the user would know what to do and whether they would recognize that their action worked. This video introduces the technique and its use in assessing how learnable a system is from a first-time user's perspective.

Why this video

It is the clearest short treatment of observable versus cognitive steps, because the walkthrough questions make the hidden knowing-and-deciding work explicit at every action, and it previews the thinking behind cognitive task analysis.

5

Video 3: How do Humans Interact with Computers. A Cycle of Interaction in HCI

▶

IxDF - Interaction Design Foundation · 3:31 · 11,761 views · 3y ago · captions — Watch on YouTube

About this video

This Interaction Design Foundation video presents the cycle of interaction between a person and a computer — forming an intention, carrying out actions, and then perceiving and interpreting the system's response. It frames human-computer interaction as a repeating loop rather than a single action, which is the conceptual basis for why tasks decompose into goals, actions, and evaluations.

Why this video

It gives you the underlying model that makes task analysis coherent, connecting user goals to observable actions and to the cognitive interpretation that happens between them, from a well-established design education publisher.

6

How These Videos Support the Learning Outcomes

▶

Together these videos build the conceptual groundwork the module's outcomes depend on. The interaction cycle and the journey-versus-flow comparison give you the goal-to-step decomposition logic behind hierarchical task analysis and the structured diagrams you will produce (MO1, MO2), while the cognitive walkthrough video models how to surface the knowledge, recall, and decision steps that cognitive task analysis targets (MO1). All three train you to read a task sequence for points of confusion, missing feedback, or unnecessary detours — exactly the bottlenecks and design implications you will be asked to extract from your own task analysis results (MO3).

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Hierarchical Task Analysis (HTA)

1

Hierarchical Task Analysis (HTA)

▶

Hierarchical Task Analysis (HTA) is a structured method for understanding how users accomplish goals by breaking complex activities into progressively smaller, more manageable units of work. Originally developed by Annett and Duncan in the 1960s within industrial and military psychology, HTA has since become one of the most widely applied techniques in human–computer interaction, usability engineering, and user-centered design. Its enduring value lies in the way it makes the internal logic of a task visible and inspectable: by arranging goals, tasks, and subtasks in a tree structure, analysts and designers can reason clearly about what users need to do, in what order, and under what conditions — long before a single pixel of interface is drawn.

Unlike simpler checklists or linear workflows, HTA captures the genuine complexity of real user behavior. It acknowledges that many goals involve choices, conditions, and parallel paths, and it provides explicit notation for expressing those nuances. The result is a living document that bridges user research and design, giving design teams a traceable, justifiable foundation for every structural and navigational decision they make.

Principles of HTA

The foundational intellectual commitment of HTA is a top-down decomposition philosophy. Analysis always starts from the highest-level user goal within the scope of the study — not from the interface that currently exists, not from the steps a system enforces, but from what the user is fundamentally trying to achieve. This orientation keeps the analysis honest and prevents it from accidentally inheriting the biases or inefficiencies of legacy designs.

From that top-level goal, the analyst asks a deceptively simple question: What does the user have to do to accomplish this? The answer produces a set of subtasks. Each subtask is then treated as a goal in its own right and subjected to the same question, producing another layer of subtasks. This recursive process continues downward through however many levels of granularity the project requires. The resulting structure is genuinely hierarchical: every node (except the root) belongs to exactly one parent, and every parent task is fully accomplished when all of its children are accomplished.

A critical principle is that the hierarchy makes dependencies and sequences explicit. When subtasks are listed under a parent, the analyst is not merely cataloguing activities — they are asserting a structural claim about how those activities combine to produce the parent. This forces precision that informal task descriptions rarely achieve. If two subtasks must happen in sequence, that is documented. If one subtask is only triggered by a condition, that too is recorded. Nothing is left implicit.

HTA is particularly well-suited to procedural, goal-directed tasks with clear start and end points — tasks like booking a flight, submitting an expense claim, configuring a device, or renewing a subscription. These tasks have a definite goal state (the booking is confirmed, the claim is submitted), and users follow recognizable paths to reach it. HTA is less naturally suited to purely exploratory or creative activities without clear end states, though it can still be applied to the procedural components embedded within them.

HTA Notation and Diagrams

HTA uses a hierarchical numbering scheme to uniquely identify every task node and to encode its position in the tree at a glance. The top-level task is conventionally numbered 0. Its immediate subtasks are numbered 1, 2, 3, and so on. The subtasks of task 1 are numbered 1.1, 1.2, 1.3. Subtasks of task 1.2 become 1.2.1, 1.2.2, and so forth. This system means that any node's number tells you both its identity and its ancestry without needing to trace the diagram.

Alongside the task nodes, HTA introduces the concept of plans. A plan is attached to every task that has subtasks and describes the order, conditions, or rules governing how those subtasks must be executed. Plans are where the logical richness of HTA really lives. Common plan types include:

Fixed sequence: Subtasks must be performed in the listed order (e.g., "Do 1, then 2, then 3"). This is appropriate when each step creates a precondition for the next.
Any order: Subtasks may be performed in any sequence (e.g., "Do 1, 2, and 3 in any order"). This is appropriate for tasks where steps are independent of one another.
Conditional: Only certain subtasks are performed depending on the situation (e.g., "If new user, do 1.1; if returning user, do 1.2"). This captures decision points and branching paths.
Iterative: A subtask or set of subtasks is repeated until a condition is met (e.g., "Repeat 2.1 until all items are reviewed").
Discretionary: The user decides which subtasks to perform and when, based on their own judgment.

HTA can be represented in two complementary formats: diagrams and indented outlines. Diagrams present the hierarchy visually as a tree, with boxes for tasks connected by lines to their parent and child nodes. Plans are typically written below the parent box or on the connecting lines. Diagrams offer an immediate gestalt view of the entire task structure and are excellent for communicating with stakeholders in presentations or workshops. Indented outlines express the same hierarchy as structured text, with indentation levels replacing the branching lines of the diagram. Outlines are easier to produce, edit, and version-control, and they integrate naturally into design documentation and specification documents.

The following table illustrates how the numbering, task descriptions, and plans combine in an outline representation for a simplified "Book a Flight" goal:

Task Number	Task Description	Plan
0	Book a flight	Do 1, then 2, then 3, then 4 in sequence
1	Search for available flights	Do 1.1, 1.2, 1.3, then 1.4 in sequence
1.1	Enter origin and destination	—
1.2	Enter travel dates	—
1.3	Specify number of passengers	—
1.4	Submit search	—
2	Select a flight	If filtering needed, do 2.1; then do 2.2
2.1	Apply filters (price, airline, stops)	Do any subset in any order
2.2	Choose flight from results list	—
3	Provide passenger details	Do 3.1, 3.2, 3.3 in any order
3.1	Enter passenger name(s)	—
3.2	Enter contact information	—
3.3	Enter passport or ID details	—
4	Complete payment	Do 4.1, then 4.2, then 4.3 in sequence
4.1	Select payment method	If new card, do 4.1.1; if saved card, do 4.1.2
4.1.1	Enter card details	—
4.1.2	Confirm saved card	—
4.2	Review order summary	—
4.3	Confirm and submit payment	—

Consistent notation across an entire project team is not a cosmetic concern — it is essential for the documentation to function as a shared, authoritative artifact. When different analysts apply different numbering conventions, plan vocabularies, or decomposition depths, the resulting documents cannot be compared, merged, or reliably handed off between team members. Establishing a notation standard at the outset of a project pays dividends throughout the design and evaluation phases.

The Decomposition Process in HTA

Conducting an HTA in practice begins with scoping the analysis: identifying which user goal will serve as the root of the hierarchy. This is usually determined by the research questions driving the project. If the project concerns improving the checkout flow of an e-commerce site, the root goal might be "Purchase selected items." If it concerns an enterprise HR system, the root might be "Submit annual leave request." The scope decision matters because it determines the depth and breadth of the entire analysis.

With the root goal defined, the analyst proceeds by decomposition. At each level, the question is: What must the user do to accomplish this task? The answers become the children of the current node. A useful quality check is to ask whether each subtask is both necessary (the parent cannot be achieved without it) and sufficient in combination (performing all children completes the parent). If a proposed subtask is optional in all circumstances, it may belong in a conditional plan rather than as a mandatory branch. If the children do not fully account for completion of the parent, something is missing.

Decomposition stops — at any given branch — when the steps have become discrete enough to directly suggest interface actions. This stopping criterion is sometimes called the P × C rule from Annett and Duncan's original formulation: decomposition is no longer worthwhile when the performance cost (effort of further analysis) outweighs the cost of inadequate specification. In practical UX work, the informal version of this rule is: stop when you can point at a specific UI element (a button, a form field, a dropdown) and say "this subtask is accomplished by interacting with this control." Going deeper than that produces detail that belongs in a style guide or component specification rather than a task analysis.

Critically, the decomposed tasks must be validated against real user data. An HTA constructed purely from the analyst's assumptions or from system documentation risks encoding the designer's mental model rather than the user's. Observation sessions, contextual inquiry, think-aloud studies, and interviews with actual users are all appropriate sources of validation. Where the observed user behavior diverges from the analyst's initial decomposition, the HTA should be revised to match reality. A common discovery during validation is that users accomplish a subtask in a different order than expected, or that they routinely skip a step the analyst considered mandatory — both of which have direct implications for design.

Applying HTA to Interface Design

Once constructed and validated, an HTA becomes a powerful generative tool for interface design. The structural relationships captured in the hierarchy map onto interface structures in predictable and useful ways.

Top-level tasks frequently correspond to primary navigation. If the HTA for an application has five major subtasks under the root goal, those five tasks are candidates for the five items in the primary navigation bar or the five tiles on a dashboard home screen. This is not a mechanical rule — good design requires judgment — but the HTA provides an evidence-based rationale for why those categories exist and what user goals they serve. Without HTA, navigation categories often reflect organizational structure or developer convenience rather than user goals.

Sequential subtasks suggest step-by-step interface patterns. When an HTA plan calls for a strict sequence — do step A, then step B, then step C — this is a strong signal that the interface should guide the user through that sequence explicitly. Wizard patterns, stepped forms, and progress indicators all exist precisely to support sequential task structures. HTA makes the case for using these patterns from user research rather than from aesthetic preference.

Conditional plans reveal where the interface must branch. Every conditional plan in an HTA identifies a point where the user's situation determines which path they follow. At these points, the interface must either detect the condition automatically (and route the user appropriately) or present a clear decision point that allows the user to self-select their path. Failing to surface conditional branches in the interface forces users to navigate a path designed for a different user type, which is a common source of friction and error.

Iterative plans indicate where repetition support is needed. When an HTA plan specifies that a subtask repeats until a condition is met — for example, adding multiple items to a list — the interface should provide affordances for that repetition: an "Add another" button, a dynamic list, a bulk-entry mechanism. Without HTA, these needs are easily overlooked until user testing reveals the gap.

Beyond individual patterns, HTA documentation provides traceable justification for design decisions. When a stakeholder asks "Why is the checkout split into four screens?" or "Why does the filter panel appear here rather than there?", the design team can point to specific nodes and plans in the HTA and explain precisely which user tasks and conditions motivated those decisions. This traceability strengthens the design team's position in reviews and makes it easier to assess the impact of proposed changes: altering a design element whose rationale is anchored in HTA requires revisiting the task analysis, which immediately surfaces any downstream consequences.

Consider a concrete design application: suppose the HTA for a recipe app reveals that the "Cook a recipe" goal has subtasks including "View ingredient list," "Follow step-by-step instructions," and "Set cooking timers" — and that the plan governing them is discretionary, meaning users move between these subtasks in whatever order suits them while cooking. This insight argues against a linear wizard interface (which would lock users into a sequence) and in favor of a tabbed or freely navigable layout where all three sections are always accessible. The HTA has directly and defensibly shaped the information architecture.

The power of HTA ultimately lies in this combination of rigor and applicability. It is rigorous because it requires explicit, validated documentation of every task and its governing logic. It is applicable because its outputs map directly onto the vocabulary of interface design: navigation, screens, forms, wizards, branches, and repetition mechanisms. Used well, HTA transforms the messy reality of user behavior into a structured, communicable model that design teams can reason about, argue from, and build upon throughout the entire design lifecycle.

NotesThe flight-booking worked example is woven through the notation section to give learners a single consistent illustration they can follow across numbering, plans, and the HTML table. The table renders all task/plan data; no ASCII art is used. Plan types are listed as a <ul> for scannability. The design implications section connects each HTA feature (sequential plans, conditional plans, iterative plans) to a named interface pattern to make the application concrete.

2

Videos on This Topic

▶

Hierarchical Task Analysis (HTA) is a structured way of describing what people actually do when they use a system. You start with a high-level goal, break it into subgoals and operations, and keep decomposing until the steps are concrete enough to be useful for design. The result is usually drawn as a numbered tree or written as an indented outline, with plans that state the order and conditions under which subtasks are carried out.

HTA matters in this course because interface requirements come from tasks, not from guesses. Once you have decomposed a workflow, you can see where steps are repeated, where users must remember information between screens, where errors are likely, and which tasks deserve shortcuts or automation. HTA also gives you a shared notation for discussing a workflow with teammates and stakeholders before any screens are designed.

The videos below approach decomposition and task modeling from different fields: instructional task analysis, hierarchical fault-tree modeling in process improvement, and UML use case diagrams in software analysis. As you watch, focus on the transferable mechanics: how a goal is stated, how far the decomposition is taken, how levels are numbered or labeled, and how the finished diagram is read back as a description of work. Then ask yourself how each representation would translate into an HTA tree with plans for an interface you are designing.

3

Video 1: Task Analysis Tutorial

▶

Delaware Network for Excellence in Autism · 6:43 · 286 views · 4y ago · captions — Watch on YouTube

About this video

A short tutorial from the Delaware Network for Excellence in Autism on task analysis as it is used in teaching and support settings. Based on its title and description, it likely walks through taking a everyday activity, breaking it into an ordered sequence of observable steps, and using that step list to teach or prompt a person through the activity. The focus is on how finely a task should be broken down so that each step is clear and performable.

Why this video

It gives a concrete, non-technical demonstration of the core HTA skill of decomposing a goal into steps at an appropriate level of detail, which is the foundation of the decomposition process subtopic before notation is added.

4

Video 2: 06e Method Model your Observations

▶

Dr. Reiner Hutwelker · 10:58 · 1,060 views · 5y ago · captions — Watch on YouTube

About this video

Dr. Reiner Hutwelker guides viewers through building a hierarchical fault tree to organize observations and knowledge gathered during a process improvement project. The video is expected to cover how to structure what you observed into parent and child nodes, how levels relate to one another, and how the hierarchy is used to reason about where problems originate. It is part of a longer methods series on structured problem analysis.

Why this video

The hierarchical tree logic, level-by-level breakdown, and emphasis on turning raw observations into a structured diagram map directly onto HTA notation and the decomposition process you will use for user workflows.

5

Video 3: UML use case diagrams: Everything you need to know

▶

Lucid Software · 12:42 · 1,027,119 views · 3y ago · captions — Watch on YouTube

About this video

Lucid Software's widely viewed tutorial explains UML use case diagrams: actors, use cases, system boundaries, and the include and extend relationships between them. It covers notation conventions and walks through constructing a diagram from a described system, aimed at both beginners and those with some UML experience.

Why this video

Use case diagrams are a complementary way of modeling goal-directed user interaction, so this video reinforces disciplined notation and shows how a task or goal model feeds directly into interface and system requirements.

6

How These Videos Support the Learning Outcomes

▶

Together these videos build the module outcomes in layers. The autism-network tutorial and the hierarchical fault-tree video model the decomposition steps at the heart of HTA, supporting MO1 by showing how a goal is progressively broken into subtasks and MO2 by demonstrating how that breakdown is captured in an ordered, hierarchical structure you can reproduce for a target user workflow. The fault-tree and UML videos then push toward MO3: the fault tree shows how a hierarchy is read back to locate problem sources and bottlenecks, while the use case tutorial shows how goal-level models are translated into system boundaries and requirements, which is exactly the move from task analysis results to interface design implications.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Cognitive Task Analysis (CTA)

1

Cognitive Task Analysis (CTA)

▶

Hierarchical Task Analysis gives us a clear map of what users do — the observable steps, sequences, and sub-goals that make up a task. But experienced designers quickly discover that this map has a significant blind spot: it says almost nothing about what is happening inside the user's head while those steps are being executed. Why does an expert complete a task effortlessly while a newcomer hesitates, makes a wrong turn, or misinterprets a status message? The answer lies not in the sequence of actions but in the knowledge, judgments, and mental representations that drive those actions. Cognitive Task Analysis (CTA) is the family of methods designed to surface exactly that invisible layer. It extends the work of task analysis by systematically uncovering the cognitive demands, decision points, and knowledge structures that underlie observable behavior — and by doing so it gives designers the raw material they need to build interfaces that genuinely support the way people think, not merely the way they move their hands.

What CTA Adds Beyond HTA

The most fundamental contribution of CTA is a shift in the unit of analysis. Where HTA asks "what does the user do next?", CTA asks "what does the user need to know, perceive, judge, or remember in order to do that next thing?" This seemingly small shift has profound consequences for what gets designed and how it gets designed.

One of the most important things CTA surfaces is tacit knowledge — the kind of knowledge that experienced users possess but can rarely articulate unprompted. A seasoned accountant processing an expense report knows at a glance that a particular line item is suspicious, but if asked to describe their process they may simply say "I just checked it." They are not being evasive; they genuinely cannot easily access the perceptual pattern-matching and heuristic judgment that years of practice has made automatic. CTA methods are specifically designed to slow down and externalize this automatic processing so it becomes visible. Once visible, it can be considered during design: perhaps a visual highlight, a range validator, or an inline benchmark figure would help a novice reach a similar judgment without years of experience.

CTA also reveals decision points — moments in a task where the user must evaluate two or more possible next actions and choose between them based on system state, contextual information, or personal judgment. HTA may represent these as a branch in the task tree, but it rarely captures what information the user needs to make that branch decision correctly, what they might misread, or what happens cognitively when the information is ambiguous. CTA makes all of that explicit.

Practically speaking, the findings from CTA directly shape several categories of design decisions: onboarding and training materials can be targeted at the precise knowledge gaps novices have rather than narrating steps that anyone can read from the screen; error messages can be written to address the actual misconception or missing information that caused the error rather than simply stating what went wrong technically; and instructional cues such as tooltips, inline hints, and contextual help can be placed at the specific moments in a workflow where cognitive demand peaks.

Key CTA Techniques

CTA is not a single method but a collection of complementary techniques, each suited to different aspects of cognitive work and different research situations. Choosing among them requires matching the technique to the complexity of the task, the expertise of the users involved, and the time and resources available for research.

Think-aloud protocols are the most widely used CTA technique and the most accessible entry point. The user is asked to perform a realistic task while continuously narrating their thought process — not explaining or justifying after the fact, but speaking their thoughts in real time as they occur. The researcher observes and records without intervening except to gently prompt continued verbalization when the user goes silent. The resulting transcript is rich with evidence of what information the user is attending to, what they expect to happen, what confuses them, and how they diagnose problems. For example, a user attempting to filter a data table might say aloud: "Okay, I see a search bar but I'm not sure if that searches the whole database or just what's on screen — I'll try it and see…" That single utterance reveals a mental model gap (uncertainty about search scope), a coping strategy (trial and error), and a potential design opportunity (clarifying the scope of the search affordance). Think-aloud protocols are particularly valuable early in a project when the design team needs a broad, exploratory view of cognitive demands across a task.

Critical Decision Method (CDM) interviews are retrospective rather than concurrent. A researcher asks an experienced practitioner to recall a specific, memorable instance of performing a particularly challenging version of the task — ideally a real incident rather than a hypothetical. Through a structured series of probing questions the interviewer works to reconstruct not just the sequence of events but the decision moments within that sequence: What information did you have at that point? What options were you weighing? What made you choose this path rather than that one? What would a less experienced person have missed? CDM is especially powerful for studying high-stakes, infrequent, or time-pressured tasks where think-aloud is impractical — surgical decisions, emergency response, financial risk assessment — and for extracting the expertise of highly skilled practitioners who cannot easily volunteer their knowledge without prompting. The method requires a skilled interviewer who can use follow-up probes such as "What would have had to be different for you to have made a different choice there?" without leading the participant.

Knowledge audits take a more systematic, structured approach. Rather than observing or interviewing around a single task performance, a knowledge audit produces a comprehensive inventory of the information types, concepts, mental categories, and heuristic rules that a user population must master. This might involve structured elicitation techniques borrowed from knowledge engineering — card sorting to discover how users categorize domain concepts, repertory grids to reveal the attributes users use to distinguish between cases, or concept mapping to show how domain knowledge is organized. Knowledge audits are especially useful when designing complex information systems, enterprise tools, or training programs where the designer needs a thorough model of the domain knowledge that the interface must support or teach.

The following table summarizes the key characteristics of these techniques to support technique selection:

Technique	Data Collection Timing	Best Suited For	Primary Output	Key Limitation
Think-Aloud Protocol	Concurrent (during task)	Exploratory discovery of cognitive demands across a workflow	Verbatim transcripts annotated with cognitive observations	Verbalization can interfere with or alter natural cognitive processing
Critical Decision Method	Retrospective (after task)	Expert knowledge in high-stakes or infrequent tasks	Decision event narratives with identified cues, options, and rationale	Memory reconstruction may omit or distort details
Knowledge Audit	Structured elicitation session	Comprehensive domain knowledge mapping for complex systems	Concept maps, knowledge inventories, taxonomies	Time-intensive; requires skilled elicitation facilitation

In practice, CTA projects often combine techniques: a knowledge audit may establish the domain vocabulary before think-aloud sessions, and CDM interviews with experts may follow to probe the high-stakes decision moments that emerged from think-aloud observations.

Identifying Decision Points and Mental Models

Two analytical constructs sit at the heart of CTA findings: decision points and mental models. Both are diagnostic tools that connect cognitive observations to design action.

A decision point is any moment in a task where the user must evaluate the current state of the system or environment and select among two or more possible next actions. Decision points are not always explicit branch menus or dialog boxes — they are often invisible to the interface but highly consequential to the user. Consider a user who has just submitted a form and sees a spinning indicator. A decision point has arisen: should they wait, refresh, navigate away, or try again? The interface has presented no explicit choice, but the user must nonetheless make a judgment. CTA identifies these moments, documents what information is available to the user at that point, what information the user actually needs to make the correct decision, and what happens when those two things diverge. That last question — the divergence — is where error prediction lives.

A mental model is the user's internal representation of how the system works. It is not a technically accurate specification; it is a functional, often approximate, sometimes metaphorical model that is good enough to generate predictions about system behavior and guide action. Users form mental models from prior experience with analogous systems, from interface affordances and labels, from onboarding materials, and from trial and error. A user who has primarily used desktop email software will arrive at a web-based email client with a strong mental model derived from that experience — and certain design choices (like whether "delete" moves a message to trash or immediately destroys it) will either align with or violate that model.

The relationship between mental models and design is bidirectional. Designers must first document the mental models that exist in their user population — CTA is the tool for doing this. Then they must align the interface's behavior, metaphors, terminology, and feedback with those models wherever alignment is possible. Where the system must behave in a way that diverges from the user's likely mental model, the design must actively work to correct the model through labeling, animation, or explanatory copy.

The most predictive finding in CTA is often the identification of a mental model gap: a specific point where the user's model of the system diverges from its actual behavior. These gaps are not random; they cluster around certain design patterns. For example, users frequently model undo as a simple reverse of the last action, when in fact an application's undo stack may have complex branching behavior. When the user's model predicts one outcome and the system produces another, an error — or at minimum confusion and loss of trust — is almost certain to result. Documenting these gaps during CTA gives the design team a prioritized list of the exact points where design intervention will have the greatest impact on usability.

Representing CTA Findings

Raw CTA data — transcripts, interview notes, observation logs — must be synthesized into a form that a design team can act on. Several representation formats have been developed, each with different strengths depending on the audience and the design decisions being supported.

Annotated HTA diagrams are the most immediately accessible representation for teams already working with task hierarchies. The existing HTA tree is preserved but each node is augmented with cognitive annotations: what does the user need to know or perceive at this step? What decision is being made? What is the cognitive load? What mental model is being applied? This format is efficient because it builds on existing documentation and makes cognitive demands visible in the context of the task structure that the team already understands. Its limitation is that the richness of cognitive information can become visually cluttered if the annotation density is high.

Decision ladders are a more formal representation developed within the Cognitive Systems Engineering tradition, most closely associated with Jens Rasmussen's work. A decision ladder maps the complete cycle of cognitive work involved in a task episode: from the initial observation of a system state, through information processing and diagnosis, to the identification of a goal, evaluation of response options, and execution of an action. The ladder's distinctive feature is that it explicitly represents shortcuts — the paths that experienced practitioners take by bypassing full analytical processing and jumping directly from a recognized cue to a familiar action. These shortcuts are precisely the tacit knowledge that novices lack, making them valuable targets for design support. Decision ladders are well suited to safety-critical domains and complex procedural tasks, but their formal notation requires some investment to learn and is not always immediately legible to product teams without facilitation.

Structured tables offer a pragmatic, flexible format that trades formal rigor for immediate usability. A structured CTA table might organize findings with columns for task step, cognitive demand type, information required, current interface support, gap identified, and recommended design response. This format is particularly useful during design reviews because it directly connects analysis to action and makes it easy to compare cognitive demands across steps or across different user populations (novices versus experts, for instance).

The following example illustrates a simplified structured CTA table for a subset of steps in a file-upload workflow:

Task Step	Cognitive Demand	Information Required	Current Interface Support	Gap / Risk	Design Recommendation
Select file to upload	Recall: acceptable file formats	Which formats are accepted?	None visible at point of selection	Users attempt to upload unsupported formats, receive error only after waiting	Display accepted formats adjacent to the upload button before interaction
Confirm upload is in progress	Perception: system state monitoring	Is the upload running or stalled?	Static spinner with no progress indicator	Users cannot distinguish active upload from hung process; some cancel prematurely	Add a progress bar showing percentage and elapsed time; surface a "still working" message after 15 seconds
Respond to upload failure	Diagnosis: interpret error and decide on next action	Why did it fail? What should I do next?	Generic "Upload failed" error message	Users do not know whether to retry, reformat, or contact support; high abandonment	Provide specific error cause (file too large, network timeout, wrong format) with a contextual next-step suggestion

The choice of representation format should always be guided by the audience who will use the findings. Design teams working in agile environments often respond best to annotated flows embedded directly in their existing design documentation, while structured tables work well for stakeholder presentations where the connection between research findings and design priorities must be made explicit. Formal notations like decision ladders are most valuable when handing off findings to a safety engineering team or writing formal human factors specifications.

CTA Findings in Interface Design

CTA is only as valuable as the design changes it produces. The synthesis of CTA findings into actionable design guidance follows a set of recurring patterns that connect the type of cognitive demand identified to the type of interface response appropriate to address it.

When CTA identifies a step with high cognitive load — typically a step where the user must simultaneously hold many items in working memory, evaluate multiple attributes, or apply complex rules — the design response is to reduce the choices available at that moment or provide intelligent defaults that handle the most common case automatically. Progressive disclosure is a particularly useful pattern here: rather than presenting all options at once, the interface surfaces the most common path prominently and places less frequent options behind an expandable section. This directly reduces the number of items the user must evaluate at once. Similarly, smart defaults derived from the user's prior behavior or contextual data can offload the decision entirely in routine cases, reserving the user's attentional resources for genuinely exceptional situations.

When CTA identifies a knowledge gap — a specific piece of information that users frequently lack but need to make correct decisions — the design response is some form of embedded instruction or contextual help. The key insight from CTA is that this help should be placed precisely at the moment and location where the knowledge is needed, not in a separate help system that requires the user to leave their task context. Tooltips triggered by hover or focus, inline examples within form fields, contextual sidebars that show relevant reference information as the user enters a particular workflow section — all of these represent knowledge gap responses. The difference between a CTA-informed tooltip and a generic help link is specificity: the CTA-informed tooltip addresses the exact cognitive gap identified for that step, in language that addresses the mental model the user brings to it.

When CTA identifies a high-risk decision point — a moment where users frequently choose the wrong path and where the consequences are significant and difficult to reverse — the design response includes confirmation dialogs and robust undo functionality. The design of a confirmation dialog should itself be informed by CTA: the dialog text should name the specific consequence that users underestimate, the button labels should describe outcomes rather than simply saying "OK" and "Cancel," and the default focus should be on the safer action. Undo functionality is particularly valuable because it lowers the cost of errors at decision points without requiring the user to make the correct decision the first time — it shifts the interaction model from "prevent errors" to "make errors recoverable," which is often more realistic for complex tasks.

Finally, the prioritization benefit of CTA should not be underestimated. Design resources are always constrained, and not every interface element can receive equal iterative attention. CTA findings create a defensible, evidence-based priority order: the steps where cognitive load is highest, where knowledge gaps are most consequential, and where decision errors have the most serious outcomes should receive the most design investment and the most rounds of testing. This transforms what might otherwise be a subjective debate about design priorities into a data-driven conversation grounded in observed user cognition.

NotesCovers all five subtopic areas: what CTA adds beyond HTA, the three key CTA techniques with a comparison table, decision points and mental models with gap analysis, four representation formats with a worked example table, and design implications with concrete interface response patterns.

2

Videos on This Topic

▶

Hierarchical Task Analysis tells you what users do and in what order. Cognitive Task Analysis (CTA) asks a harder question: what is going on in the user's head while they do it? CTA methods surface the knowledge, cues, judgments, and decisions that experts rely on but rarely state out loud — the things that never appear in a procedure manual yet determine whether a task succeeds or fails.

In this topic you will look at what CTA adds beyond HTA, the core techniques used to elicit expert knowledge (structured and probing interviews, critical decision method, think-aloud protocols, concept mapping), how to locate decision points and reconstruct users' mental models, and how to represent findings in forms a design team can act on — decision requirement tables, concept maps, annotated task flows. The payoff comes in the last subtopic: turning those findings into concrete interface requirements, such as what information must be visible at a decision point, what should be defaulted, and where the interface should prevent a predictable error.

The videos below do not teach CTA procedures directly; they build the two skills CTA depends on. The first two are about questioning technique — how to probe beliefs, reasoning, and assumptions without leading the person you are interviewing, which is exactly the skill a CTA interview requires. The third is about cognitive bias, which matters both because users' mental models are shaped by biases you will have to design around, and because your own biases can distort what you hear in an interview. As you watch, keep translating: when you hear a question type, ask yourself what it would reveal about a user's decision at a step in a workflow you are analyzing.

3

Video 1: This tool will help improve your critical thinking - Erick Wilberding

▶

TED-Ed · 5:20 · 8,378,956 views · 5y ago · captions — Watch on YouTube

4

Video 2: Socratic Questioning Examples in Cognitive Behavioural Therapy (CBT)

▶

Teresa Lewis | Lewis Psychology · 5:44 · 69,173 views · 4y ago · captions — Watch on YouTube

5

Video 3: Introduction to Cognitive Bias: Crash Course Scientific Thinking #1

▶

CrashCourse · 11:49 · 1,193,558 views · 8mo ago · captions — Watch on YouTube

6

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Comparing and Selecting Analysis Methods

1

Comparing and Selecting Analysis Methods

▶

Every task analysis effort begins with a methodological choice, and that choice carries real consequences for the quality, depth, and utility of the information you gather. Hierarchical Task Analysis (HTA) and Cognitive Task Analysis (CTA) are not competing methods that one replaces the other — they are complementary tools built to answer different kinds of design questions. Understanding what each method does well, where each falls short, and how to scope your analysis before you begin are the skills that separate a productive task analysis from one that produces pages of documentation but little actionable insight. This topic develops each of those considerations in depth so you can approach method selection as a deliberate, reasoned decision rather than a habit or default.

Strengths and Limitations of HTA

Hierarchical Task Analysis organises work into a structured tree of goals, sub-goals, and operations, governed by plans that specify how and when sub-goals are executed. Its most immediate practical virtue is that this structure is visual and highly communicable. A well-drawn HTA diagram can be placed in front of a stakeholder, a developer, or a content designer with no prior training in task analysis and they will understand — at least in broad terms — what users are trying to accomplish and in what sequence. This makes HTA an unusually effective tool for aligning cross-functional teams early in a design project, when shared vocabulary and shared mental models of the task domain matter enormously.

HTA is also relatively fast to produce when the task under analysis is procedural and well-defined. Consider a task like submitting an expense report through a corporate finance system. The steps have a recognisable sequence, the inputs and outputs are concrete, and most users perform the task in broadly the same way. An experienced analyst can conduct a small number of observations and brief interviews, then produce a usable HTA within a day or two. That speed has real value in projects operating under time pressure, and it means the team can move quickly from analysis to design exploration.

However, HTA's clarity comes at a price. The method captures what people do and in what order, but it does not capture why they do it that way, what they are thinking while they do it, or what knowledge they are drawing on to make decisions. Consider the difference between two users submitting that same expense report. A new employee follows each step literally, unsure why certain fields are mandatory or what happens if they make an error. An experienced employee recognises immediately that a particular field requires a cost centre code they have memorised, skips a confirmation screen they know is irrelevant for domestic travel, and catches a common system error before it occurs. An HTA of both users might look almost identical, masking a significant difference in cognitive demand and error risk. This is not a flaw that can be patched — it is structural. HTA was designed to represent task structure, not cognitive process.

A related limitation is that HTA can oversimplify tasks that vary with experience. Novice and expert users often do not perform tasks in the same sequence, with the same granularity of attention, or with the same recovery strategies when something goes wrong. An HTA built primarily from observation of expert users may produce a decomposition that looks clean and logical but bears little resemblance to the struggle a new user encounters. Conversely, an HTA built from novice observation may include steps that experts have long since automated and no longer consciously execute. Neither version is wrong, but a single HTA without qualification about which user population it represents can mislead design decisions.

Strengths and Limitations of CTA

Cognitive Task Analysis addresses the gap that HTA leaves open. Its defining purpose is to surface the mental processes that drive task performance — the perceptual cues users attend to, the knowledge structures they consult, the judgements they make under uncertainty, and the mental models they apply when the system behaves unexpectedly. These are precisely the things that experienced users struggle to articulate unprompted, because expertise involves the progressive automation of knowledge that was once effortful and conscious. A senior intensive care nurse monitoring a patient's vital signs is not running through a checklist — she is pattern-matching against a rich mental model built from hundreds of clinical encounters. CTA methods such as the Critical Decision Method, Think-Aloud Protocol, and knowledge elicitation interviews are designed to excavate that tacit knowledge and make it available for design purposes.

The practical payoff is that CTA produces data that directly informs decisions about feedback, guidance, and error handling — the parts of interface design that novice users depend on most and that are most often underspecified. If a CTA reveals that users make a particular class of decision by attending to three specific data points on the screen, a designer can ensure those data points are visually prioritised and co-located. If a CTA reveals that users commonly misinterpret a system state during a high-stakes operation, the design team has the specific cognitive mechanism of that misinterpretation and can engineer a more effective feedback signal. This kind of actionable, mechanism-level insight is what distinguishes CTA outputs from more surface-level analysis.

The costs, however, are significant. CTA is more time-consuming than HTA at every stage. Data collection through methods like the Critical Decision Method requires skilled facilitation — the interviewer must probe without leading, pursue productive tangents without losing the thread of the interview, and recognise when a participant's account of events contains an implicit cognitive decision that warrants a follow-up question. These skills are not trivial. An inexperienced researcher conducting a CTA-style interview will often obtain a narrative of events that looks superficially rich but contains almost no genuine cognitive content — essentially a verbal version of an observable task sequence.

Analysis of CTA data is equally demanding. Unlike an HTA diagram, which has a well-established representational convention, CTA data can be represented in multiple formats — knowledge audit tables, decision requirement tables, critical cue inventories, cognitive demands tables — and none of these formats has the intuitive legibility of a hierarchical diagram. Without a clear analytical framework applied consistently across the dataset, CTA outputs can become a large, unstructured collection of observations and quotes that is difficult to translate into specific design recommendations. Investing in CTA without investing in the analytical infrastructure to process its outputs is a common and costly mistake.

A structured comparison of the two methods

Dimension	HTA	CTA
Primary focus	Observable task structure and sequence	Cognitive processes, knowledge, and decision-making
Output format	Hierarchical diagram with plans	Tables, decision trees, knowledge maps (varies by method)
Stakeholder accessibility	High — visual and self-explanatory	Lower — requires interpretation and framing
Data collection time	Relatively short for well-defined tasks	Substantially longer; requires multiple sessions
Researcher skill required	Moderate	High — trained facilitation essential
Captures expert-novice differences	Poorly	Well
Informs feedback and error handling	Indirectly	Directly
Best suited to	Procedural, sequential, well-defined tasks	Judgement-heavy, knowledge-intensive, or safety-critical tasks

Choosing the Right Method

The most reliable way to choose between HTA and CTA — or to decide whether to use both — is to begin by articulating the primary design question the analysis needs to answer. This question is more specific than "what do users do?". It might be: "How should the navigation of this onboarding flow be structured so that users can complete registration without abandoning?" That is a question about task structure, sequence, and navigation — precisely what HTA is built to answer. Alternatively, the question might be: "Why do experienced operators sometimes fail to recognise an impending system alarm in time to intervene?" That is a question about perception, mental models, and situation awareness — precisely what CTA is built to answer.

A useful heuristic is to reach for HTA when the design problem is primarily structural — when you need to understand and document what steps the system must support, in what order, and with what options for alternative paths. User onboarding flows, checkout processes, form-based data entry workflows, and administrative dashboard navigation are all areas where HTA tends to deliver the greatest return on analytical investment. The outputs translate directly into information architecture decisions, navigation design, and content sequencing.

Reach for CTA when the design problem is primarily cognitive — when users must make judgements, interpret ambiguous information, apply specialised knowledge, or manage cognitive load under time pressure. Clinical decision support systems, financial analysis tools, emergency response interfaces, complex configuration systems, and any domain involving significant expertise are strong candidates for CTA. When the cost of user error is high or when the gap between novice and expert performance is large, CTA data provides the depth of understanding necessary to design interventions that actually reduce error risk.

In many real projects, the most comprehensive and defensible analysis combines both methods. A common and effective sequence is to begin with HTA to establish the structural skeleton of the task domain — what goals exist, how they decompose, what the procedural sequence looks like. This structural map then identifies the sub-tasks that carry the greatest cognitive demand, ambiguity, or error risk. CTA is then applied selectively to those high-priority nodes, providing the cognitive depth where it is most needed without incurring the full cost of a CTA across the entire task domain. This combined approach produces documentation that satisfies stakeholders who need structural clarity (the HTA layer) and designers who need cognitive mechanism detail (the CTA layer).

It is also important to recognise that time and resource constraints are legitimate factors in method selection, and that pretending otherwise leads to analysis projects that are either abandoned before completion or completed superficially. A thorough CTA of a complex medical device interface might require eight to twelve weeks of data collection and analysis with two trained researchers. If the project timeline does not accommodate that investment, the right response is not to conduct a rushed and under-resourced CTA — it is to conduct a well-scoped HTA that honestly documents the cognitive questions it was unable to address, and to flag those questions as risks that warrant attention in usability testing. Method selection decisions, including the constraints that shaped them, should be documented in the analysis deliverable so that future design teams understand what the analysis covers and what it does not.

Scoping a Task Analysis

Before any task decomposition begins — whether using HTA, CTA, or a combination — the analysis must be scoped. Scoping is the process of defining the boundaries, user population, and goals that will govern what gets included in the analysis and what gets set aside. Without deliberate scoping, task analysis efforts expand organically until they are either unmanageable or so broad and shallow that their outputs cannot support specific design decisions. A well-scoped analysis with a narrow, clearly defined focus will almost always produce more actionable results than a broad but underspecified one.

The first scoping decision is to define the primary user group. User groups are not monolithic. Within any user population there are differences in experience level, domain knowledge, frequency of system use, physical context of use, and personal working style. Each of these differences can produce meaningfully different task behaviour. Before decomposing tasks, the analyst must specify which user group the analysis is targeting. This does not mean other groups are irrelevant — it means they are documented as explicit out-of-scope populations or as secondary populations to be addressed in a subsequent analysis phase. A task analysis that tries to represent all users simultaneously often ends up representing none of them accurately. The choice of primary user group should be driven by the design question: who are you most trying to support, and whose task behaviour will most directly shape the design decisions you face?

The second scoping decision is to specify the system boundaries — the definition of what interactions fall within the scope of the analysis and what falls outside it. In most digital product contexts, users do not interact only with the system under design. They consult external resources, communicate with colleagues, use other software tools, and navigate organisational processes that exist entirely outside the interface. A task analysis that attempts to capture all of this context simultaneously becomes unwieldy. The analyst must draw a boundary: for example, "This analysis covers the interactions a user performs within the invoice management module, from logging in to submitting an approved invoice for payment. It does not cover the approval workflow that occurs in the organisation's separate finance system, nor the email communications users may engage in outside the platform." That boundary statement is not a claim that the out-of-scope items are unimportant — it is a clarification of what this analysis is responsible for documenting.

The third scoping discipline is to document the assumptions made during scoping explicitly and systematically. Every scoping decision rests on assumptions about users, context, and system behaviour. For example: "We assume that the primary user group has at least six months of experience with the legacy system and is therefore familiar with core domain concepts, even if they are new to this interface." That assumption, if left undocumented, becomes invisible. Future team members inheriting the analysis may apply its findings to onboarding entirely new users — a population for whom the assumption is false and the analysis is potentially misleading. Documented assumptions serve as a map of the analysis's limits. They signal where the findings apply with confidence and where they should be treated with caution.

Assumptions worth documenting typically include: the experience level and technical fluency of the primary user group; the devices, environments, and access conditions under which tasks are performed; the frequency and criticality of the tasks under analysis; and any dependencies on external systems, processes, or information sources that the analysis takes as given. When the design context changes — when the user group shifts, when the system is extended into a new domain, or when the deployment environment changes — these documented assumptions make it straightforward to identify which parts of the analysis need to be revisited and which remain valid.

Together, these scoping disciplines — defining the user group, specifying system boundaries, and documenting assumptions — transform a task analysis from a vague documentation exercise into a precise analytical instrument. The resulting analysis is not just easier to produce; it is easier to use, easier to maintain, and easier to defend when its findings are challenged. A scoped analysis with clear boundaries produces outputs that tell a specific design team what they need to know about a specific user population performing specific tasks in a specific context. That specificity is what makes a task analysis genuinely useful rather than merely thorough.

NotesConsider pairing this topic with a worked example in which students receive a brief design brief and must justify in writing which method they would select and how they would scope the analysis — including the assumptions they are making. This reinforces the decision-making process rather than just the declarative content.

2

Videos on This Topic

▶

By this point in the module you have seen two ways of describing what users do: hierarchical task analysis (HTA), which decomposes observable goals into subgoals, operations, and plans, and cognitive task analysis (CTA), which digs into the knowledge, judgments, and decisions behind expert performance. Neither method is universally better. HTA is efficient, easy to diagram, and excellent for procedural, well-structured work, but it can flatten the reasoning behind a step. CTA surfaces mental models, cues, and decision strategies, but it is interview-intensive, depends on access to experts, and produces findings that are harder to standardize.

Choosing between them (or combining them) is a scoping decision. Before you pick a method you need to settle what question you are answering, who your users are, how much access and time you have, and how deep the analysis needs to go. A narrow scope with a clear boundary (one workflow, one user role, one goal) usually produces more usable design implications than an ambitious analysis that is never finished. The same discipline applies to any research method you will use later in the course.

The videos below place task analysis in the wider landscape of UX research methods, so you can see how method selection is reasoned about in practice: matching a method to an objective, a budget, and a timeline. As you watch, keep translating the general advice into your own decision — which method would you use for your project workflow, what would you have to give up, and how would you know the analysis is deep enough to stop? The third video shows a specific task-based inspection technique that pairs naturally with the task models you are building.

3

Video 1: UX Research Methods: The Basics You Need to Get Started

▶

UX in the Head · 11:26 · 35,698 views · 3y ago · captions — Watch on YouTube

About this video

An introductory tour of the UX research methods practitioners use most often, with a few less common ones included for context. Expect coverage of how methods differ along familiar dimensions such as qualitative versus quantitative and attitudinal versus behavioral, and when each type of study is appropriate.

Why this video

It gives you the vocabulary and the comparison framework you need to position HTA and CTA against other ways of learning about users, which is the core skill in this topic.

4

Video 2: 9 UX research methods you should know | Maze

▶

Maze · 12:48 · 18,494 views · 3y ago · captions — Watch on YouTube

About this video

Maze walks through nine research methods and, importantly, frames the discussion around selection: fitting a method to your research objectives, budget, team, and timeline. The format is method-by-method, so you can compare what each one costs you and what it gives back.

Why this video

The video's explicit focus on constraint-driven method selection maps directly onto "Choosing the Right Method" and "Scoping a Task Analysis," where effort and access often decide between HTA and CTA.

5

Video 3: Cognitive Walkthroughs Help Assess Interface Learnability

▶

NNgroup · 4:45 · 14,522 views · 3y ago · captions — Watch on YouTube

About this video

Nielsen Norman Group explains the cognitive walkthrough, a task-based usability inspection technique used to evaluate how learnable an interface is for first-time users. The short format covers what the technique is and how evaluators step through tasks asking questions from the user's point of view.

Why this video

NNgroup is an authoritative source, and the cognitive walkthrough shows how a structured task breakdown feeds a cognitively oriented evaluation, illustrating the practical boundary between HTA-style decomposition and CTA-style reasoning about users.

6

How These Videos Support the Learning Outcomes

▶

The first two videos build the comparative judgment that MO1 depends on: knowing the steps of HTA and CTA matters only if you can say which one answers your question and at what cost. The selection criteria they present (objectives, access, budget, timeline) give you a concrete way to scope the workflow you analyze for MO2, so your hierarchical diagram stays bounded and finishable. The NNgroup walkthrough video supports MO3 by demonstrating how a task-by-task examination of an interface exposes learnability problems and points toward specific design implications and requirements.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Data Collection for Task Analysis

1

Data Collection for Task Analysis

▶

Task analysis is only as accurate and useful as the data that feeds it. Before a designer or analyst can break down a task into its component steps, identify cognitive demands, or spot points of friction in a workflow, they need a solid foundation of empirical evidence about how real users actually perform those tasks. That evidence comes from a deliberate, structured process of data collection — one that combines direct observation, verbal protocols, existing documentation, and careful participant selection. Each method captures a different dimension of user behavior, and together they build a picture that is far richer and more reliable than any single source could provide on its own.

Understanding why multiple collection methods are necessary requires appreciating a fundamental gap in human self-knowledge: people are remarkably poor at accurately describing their own behavior. Users frequently report doing things in a logical, orderly sequence, when observation reveals that their actual process is iterative, fragmented by interruptions, and full of workarounds they have long since stopped noticing. The purpose of data collection for task analysis is therefore not simply to record what users say they do, but to triangulate across sources until a truthful, nuanced account of task performance emerges.

Observation Methods

Observation is the most direct route to understanding real-world task performance because it captures behavior as it actually unfolds, rather than as it is remembered or idealized after the fact. When a participant explains a task in an interview, they are constructing a narrative — one that is shaped by what they believe the interviewer wants to hear, what they think is relevant, and the natural tendency of memory to smooth over complexity and error. Observation bypasses these distortions by placing the analyst in the same space and time as the task itself.

The most valuable form of observation for task analysis is contextual observation, sometimes called contextual inquiry when combined with interviewing. Rather than asking users to perform tasks in a controlled lab, the analyst observes them in their actual working environment — at their workstation, in the warehouse, on the shop floor, or wherever the task genuinely occurs. This context matters enormously. A data-entry clerk who works in an open-plan office contends with verbal interruptions every few minutes; a nurse updating patient records must constantly switch attention between a screen and a patient; a warehouse picker references a handheld scanner while managing a physical cart and navigating narrow aisles. None of these environmental factors will appear in a laboratory observation, yet all of them shape the task's cognitive and procedural demands. Contextual observation surfaces these factors organically because the analyst is present when they happen.

Field notes are the primary record of an observation session. Effective field notes go beyond a simple log of actions; they capture the sequence of steps, the duration of pauses, moments of hesitation or backtracking, tools and artifacts the user references, and any verbal utterances or expressions of frustration. Crucially, good field notes distinguish between direct observation — what was literally seen or heard — and inference or interpretation, which should be flagged clearly and revisited later. An analyst who writes "User seemed confused by the error message" is already interpreting; a more rigorous note would record the exact error message that appeared, the user's verbatim reaction, and the subsequent actions taken, leaving interpretation for the analysis phase.

Screen recordings are an invaluable complement to field notes for any task that involves a digital interface. They provide a frame-by-frame record that no human observer can match: every click, scroll, typed character, and navigation path is captured for later review. When combined with audio — either from a microphone or a think-aloud protocol — screen recordings allow analysts to replay specific moments, measure precise durations, and notice micro-behaviors (such as a user hovering over a button before clicking elsewhere) that are easy to miss in real time. Modern screen-capture tools can also record mouse paths and dwell times, adding another layer of behavioral data.

The observer's role during a session requires careful calibration. The goal is to be a fly on the wall — present enough to capture rich data, but unobtrusive enough that the user's behavior remains natural. This is more difficult than it sounds. The mere presence of an observer changes behavior (a phenomenon known as the Hawthorne effect), and any action the observer takes — leaning in, asking a question, reacting visibly — can interrupt the user's task flow or signal that a particular behavior was noteworthy, prompting the user to alter subsequent actions. Good observers develop a practiced neutrality: they make brief, non-evaluative acknowledgments ("mm-hmm," "okay") that keep the session going without influencing it. They resist the urge to help when the user struggles, because struggle is often the most analytically valuable moment in the entire session — it reveals where the design fails to support the mental model users bring to the task.

Observers must also remain alert to unexpected behaviors: things users do that were not anticipated by the analysis plan. A user who opens a second browser tab mid-task to cross-reference a previous order, or who writes a step down on paper before executing it in the software, is revealing something important about the task's cognitive demands and the gaps in the tool's support for them. These unplanned moments often yield the most actionable insights.

Interview and Protocol Methods

While observation reveals what users do, it does not always explain why they do it. The reasoning behind a choice — why a user navigated to a particular screen before completing a form, why they preferred one confirmation path over another, why they paused before submitting — is largely invisible to an observer. Interview and verbal protocol methods are designed to make that reasoning explicit.

The think-aloud protocol is one of the most widely used techniques in usability and task analysis research. Participants are asked to verbalize their thoughts continuously as they perform a task: what they are looking at, what they are trying to do, what they expect to happen, and what they make of what they see. This running commentary, when recorded and transcribed, provides a real-time window into the user's cognitive process — their mental model of the system, the cues they use to orient themselves, the points at which their expectations are violated, and the strategies they adopt when things go wrong.

Think-aloud data is particularly valuable for identifying invisible steps in a task: cognitive operations such as deciding, comparing, recalling, or checking that leave no visible trace in the interaction log. A user who silently scans a table of results before clicking is performing a significant cognitive task — evaluating options against criteria, filtering by some internal heuristic — that would be invisible to observation alone but surfaces clearly in a think-aloud protocol as "Okay, I'm looking for the most recent one... this one says June, this one says July... I'll use the July record."

Think-aloud protocols do, however, have limitations. Verbalizing thoughts is cognitively demanding, and for tasks that are themselves cognitively demanding, the added load of narration can alter performance — slowing the user down, prompting more deliberate and less automatic behavior, or occasionally causing them to abandon a natural strategy in favor of one that is easier to articulate. Participants also vary in their willingness and ability to verbalize fluently. Some require regular prompting ("keep talking, tell me what you're thinking"), while others produce a rich, unprompted narration. These variations need to be accounted for during analysis.

Retrospective interviews address the think-aloud limitation by separating the task performance from the verbal account of it. The user first completes the task — without any narration requirement — and then, immediately afterward, is asked to walk through what they did and why. Retrospective interviews can be conducted with or without a replay of the session recording; replaying the recording (sometimes called stimulated recall) is particularly effective because it allows the user to comment on specific moments in their actual session rather than reconstructing the task from memory alone.

The quality of interview data depends heavily on question design. A well-constructed interview guide uses a progression that moves from broad, open-ended prompts toward more specific probes, following the participant's own account rather than imposing a predetermined structure. The most productive interview questions for task analysis focus on four dimensions: what the user noticed (perceptual cues), what they considered (the options or factors they weighed), what they decided (the choice made and why), and what they expected to happen as a result. Questions that focus only on actions — "And then what did you do?" — reproduce the sequence of steps but miss the cognitive architecture beneath them.

Probing questions are particularly important when a user's account is vague or incomplete. If a participant says "I just knew to go there," a skilled interviewer probes: "What made you go there rather than somewhere else?" or "What were you looking for when you arrived at that screen?" These probes should feel genuinely curious rather than challenging; the goal is to help the participant articulate tacit knowledge that they have automated through experience and no longer consciously notice.

Structured interview guides — a consistent set of core questions administered to all participants — serve a dual function. They ensure that the same analytical territory is covered across multiple sessions, making it possible to compare responses and identify patterns. They also provide a quality control mechanism: a well-designed guide prevents the interviewer from inadvertently spending more time on some topics with some participants than with others, introducing a systematic bias into the dataset. The guide should be treated as a scaffold, not a script — interviewers must remain flexible enough to pursue unexpected threads — but the core questions should be asked of every participant in a comparable form.

Using Existing Documentation

Before conducting a single observation or interview, analysts can accelerate the task analysis process by mining existing organizational documentation. This includes standard operating procedures, training manuals, job aids, workflow diagrams, process maps, system specifications, and any other materials that describe how tasks are supposed to be performed. This documentation does not capture how tasks are performed — that distinction is critical — but it provides a structured starting point: a first draft of the task model that can then be tested and refined through empirical methods.

One of the most revealing categories of existing documentation is support and help desk records. Support logs, trouble tickets, and frequently asked questions represent a distilled record of where users struggle: the steps they get stuck on, the error messages they cannot interpret, the functions they cannot find, and the outcomes they cannot achieve. Unlike designed documentation (which describes the intended workflow), support records describe the actual breakdown points — the places where the gap between intended design and real-world use is wide enough that users seek outside help. Patterns in support logs can efficiently direct an analyst's attention to the most problematic parts of a task before any observation session is conducted.

Workflow diagrams produced by subject matter experts (SMEs) — people with deep domain knowledge, such as experienced employees, trainers, or process engineers — offer another valuable perspective. SMEs have typically developed a sophisticated, internalized model of how a task works, and their diagrams capture procedural logic, decision points, conditional branches, and domain-specific terminology that general documentation may omit. A process diagram drawn by an experienced accounts-payable clerk will include contextual rules ("if the invoice is over $10,000, it requires a second approval") and exception handling ("if the vendor code doesn't appear in the system, check the legacy database") that reflect actual practice far more accurately than a generic procedure manual.

However, documentation-derived task models carry a significant risk: they reflect the perspective of whoever produced them, which may be a designer, a manager, a trainer, or a policy writer — not necessarily the end user. Standard operating procedures describe the intended process; they do not account for the informal workarounds, adaptive strategies, and situational judgments that characterize real task performance. Every step or decision point derived from existing documentation must therefore be explicitly validated through direct observation or user interviews before it is incorporated into the final task analysis. Treating documentation as ground truth, rather than as a hypothesis to be tested, is one of the most common and consequential errors in task analysis practice.

Participant Selection

The validity of any task analysis depends not only on the methods used to collect data but on the participants from whom that data is collected. Selecting the wrong participants — users who are not representative of the intended user population, or who perform the task under conditions that differ from real-world use — can produce a task model that is technically rigorous but practically misleading.

The foundational principle of participant selection is alignment with the target user group defined in the analysis scope. If the analysis concerns a warehouse management system used by receiving clerks with no formal IT training, the participants must be receiving clerks with no formal IT training — not warehouse managers, not IT administrators, and not analysts who happen to be familiar with the system. Each of these other groups brings a different knowledge base, a different set of expectations, and a different set of task demands that will produce a systematically different picture of the task.

Expertise level is a particularly important dimension of participant selection when the interface must serve a range of users. Novice users and experienced users perform the same task differently in ways that are analytically significant. Novices rely more heavily on surface cues (labels, icons, and visual affordances) and are more vulnerable to interface ambiguity; experienced users have developed internalized shortcuts and may barely notice the interface at all, navigating by habit. If a system must serve both groups, collecting data from only one group will produce a task model that is systematically incomplete. Including participants from both ends of the expertise spectrum — and potentially intermediate users as well — ensures that the analysis captures the full range of task strategies and support needs that the design must accommodate.

A common misconception is that larger participant samples always produce better data. In qualitative task analysis, the reverse is often true: a small number of carefully selected, representative participants yields more actionable and analytically coherent data than a large sample drawn without regard for representativeness. Research in usability testing has repeatedly demonstrated that a handful of well-chosen participants will surface the majority of significant usability issues; adding more participants from the same population produces rapidly diminishing returns. The priority should be on quality of selection — genuine representativeness — rather than on quantity.

Documenting participant characteristics is not merely a methodological formality; it is an analytical resource that supports every subsequent phase of the design process. A participant log that records relevant attributes — role, tenure, frequency of task performance, level of formal training, primary technology used, and any other characteristics relevant to the task — allows analysts to identify whether patterns in the data are associated with specific participant profiles. It also enables later project reviewers and stakeholders to evaluate the credibility of the analysis: findings that are well grounded in a clearly described, representative participant group carry more evidential weight than findings from an undocumented or convenience sample.

The following table summarizes the four major data collection methods for task analysis, including their primary strengths, limitations, and the types of data each method is best positioned to capture:

Method	Primary Strengths	Key Limitations	Best For Capturing
Contextual Observation	Reveals actual behavior; captures environmental factors and interruptions; uncovers workarounds	Observer effect may alter behavior; reasoning behind actions remains invisible	Action sequences, environmental influences, unplanned behaviors, tool use
Think-Aloud Protocol	Exposes real-time reasoning and mental models; identifies cognitive steps invisible to observation	Verbalization adds cognitive load; may alter natural task performance; varies by participant	Decision logic, expectation violations, evaluation criteria, error recovery strategies
Retrospective Interview	Does not interfere with task performance; stimulated recall using recordings improves accuracy	Memory decay; participants reconstruct rather than recall; may rationalize post-hoc	Reasoning about specific decisions, user goals, satisfaction or frustration with outcomes
Existing Documentation	Rapid first draft of task structure; surfaces common failure points via support logs; captures domain knowledge from SMEs	Describes intended, not actual, process; may reflect designer or manager perspective rather than user experience	Procedural scaffolding, conditional logic, exception handling, organizational policy

In practice, robust task analysis draws on all of these methods in a deliberate sequence: existing documentation is reviewed first to build a preliminary task model and focus observation efforts; contextual observations are conducted to capture actual behavior in the real environment; think-aloud or retrospective protocols are used to surface the reasoning behind observed actions; and participant selection is managed throughout to ensure that the resulting task model reflects the full range of the target user population. Each method compensates for the blind spots of the others, and the convergence of evidence across methods is what gives the final task analysis its credibility and practical value.

NotesCovers all four subtopic clusters (Observation Methods, Interview and Protocol Methods, Using Existing Documentation, Participant Selection) in depth with explanations, examples, and a summary comparison table. No headings used per formatting rules — topic transitions are handled via bold lead-in sentences.

2

Videos on This Topic

▶

Task analysis is only as good as the data behind it. Before you can diagram a workflow or identify where users struggle, you need an accurate record of what people actually do, in what order, with what information, and what they are thinking while they do it. This topic covers the main ways that raw data is gathered: observing users in their real context, interviewing them and collecting verbal protocols such as think-aloud, mining documentation that already exists (manuals, training materials, logs, help tickets, procedures), and choosing participants who genuinely represent the target user population.

Each method has trade-offs. Observation captures what people do but not always why; interviews capture intent and rationale but are filtered through memory and self-presentation; existing documentation describes how a task is supposed to be done, which often differs from how it is really done. Skilled practitioners combine methods and treat disagreements between them as findings rather than noise. Participant selection matters just as much: data from the wrong users produces a clean, well-structured, and wrong task analysis.

The three videos below come from Nielsen Norman Group and focus on the verbal-protocol and moderation side of data collection. As you watch, pay attention to how a moderator elicits information without putting words in the participant's mouth, what a repeatable session procedure looks like, and when thinking aloud distorts the very behavior you are trying to record. Then consider how the data you collect this way would feed into the hierarchical and cognitive task analyses you build later in the module.

3

Video 1: Help Users Think Aloud

▶

NNgroup · 3:42 · 18,210 views · 3y ago · captions — Watch on YouTube

About this video

A short practitioner video on the think-aloud protocol: what it is, why researchers ask participants to verbalize their thoughts, and how to get users to keep talking during a session. Based on the title and description, it covers explaining the technique to participants up front, reinforcing the behavior when they do it well, and using neutral prompts to restart narration when a participant goes quiet.

Why this video

Think-aloud is the core verbal protocol method used to surface the cognitive steps of a task, and this video addresses the practical skill of eliciting it without leading the user. NN/g is a long-established usability research group, so the guidance reflects standard professional practice.

4

Video 2: Checklist for Moderating a User Test

▶

NNgroup · 4:29 · 7,896 views · 3y ago · captions — Watch on YouTube

About this video

A checklist-style walkthrough of roughly ten things a moderator should do when running a usability study. It is likely to cover session setup, briefing the participant, giving tasks, staying neutral while observing, and wrapping up, framed as a repeatable procedure that protects the quality of the insights you collect.

Why this video

It treats data collection as a disciplined protocol rather than an informal chat, which is exactly the standard your own observation and interview sessions should meet. The checklist format makes it easy to reuse when you plan and run your own sessions for the module project.

5

Video 3: When Thinking Aloud Fails

▶

NNgroup · 3:46 · 3,970 views · 3y ago · captions — Watch on YouTube

About this video

A counterpoint video on the limits of the think-aloud method, including situations where verbalizing interferes with the task or where participants cannot articulate what they are doing. The description points toward expert users as a case where other approaches work better than standard think-aloud usability testing.

Why this video

Knowing when a method fails is part of choosing methods well, and this video connects directly to participant selection, since the right technique depends on who your users are. It balances the first video so you do not treat think-aloud as a universal solution.

6

How These Videos Support the Learning Outcomes

▶

These videos supply the data-gathering foundation the module's outcomes depend on. Think-aloud and moderated observation are the primary way analysts capture the mental steps, decisions, and information needs that cognitive task analysis represents, and they also reveal the ordered subtask structure you will decompose in a hierarchical task analysis (MO1, MO2). The moderation checklist helps you run sessions consistently enough that the resulting workflow diagram reflects real user behavior rather than your assumptions (MO2). The video on when thinking aloud fails pushes you to judge method fit and participant type, which in turn sharpens your ability to read the collected data for genuine bottlenecks, workarounds, and interface requirements instead of artifacts of a poorly chosen method (MO3).

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Producing Task Analysis Documentation

1

Producing Task Analysis Documentation

▶

Producing a task analysis document is more than simply writing down a list of steps a user performs. It is the act of translating raw observational and interview data into a structured, verifiable, and design-ready artefact that a whole project team can read, critique, and act upon. A well-produced task analysis document serves as the authoritative record of what users actually do, why they do it, and what cognitive demands those actions place on them. When this document is thorough, it becomes the single source of truth that connects user research to every subsequent design decision. When it is vague or incomplete, it leaves designers guessing, leading to interfaces that solve the wrong problems or miss critical user needs entirely.

Understanding how to produce this document means understanding both its structural components and the quality standards that make each component genuinely useful. The sections below work through the major elements of a complete task analysis document, the craft of writing clear task descriptions, methods for validating the document's accuracy, strategies for linking the analysis to concrete design artefacts, and the specific requirements that apply to group project submissions.

Components of a Task Analysis Document

A complete task analysis document is made up of four interdependent components. Each plays a distinct role, and each depends on the others to carry its full meaning. Treating any one component as optional produces a document that is harder to validate, harder to act upon, and harder to justify to stakeholders.

The first and foundational component is the scope statement. Before a single task step is written down, the document must define who is being studied, what they are trying to achieve, and what is and is not covered by the analysis. A scope statement typically answers three questions explicitly: Who is the user group? What are their primary goals in the context being studied? And what are the boundaries of the analysis — that is, where does the task begin and where does it end?

For example, a scope statement for an analysis of an online pharmacy system might read: "This analysis covers registered adult patients aged 18 and over who use the pharmacy's web portal to request repeat prescriptions. The analysis begins when the user logs into the portal and ends when the system confirms the prescription request has been submitted. Ordering new (non-repeat) medications and managing account billing details are outside the scope of this analysis." This level of precision prevents scope creep during the analysis itself, keeps peer reviewers focused on the right tasks, and ensures that design recommendations do not stray into areas the research did not cover.

The second component is the task diagram. A Hierarchical Task Analysis (HTA) produces a hierarchical decomposition of goals into sub-goals and operations. Representing that decomposition visually — as a tree or indented outline with numbered nodes — makes the structure navigable in a way that a plain list of steps cannot. A reader scanning a task diagram can immediately see the overall shape of the task, which sub-goals belong together, and how deep the decomposition goes. Diagrams also make it obvious when one branch of the hierarchy is much more elaborately decomposed than another, which may indicate either genuine complexity in that area or an inconsistency in how thoroughly the analysis was conducted.

A typical HTA diagram uses a numbering convention such as the one shown below, where the goal is numbered 0 and each level of decomposition adds a digit:

0. Request a repeat prescription
   1. Log in to the portal
      1.1 Enter username
      1.2 Enter password
      1.3 Select 'Sign In'
   2. Locate the repeat prescription section
      2.1 Navigate to 'My Medications'
      2.2 Select 'Request Repeat'
   3. Select medications to reorder
      3.1 Review the list of eligible medications
      3.2 Check the box next to each required medication
   4. Confirm and submit the request
      4.1 Review the selected items
      4.2 Select 'Submit Request'
      4.3 Note the confirmation reference number

This structure, rendered graphically as a tree in the full document, allows any reader to navigate from the top-level goal down to individual atomic operations. It also provides the anchor points to which plans and annotations are attached.

The third component is plans and cognitive annotations. Plans in HTA describe the conditions under which sub-tasks are performed and in what order. They answer questions like: Are these steps always done in sequence? Are some steps only performed under certain conditions? Can any steps be skipped? A plan for node 3 in the example above might state: "Plan 3: If there is only one medication to reorder, perform 3.1 and 3.2 once. If multiple medications are required, perform 3.1, then repeat 3.2 for each medication before proceeding." Plans make the logic of task execution explicit and allow designers to anticipate branching scenarios.

Cognitive annotations go further by documenting the mental demands placed on the user at specific steps. Drawing on Cognitive Task Analysis (CTA) techniques, annotations might note that a step requires the user to hold information in working memory, make a decision under uncertainty, or apply a rule they may have learned only recently. For example, the annotation on step 4.1 might read: "Users must compare the selected list against their current medication regime from memory. If the list is long, this creates a significant working memory load and increases the likelihood of omission errors." This kind of annotation is what separates a superficial list of steps from a document that genuinely informs interface design.

The fourth component is the design implications section. This section is the bridge between analysis and action. It takes the findings from the task diagram, plans, and cognitive annotations and translates them into specific, actionable recommendations for the interface. A design implication is not a vague suggestion like "make it easier." It is a traceable recommendation tied to a specific task analysis finding. For example: "Step 4.1 places high working memory demand on users who have multiple medications. Design implication: Display a persistent summary panel listing all currently selected medications alongside the confirmation screen, so users can verify their selection without relying on recall." This specificity allows the design team to prioritise features, justify decisions to stakeholders, and revisit recommendations if requirements change.

Writing Clear Task Descriptions

The quality of a task analysis document depends heavily on the quality of the individual task descriptions that make up each node of the hierarchy. Poorly written descriptions introduce ambiguity, make validation difficult, and cause inconsistency when different team members write different sections. Four principles govern the writing of clear task descriptions.

First, every task description should begin with an observable action verb. Verbs like select, enter, confirm, review, navigate, check, scroll, and submit describe behaviours that can be directly observed or inferred from user actions. They are testable: a validator watching a user perform the task can tick off whether the action occurred. Contrast these with vague verbs like manage, handle, or deal with, which describe outcomes or responsibilities rather than specific actions. The step "manage the medication list" cannot be validated because it does not specify what the user actually does. The step "check the box next to each required medication" is specific and observable.

Second, descriptions must specify what the user acts upon, not just what they do in the abstract. Knowing that a user "enters information" is not sufficient. The description should state what information, into what field, and from what source if relevant. "Enter the six-digit one-time password received by SMS into the verification field" is a complete description. "Enter the code" is not. The object of the action — the interface element, the data item, the decision — must be named explicitly. This specificity also makes it possible to map task descriptions directly to interface elements during the design phase.

Third, task descriptions should avoid technical jargon that the user may not recognise. This is particularly important when the task domain involves specialised terminology. If the user group is general members of the public rather than trained professionals, descriptions should use the language those users would naturally use. Writing "the user authenticates via the OAuth2 token exchange" is appropriate for a technical specification but not for a task analysis that represents user experience. The equivalent user-facing description might be "the user signs in using their email address and the password they created when registering." Using user language also helps during validation: when you walk a real user through the documented steps, the language will match how they think about the task.

Fourth, consistent grammatical structure across all task descriptions makes the document easier to read, easier to compare across steps, and easier to review for completeness. If one step begins with a past-tense verb, another with an infinitive, and another with a noun phrase, the reader's eye must re-parse every step rather than reading smoothly. A recommended convention is to write all steps in the simple present tense with the subject implied: "Enter username," "Select 'Sign In'," "Review the list of eligible medications." Applying this convention uniformly across all sections — even when different team members have written different parts — is one of the key tasks of document editing before submission.

The table below illustrates the difference between weak and strong task descriptions across several common examples:

Weak Description	Problem	Improved Description
Manage the medications	Vague verb; no specific action or object	Check the box next to each medication required for reorder
Do the login	No action verb; object not specified	Enter username and password, then select 'Sign In'
Handle the authentication token	Technical jargon; not user-facing language	Enter the six-digit code sent to the registered mobile number
The user has submitted the form	Past tense; inconsistent with other steps	Select 'Submit Request' to send the prescription request
Look at the confirmation	Imprecise verb; object vague	Note the confirmation reference number displayed on screen

Validating the Task Analysis

A task analysis document is a model of user behaviour. Like any model, it is an approximation that must be tested against reality before it can be trusted to drive design decisions. Validation is the process of checking whether that model accurately and completely represents what users actually do. There are four complementary validation approaches, and a thorough document will have passed through all of them.

The first approach is cross-referencing documented steps against collected data. Every step in the task diagram should be traceable to at least one piece of source evidence — an observation note, an interview transcript, a screen recording, or a process document provided by the client. If a step cannot be traced to a source, it may have been inferred by the analyst rather than observed in practice. This does not necessarily mean the step is wrong, but it does mean it needs to be flagged and verified. Practically, this is often done by annotating the task diagram with source references, for example noting "(Observation session 2, participant 3)" next to a step that was directly observed. Any step without such a reference becomes a candidate for further investigation.

The second approach is a structured peer review. This involves having team members or colleagues who were not the primary authors of a given section review the document systematically. Peer reviewers look for steps that are ambiguous (could be interpreted in more than one way), steps that appear to be missing (a logical gap between one step and the next), and steps that appear to be incorrectly sequenced (placed before a step that must logically precede them). A structured peer review uses a checklist or review template rather than relying on informal reading, because informal reading tends to miss exactly the kinds of errors that are most dangerous — the ones that seem reasonable at first glance. After the review, findings are collated and the authors revise the document to address each issue.

The third and most direct approach is a walkthrough validation with a real user. In this method, a member of the actual user group is asked to work through the task while the analyst follows along with the documented steps. The analyst narrates the steps from the document and asks the user to confirm whether that is indeed what they do, or whether they do something different. Discrepancies between the document and the user's actual behaviour reveal errors in the analysis. This might include steps the analyst documented but the user skips, steps the user performs that are missing from the document, or steps whose sequence the user naturally reverses. Walkthrough validation is particularly valuable for catching errors that both data collection and peer review missed, because it tests the document against live behaviour rather than against memory or inference.

The fourth step is revising the document based on validation findings before using it to drive design. It may be tempting to treat validation as a box-ticking exercise and proceed with design anyway. This is a significant risk. Design decisions built on an inaccurate task analysis produce interfaces that do not match how users actually work, which creates usability problems that are expensive to fix after development has begun. The discipline of completing the full validation-and-revision cycle before moving to design is what distinguishes a professionally produced task analysis from a rough first draft.

Linking Task Analysis to Design Artefacts

A task analysis document that sits in isolation — not connected to any downstream design work — has failed in its primary purpose. The value of the analysis is realised only when it actively shapes the artefacts that the development team will build from. Establishing explicit, documented links between analysis findings and design decisions creates a traceable chain of reasoning that benefits the entire project lifecycle.

The most direct link is between top-level tasks and primary navigation structures. The highest-level goals in a task hierarchy — the things users most fundamentally need to do — should correspond to the primary sections, menu items, or entry points of the application. If the top-level HTA for a pharmacy portal identifies three primary user goals (requesting repeat prescriptions, tracking order status, and managing account details), then the application's primary navigation should provide direct, prominent access to those three areas. Any navigation structure that buries a top-level user goal behind multiple sub-menus is misaligned with the task analysis and that misalignment should be explicitly flagged and justified if retained.

The second type of link connects cognitive demand annotations to specific interface support features. When the cognitive analysis identifies that a step places high memory load on the user, the design response should be a feature that reduces that load — for example a persistent summary, a pre-populated field, a tooltip that provides contextual information, or a system default that handles the decision for the user in common cases. When the analysis identifies that a step involves a decision the user may find ambiguous, the design response might be inline help text or a confirmation dialog that explains the consequences of each choice. Documenting these connections explicitly — "Cognitive annotation on step 4.1 motivated the addition of the persistent medication summary panel" — ensures that support features are not removed during development without understanding what user need they address.

The third link involves documenting the rationale for each design decision by referencing the specific task analysis step that motivated it. This is most naturally done in a decision log or in annotations within wireframes and prototypes. When a designer adds a feature, they record which task analysis finding justified it. When a feature is removed or changed, the team can check whether the task analysis finding it addressed has been addressed in another way, or whether the user need is now going unmet. This practice of rationale documentation is standard in mature design processes and is what allows design decisions to survive team changes, client feedback cycles, and evolving requirements without losing their justification.

The fourth principle is maintained traceability. Traceability means that at any point in the project, anyone can follow the chain: from a specific interface element, back to the design decision that introduced it, back to the task analysis finding that motivated that decision, back to the source data that produced that finding. This chain does not need to be maintained in a complex tool — a well-structured document with consistent numbering and cross-references is sufficient. But it must be maintained consistently. When requirements change — as they always do — traceability allows the team to ask "which design decisions were based on the requirement that has now changed?" and to update those decisions in an informed, systematic way rather than through guesswork.

Group Project Documentation Requirements

When a task analysis document is produced as part of a group project for assessment, it must meet a set of explicit structural and content requirements. These requirements exist both to ensure the document is professionally complete and to make it possible to assess individual contributions fairly. Each requirement is described below.

The document must include a defined scope statement, an HTA diagram with plans, and CTA annotations. These are not optional sections that can be omitted if time is short. The scope statement establishes the basis for everything else. The HTA diagram with plans is the core structural output of the analysis. The CTA annotations are what elevate the document from a procedural list to a cognitively informed account of user experience. A submission missing any of these three components is structurally incomplete regardless of the quality of its other sections.

All data sources used to inform the analysis must be cited within the documentation. This means identifying the observations, interviews, contextual enquiry sessions, or secondary sources from which each part of the analysis was drawn. Citations may be embedded as inline references within the task diagram (for example, by labelling each node with the source that supports it) or collected in a separate data sources appendix. The purpose of this requirement is twofold: it allows reviewers to verify that the analysis is grounded in actual research rather than assumption, and it models the professional practice of traceable, evidence-based design work. A document that presents an analysis without citing its sources provides no basis for trust in its conclusions.

The design implications section must connect at least three task analysis findings to specific interface decisions. This minimum threshold exists to ensure that the bridge between analysis and design is genuinely built, not merely gestured at. Each connection should clearly identify the task analysis finding (referencing the specific step or annotation number), describe the design implication that finding produces, and specify the interface feature or decision that addresses it. Three connections is the floor, not the ceiling — a thorough document will typically connect many more findings to design decisions. However, the three that are included must be genuinely specific and traceable, not vague generalisations.

Finally, each team member's contribution to the document must be clearly identified. This is both a project management requirement and an assessment requirement. In practice, it means that the document includes either a contribution statement (a section listing who wrote which parts), annotations on individual sections identifying their authors, or a team log documenting who produced what and when. This requirement also has a secondary benefit: it creates accountability within the team during the production process, because each member knows their section will be individually attributed. The contribution statement should be honest — claiming credit for work a colleague produced, or failing to credit a colleague for their contribution, is an integrity issue as well as an accuracy problem.

The following table summarises the key requirements for a group project task analysis document submission:

Requirement	What Must Be Included	Common Failure Mode
Scope statement	User group, primary goals, explicit boundaries of the analysis	Scope statement is too vague to constrain the analysis or is omitted entirely
HTA diagram with plans	Numbered hierarchical decomposition, visual or structured format, plan statements for each node with sub-tasks	Plans are missing; decomposition stops too high and does not reach atomic operations
CTA annotations	Cognitive demand notes linked to specific steps, identifying memory load, decision points, or skill requirements	Annotations are generic rather than step-specific; no connection to observable cognitive demands
Data source citations	References to observations, interviews, or secondary sources for each part of the analysis	No sources cited; analysis appears to be based on assumption rather than data
Design implications	At least three specific, traceable connections from task analysis findings to interface decisions	Implications are vague generalisations not tied to specific steps or findings
Contribution statement	Clear identification of each team member's role and specific contributions	Contribution statement is absent or lists only names without specifying what each person produced

Taken together, these requirements define a document that is not just complete but defensible — one that a reader can scrutinise, a validator can test, and a design team can act upon with confidence. Producing such a document is a significant undertaking, but it is precisely this rigour that makes task analysis a foundational method in user-centred design rather than a preliminary sketch that gets set aside once design begins.

NotesCovers all five subtopic clusters in depth: document components (scope, diagrams, plans/annotations, design implications), writing quality standards, validation methods, traceability to design artefacts, and group project requirements. Tables used for task description quality comparison and submission requirements checklist. Code block used to illustrate HTA numbering convention.

2

Videos on This Topic

▶

A task analysis is only useful to a design team if it is written down in a form other people can read, question, and build from. In this topic we look at what a complete task analysis document contains: a statement of scope and users, the data sources behind it, hierarchical task diagrams with numbered plans, narrative task descriptions, and a section that translates findings into design implications and interface requirements. Clear writing matters here as much as correct method — each task description should name the actor, the goal, the trigger, the steps, and the conditions for success, in language a teammate or client can follow without you in the room.

Documentation also has to be validated. Before you hand it to a design team, you check it back against real users and real evidence: did you observe or interview people doing the work, does the hierarchy match what they actually do, and does an independent reviewer reading your document reach the same conclusions? From there the document becomes a bridge to design artefacts — personas, scenarios, screen flows, and requirement lists — and for this course, to your group project deliverable.

The three videos below do not describe a documentation template directly; they cover the evidence-gathering and review practices that make the documentation trustworthy. As you watch, listen for things you can cite in your own document: how qualitative research data is collected and organized, how a session is set up so the data is usable, and how a structured review produces findings that are specific enough to act on. Ask yourself after each video: what would I write down, and in what section of my task analysis document would it go?

3

Video 1: How to Conduct a Heuristic Evaluation

▶

NNgroup · 4:50 · 45,581 views · 2y ago · captions — Watch on YouTube

About this video

NNgroup explains how to run a heuristic evaluation: a systematic expert review of an interface against a set of usability principles to surface potential problems. The video covers the basic procedure and the idea of reviewing in a structured, repeatable way rather than ad hoc.

Why this video

Heuristic evaluation is a model of structured review and of writing findings so others can act on them, which maps directly onto validating your task analysis and onto linking documented problems to design implications and interface requirements.

4

Video 2: UX Research - Get Started With Qualitative User Research (2023)

▶

CareerFoundry · 14:18 · 134,439 views · 4y ago · captions — Watch on YouTube

About this video

A long-form introduction to qualitative user research from CareerFoundry, covering why user research is done, common qualitative methods such as interviews and observation, and how researchers plan and run studies. Based on its title and description it is aimed at beginners entering UX and works through the research process at a practical level. Expect discussion of participants, questions, and what you do with the material you collect.

Why this video

Task analysis documentation stands or falls on the quality of the underlying data, so this video supports the sections of your document that describe methods and data sources, and helps you justify your task descriptions with evidence rather than assumption.

5

Video 3: Introducing a Participant to a Usability Test: A Demonstration

▶

NNgroup · 3:35 · 64,558 views · 3y ago · captions — Watch on YouTube

About this video

A short demonstration from Nielsen Norman Group showing facilitation experts introducing a participant at the start of a usability test session, including the use of a facilitator's script. It models the wording and tone used to set expectations, explain think-aloud, and put the participant at ease. The emphasis is on preparation and consistency across sessions.

Why this video

It makes the case for scripted, repeatable procedure, which is exactly the standard your validation section needs if another reader is to trust or reproduce your findings; the facilitator script is also a concrete example of the kind of artefact that belongs in a document appendix.

6

How These Videos Support the Learning Outcomes

▶

Together these videos reinforce the module outcomes from the documentation side. The qualitative research video supports MO1 and MO2 by showing where the raw observations behind an HTA or CTA come from and how user workflows are captured before being structured into a hierarchy. The usability test introduction supports MO2 by modelling disciplined, consistent session practice, so the steps and plans you record reflect what users actually do rather than what you assumed. The heuristic evaluation video supports MO3 by demonstrating how structured review turns observations into specific, reportable problems and requirements — the same move you make when you translate a finished task analysis into design implications and bottlenecks for your group project document.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Applying Task Analysis to the Group Project

1

Applying Task Analysis to the Group Project

▶

Task analysis is not merely an academic exercise — it is a disciplined, collaborative process that transforms vague design intentions into structured, evidence-based understanding of what users actually do, think, and need. When a team undertakes task analysis together, the challenges multiply: different members observe different things, interpret data differently, and hold different mental models of the system being studied. A successful group project requires not only mastery of task analysis techniques but also explicit coordination strategies that keep the team's work coherent, consistent, and grounded in real user data. The sections below walk through each phase of the group task analysis process in depth, from agreeing on a primary user goal all the way through finalizing a polished, internally consistent document.

Identifying Your Project's Primary User Goal

The primary user goal is the foundation of the entire task analysis. Everything else — the hierarchical decomposition, the cognitive annotations, the design implications — flows from this single starting point. Getting it right is therefore not a formality but a genuine intellectual task that deserves careful team discussion before any data collection begins.

The most important discipline here is expressing the goal from the user's perspective as a desired outcome, not from the designer's perspective as a system feature. Consider the difference between these two framings:

System-centric (avoid): "Use the medication management module to log a new prescription."
User-centric (preferred): "Ensure my current prescriptions are accurately recorded so I never miss a dose or take the wrong medication."

The user-centric framing keeps the analysis honest. It reminds the team that intermediate steps — navigating menus, entering data fields, confirming entries — are instrumental, not intrinsically meaningful. Users do not care about clicking a button; they care about the outcome that button click produces. When the primary goal is expressed as an outcome the user genuinely wants, it becomes much easier later to evaluate whether a proposed design actually serves that goal.

The goal also needs to be complex enough to yield at least three levels of hierarchical decomposition. A goal like "read a notification" is too shallow — it decomposes in one or two steps and stops. A goal like "plan and complete an international business trip within a corporate travel management system" has natural depth: planning involves booking flights, reserving hotels, and arranging ground transport; each of those involves searching, comparing, selecting, and confirming; confirming involves entering payment, agreeing to policy, and receiving confirmation. Three or more levels emerge naturally. If your team's proposed goal collapses into a flat list of four or five steps with no further decomposition, it is probably too narrow and should be broadened or reframed.

Team agreement on the primary goal must happen early. A common and costly mistake is for each team member to silently hold a slightly different understanding of what the project is about. One member may think the goal is about the booking process, another about expense reporting afterward. When these divergent assumptions surface during analysis — or worse, during document review — significant rework is required. A brief but formal goal-setting session, with explicit verbal agreement and a written record, prevents this. Use a simple agreement protocol: state the proposed goal, invite objections or alternative framings, discuss, and call for explicit consensus before moving on.

Finally, document the rationale for the chosen goal as part of your scope statement. The rationale explains why this goal was selected over alternatives. For example: "We chose 'ensure prescriptions are accurately recorded' rather than 'log a new prescription' because our preliminary interviews revealed that users are motivated by medication safety outcomes, and the narrower framing would have excluded critical review and correction behaviors we observed." This rationale serves multiple purposes — it justifies the scope to any reader of the document, it guards against scope creep mid-project, and it provides a benchmark against which the final HTA can be evaluated.

Dividing Data Collection Responsibilities

Once the primary goal is agreed upon, the team must gather empirical data about how real users pursue that goal. This almost always involves some combination of observation sessions, think-aloud protocols, interviews, and contextual inquiry. With a team of several people, there is an opportunity to collect richer data than any individual could — but only if the division of labor is explicit and systematic.

Assign specific participants or data sources to each team member before collection begins. Do not leave this to chance or to whoever happens to be available. A clear assignment matrix eliminates duplication of effort and ensures coverage. For example:

Team Member	Assigned Participant(s)	Method	Scheduled Date
Alex	Participant 1 (novice user, age 62)	Think-aloud observation	March 4
Jordan	Participant 2 (experienced user, pharmacy tech)	Semi-structured interview	March 5
Sam	Existing usability study reports (3 documents)	Document analysis	March 4–6
Riley	Participant 3 (caregiver managing family member's medications)	Contextual inquiry	March 6

This kind of matrix makes responsibilities unambiguous and allows the team to track progress. It also helps ensure that the team is sampling across relevant user types — novice versus experienced, primary user versus proxy user — which will become important when distinguishing cognitive demands at different expertise levels during CTA integration.

Consistency across data collection sessions is critical, and it is achieved through a shared observation guide or interview script. When each team member uses the same core set of questions and observation prompts, the resulting data is genuinely comparable. Without a shared guide, one member might probe deeply into error-recovery behaviors while another focuses entirely on the happy path; the resulting dataset has gaps that are hard to diagnose after the fact. A good shared guide includes: a warm-up introduction script, a set of core tasks for the participant to attempt, a list of follow-up probes (e.g., "Can you tell me what you were thinking when you paused there?"), and a structured note-taking template that prompts observers to record both actions and verbalizations.

After initial data collection, the team should hold a structured debrief session before any individual analysis begins. Each member presents their key observations, surprises, and apparent gaps. This session serves several functions: it surfaces inconsistencies or contradictions across data sources early, it allows the team to identify whether any critical subtasks were not observed or asked about, and it builds shared understanding so that individual analysis in later phases is informed by the full dataset rather than just one member's slice. Common gaps to watch for include: what happens when something goes wrong, what users do to prepare before starting the main task, and what users do to verify that the task was completed correctly.

All raw data — observation notes, interview transcripts, audio recordings, sketches, screenshots — must be stored in a shared location accessible to the full team from the moment it is collected. This is not just a logistical convenience; it is a scientific integrity requirement. Task analysis claims should be traceable to specific data points. If a team member leaves the project, or if the team needs to revisit a decision weeks later, the data must be available to everyone. Use a shared folder (cloud-based storage works well) with a clear, agreed-upon naming convention. Avoid keeping any data only on one person's local machine.

Building the HTA as a Team

Hierarchical Task Analysis (HTA) structures a complex goal into a hierarchy of tasks and subtasks, each decomposed until reaching a level of granularity appropriate for design analysis. Building this hierarchy collaboratively introduces both advantages — multiple perspectives, distributed cognitive load, richer coverage — and risks, particularly inconsistent decomposition depth, conflicting interpretations of task boundaries, and notational drift across sections authored by different people.

The recommended approach is to draft an initial task hierarchy individually before converging as a team. Each team member independently produces their own draft HTA based on the collected data. This step might feel redundant, but it is essential: it forces every team member to engage seriously with the full task structure rather than passively accepting what emerges from group discussion. When the team then convenes to compare drafts, genuine differences in decomposition reveal real analytical questions — not just oversights — and the discussion is richer and more productive.

During convergence, the team will encounter disagreements about task order or decomposition level. For example, one member might decompose "confirm prescription details" into three subtasks while another treats it as a single atomic step. Resolve these disagreements by referencing collected user data, not personal intuition or convenience. The correct question is always: "What did users actually do here?" If the observation data shows that users consistently pause, scan, and then actively correct entries at this step, it warrants decomposition. If users treat it as a single fluid action with no distinguishable sub-steps, it may be appropriately left as atomic. Data is the arbiter of disagreements, not seniority, not who speaks most confidently, and not the path of least resistance.

Assign one team member as the document owner responsible for maintaining consistent notation throughout the HTA. HTA notation includes conventions such as numbering schemes (1, 1.1, 1.1.1), plan descriptions (specifying the order or conditions under which subtasks are performed), and the level at which decomposition stops. If different team members use different numbering schemes, describe plans in different formats, or decompose to wildly different levels of granularity in their sections, the resulting document is incoherent. The document owner does not need to author all sections, but they must review every section for notational consistency and have authority to request revisions.

A well-formed HTA plan statement is worth illustrating. Consider a partial HTA for the goal "Ensure current prescriptions are accurately recorded":

0. Ensure current prescriptions are accurately recorded
   Plan 0: Do 1, then 2, then 3. If error found at any point, do 4 before proceeding.
   1. Gather prescription information
      Plan 1: Do 1.1 and 1.2 in any order before doing 1.3.
      1.1 Locate physical prescription or pharmacy record
      1.2 Note dosage, frequency, and prescriber details
      1.3 Confirm information with prescriber or pharmacist if unclear
   2. Enter prescription into the system
      Plan 2: Do 2.1, 2.2, 2.3, 2.4 in sequence.
      2.1 Navigate to the medication entry screen
      2.2 Search for the medication by name
      2.3 Select correct medication and dosage form
      2.4 Enter dosage schedule and start date
   3. Verify the recorded entry
      Plan 3: Do 3.1, then 3.2. If discrepancy found, do 4.
      3.1 Review the saved entry on screen
      3.2 Cross-check against the physical prescription
   4. Correct an erroneous entry
      Plan 4: Do 4.1, then 4.2, then return to step 3.
      4.1 Locate and open the incorrect entry
      4.2 Edit the erroneous field(s) and save

Note how plan statements specify sequencing, conditionality, and looping. This is what distinguishes HTA from a simple bulleted list — the plans carry the procedural logic of the task.

Once the HTA is drafted and internally consistent, the team must review the completed hierarchy against the original user goal to confirm nothing critical is missing. Walk through the HTA as if you were a user and ask: "If someone followed every step described here, would they actually achieve the goal as we defined it?" Check specifically for missing error-handling paths, missing preparatory steps, and missing verification steps — these are the most commonly omitted elements in first-draft HTAs.

Integrating CTA Findings into the Document

Cognitive Task Analysis (CTA) goes beyond the observable sequence of actions to examine the mental processes underlying them: what knowledge users must draw on, what decisions they make, where uncertainty arises, and what expertise distinguishes novice from expert performance. Integrating CTA findings into the HTA document transforms a behavioral map into a cognitively rich analysis that directly informs interface design.

The primary data sources for CTA in a group project are typically think-aloud transcripts and interview records. Begin by having every team member review all transcripts — not just their own — and mark any passage where a participant expresses uncertainty, describes a decision, reveals background knowledge they are applying, asks a question, makes an error and recovers, or describes a situation where they were unsure what to do next. Common linguistic signals include phrases like:

"I'm not sure if I should…"
"I usually do it this way, but I don't know if that's right…"
"I have to remember to…"
"Wait, I need to check…"
"I learned this the hard way…"
"Hmm, I'd have to look that up…"

Each marked passage corresponds to a specific step in the HTA. The next step is to annotate each relevant HTA step with the corresponding cognitive demand identified in the data. These annotations should be concise but specific. A vague annotation like "users find this confusing" is not useful. A useful annotation looks like this:

Step 2.3 – Select correct medication and dosage form: Novice users expressed uncertainty about the difference between brand-name and generic medication entries (3 of 4 novice participants verbalized confusion or selected the wrong entry on first attempt). Expert users (pharmacy technician) reported using a mental rule: "always search by generic name first." This knowledge gap is not supported by any on-screen cue.

This annotation is grounded in data (specific participant counts, verbatim behavior description), identifies the nature of the cognitive demand (knowledge gap regarding classification), distinguishes expertise levels, and closes with an implicit design implication (the absence of an on-screen cue). That structure — what was observed, in whom, what it reveals about cognition, and what is currently absent — is the template for a strong CTA annotation.

The distinction between cognitive demands for novices versus experienced users deserves particular attention. Many interface design failures stem from designing for the experienced user's mental model while ignoring the novice's. CTA annotations should explicitly tag each finding as primarily affecting novices, primarily affecting experts, or affecting both but for different reasons. For instance:

HTA Step	Cognitive Demand	Primarily Affects	Evidence
1.3 – Confirm with prescriber if unclear	Decision: when is information "unclear enough" to warrant calling the prescriber?	Novices	P1, P3 did not know when to escalate; P2 (expert) had internalized clinical thresholds
2.2 – Search for medication by name	Recall: generic vs. brand name; spelling variation	Both (different reasons)	Novices struggled with generic names; experts struggled with spelling of uncommon drugs
3.1 – Review saved entry on screen	Attention management: knowing which fields are critical to verify	Novices	P1, P3 scanned all fields equally; P2 went directly to dosage and frequency fields
4.1 – Locate and open incorrect entry	Memory: recalling which entry was recently added to locate it for editing	All users	All participants had difficulty locating the entry they had just added after navigating away

A crucial discipline: CTA annotations must be grounded in collected data, not team assumptions about user cognition. It is tempting, especially when data is sparse, to fill in gaps with the team's own intuitions — "users probably find the date format confusing" or "users likely don't know the difference between these two options." These assumptions may be correct, but they do not belong in the CTA section of an empirical task analysis document. If you lack data for a particular step, note the gap explicitly: "No think-aloud data was collected for this step; future user research should investigate whether users understand the distinction between X and Y." This honesty is more valuable — and more credible — than invented confidence.

Reviewing and Finalizing the Project Document

The final review phase is where a collection of individually competent sections becomes a coherent, professional document. Because different team members authored different sections, the review must be systematic and must check for both completeness and consistency.

Begin with a completeness check. Verify that all required components are present. A complete task analysis project document typically contains:

Scope statement: defines the primary user goal, the user population studied, the rationale for the chosen goal, and the boundaries of the analysis (what is and is not included)
HTA diagram or structured outline: the full hierarchical decomposition with plan statements at each level
CTA annotations: cognitive demand notes attached to relevant HTA steps, grounded in data, with expertise-level distinctions
Design implications section: a set of specific, actionable recommendations derived from the task analysis findings

If any of these components is missing or present only in skeletal form, the document is incomplete regardless of how well the present sections are written.

Next, conduct a consistency review. Terminology and notation must be uniform across all sections regardless of who authored them. Common inconsistencies to check for:

The same task step referred to by different names in different sections (e.g., "confirm entry" in the HTA but "verify prescription" in the CTA annotations)
Numbering schemes that do not match between the HTA outline and references to steps in the CTA or design implications sections
Inconsistent use of technical terms (e.g., "task" versus "subtask" versus "step" used interchangeably without definition)
Different verb tenses or grammatical persons used to describe tasks in different sections

A practical method: the document owner should do a single read-through specifically looking for terminology, and create a brief glossary or style note at the start of the document if needed.

The design implications section requires its own focused review. Every design implication must cite a specific task analysis finding as its source. This is the link between analysis and design — the reason task analysis is worth doing. A design implication that cannot be traced to a specific finding is an opinion, not an evidence-based recommendation. Compare these two versions:

Unsupported (avoid): "The interface should display the generic drug name prominently."
Supported (preferred): "The interface should display the generic drug name prominently alongside the brand name during medication search (Step 2.2), because 3 of 4 novice participants either searched by brand name alone and failed to find the medication, or selected an incorrect entry due to brand/generic confusion (CTA annotation, Step 2.2)."

The supported version gives a design reviewer everything they need: what to do, where it applies, why, and what the evidence basis is. It is also substantially more persuasive to stakeholders who might otherwise dismiss the recommendation as stylistic preference.

Finally, proofread all task descriptions to ensure they are written from the user's perspective using action verbs. Task descriptions should describe what a user does, not what the system does, not what the designer intends, and not abstract states. Each task description should begin with a strong, specific action verb: navigate, select, enter, review, confirm, locate, compare, decide. Avoid passive constructions ("the form is completed"), vague nouns ("medication management"), and system-centric framings ("the system displays"). A quick pass through every task description — searching for any that do not begin with an action verb performed by the user — catches most of these problems efficiently.

By the end of this review process, the team should have a document that any reader — including those unfamiliar with the project — could use to understand what users do, what mental demands those actions place on them, and what specific design changes would reduce friction, support novice users, and leverage the existing strengths of expert users. That is the goal of the entire exercise: not a document that demonstrates effort, but a document that generates genuine design insight from real evidence about real users.

NotesThis topic covers the full applied workflow for a group task analysis project: goal-setting, data collection coordination, HTA construction, CTA integration, and final document review. Instructors may want to pair this with a rubric that maps directly to the five phase headings so students can self-assess before submission. The HTA code block example and the annotated tables are suitable for use as classroom templates.

2

Videos on This Topic

▶

This topic takes the methods you learned earlier in the module — hierarchical task analysis (HTA) and cognitive task analysis (CTA) — and puts them to work inside your group design project. The practical questions here are different from the textbook ones: What is the single primary goal your users are trying to accomplish? Who on the team talks to users, and who writes up the notes? How do four people build one coherent task hierarchy instead of four partial ones? And how do interview findings about reasoning, judgment, and error become real content in your project document rather than an appendix nobody reads?

The work breaks into a sequence. First you narrow a broad project idea into a specific, researchable user goal. Then you divide data collection so that observation, interviews, and documentation review are covered without duplicated effort. Next you assemble the HTA as a team, agreeing on decomposition level and plans. Finally you fold CTA findings into the document and review it as a group for consistency, traceability, and clear design implications.

The three videos below come from Nielsen Norman Group, a long-standing UX research and consulting firm. None of them is specifically about HTA, so watch them for the surrounding project skills: how to sharpen a vague research goal into a specific one, how to decide what matters most when you cannot analyze everything, and how to reduce the administrative overhead that eats team time. As you watch, keep asking how each idea would change the way your team plans its next week of project work.

3

Video 1: Making UX Research Goals Specific

▶

NNgroup · 4:11 · 17,112 views · 4y ago · captions — Watch on YouTube

About this video

A short talk on turning broad, fuzzy research goals into specific, answerable ones, and on cultivating the mindset that keeps research focused. It is likely to show the difference between a vague aim and a goal that actually tells you what data to collect and from whom.

Why this video

This maps directly onto the first subtopic, identifying your project's primary user goal: before any HTA can be drawn, the team has to agree on what goal is being decomposed. The source is Nielsen Norman Group, a credible and widely used authority on UX research practice.

4

Video 2: UX Design Prioritization Methods

▶

NNgroup · 6:20 · 18,208 views · 3y ago · captions — Watch on YouTube

About this video

An overview of prioritization methods used in UX work, built around the premise that you cannot include everything and that adding everything makes a product worse. Expect discussion of how teams weigh items against each other and decide what to pursue first.

Why this video

Group projects run on limited time, so your team must choose which tasks to decompose in depth, which findings to foreground, and which to set aside — this video gives vocabulary and structured methods for making those calls defensibly.

5

Video 3: Automate Admin Tasks in the Research Process

▶

NNgroup · 5:01 · 2,623 views · 2y ago · captions — Watch on YouTube

About this video

A practical look at the administrative overhead of user research — scheduling, recruiting, consent, note handling — and ways to streamline or automate the repetitive parts. It focuses on process efficiency rather than on analysis technique.

Why this video

It supports dividing data collection responsibilities by showing where coordination effort actually goes, helping your team assign roles and cut busywork so more time is left for building the HTA and writing up CTA findings.

6

How These Videos Support the Learning Outcomes

▶

These videos do not teach HTA or CTA notation directly; they support the project-execution side of the module outcomes. Making research goals specific (MO1, MO2) ensures the task you decompose is well defined enough to yield a meaningful hierarchy rather than an unfocused sketch. Prioritization methods (MO3) help the team move from a large set of observations to the bottlenecks and interface requirements worth reporting, while the research-overhead video protects the time your group needs to actually collect data, build the diagram, and review the final document together.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.