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.