Evaluation documentation is the part of an HCI report that makes your usability work verifiable. It records what you did (the method, the participants or evaluators, the tasks, the setting), what you found (the specific problems, with evidence and severity), and what you changed as a result (the design iterations your findings triggered). Without this record, evaluation results become opinion; with it, they become justification that a reader can trace from a user's struggle to a concrete design decision.
In this course, the evaluation section is where your project report earns its credibility. Your audience — instructors, teammates, and in professional practice, stakeholders and developers — needs to know how confident to be in each finding and what to prioritize first. That requires writing methodology precisely enough to be repeated, reporting findings in a structured and rated way rather than as a loose list of complaints, and stating honestly what your evaluation could not tell you.
The three videos below come from the Nielsen Norman Group and cover complementary pieces of this workflow: running and recording a heuristic evaluation, rating and reporting findings by severity, and reasoning about the limits of small-sample testing. While watching, note the vocabulary each video uses for method steps and severity criteria — borrow that vocabulary for your own report — and keep asking: what would I need to write down during this activity so that someone reading my report later could follow my reasoning?
A short walkthrough of how to run a heuristic evaluation: systematically reviewing an interface against established usability heuristics to surface potential problems before or alongside user testing. Based on its title and description, it likely covers who should evaluate, how to work through the product in a structured way, and how individual evaluators' findings are combined. Treat each step it names as something you should be recording in your methodology section.
It gives you a concrete, named evaluation method to document accurately, and Nielsen Norman Group is the organization that originated the heuristic evaluation technique, so the terminology you pick up here will match what professional reports and your course readings use.
This video explains how to assign severity ratings to usability problems found in testing or heuristic evaluation, using a small, consistent set of criteria. It addresses the reporting stage directly: once you have a list of issues, how do you communicate which ones matter most. Expect discussion of the factors that push an issue up or down the priority scale.
Presenting findings and linking them to design iterations both depend on prioritization — this video supplies a defensible rating scheme you can cite in your report so that your choice of what to fix first looks reasoned rather than arbitrary.
This talk responds to the common stakeholder objection that five test users cannot represent all customers and that acting on such limited data is risky. It discusses what small-sample qualitative testing can and cannot support, and how to weigh limited evidence against the alternative of shipping with no evidence at all. It frames evaluation limitations as something to state and reason about rather than hide.
It maps directly onto the reflecting-on-limitations subtopic, giving you language for writing an honest limitations paragraph that acknowledges sample size and generalizability without undermining the value of your findings.
Together these videos supply the raw material for the evaluation portion of your design document (MO1): a documentable method in the heuristic evaluation walkthrough, a structured way to present and prioritize findings via severity ratings, and a model for writing a limitations section. The severity and method vocabulary supports the technical writing conventions emphasized in MO2, giving you consistent, professional terms instead of informal descriptions of problems. And because severity ratings and an honest account of evaluation scope are exactly what let you argue why one issue was fixed in the next iteration and another was deferred, these videos directly feed the evidence-based justification of design choices required by 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.