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.