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.
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.
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.
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.
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.
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.
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.
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).
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) 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.