Every usability test produces evidence, but not all evidence looks the same. Some of it is numeric — how many participants finished a task, how long they took, how many errors they made, how they rated the system at the end. Some of it is observational — what a participant said while hesitating, where they looked for a button that wasn't there, what assumption led them down the wrong path. This topic builds the shared vocabulary you need to talk about both kinds of data and to know which kind answers which question.
The distinction matters because the two types of data do different jobs. Quantitative measures such as task completion rate, error rate, time on task, and satisfaction scores let you compare designs, track progress across iterations, and describe the size of a problem. Qualitative findings explain why the numbers look the way they do and point toward a fix. In this module you will need both: numbers to prioritize and justify, observations to diagnose and redesign.
As you watch the videos below, pay attention to three things. First, notice when a speaker is talking about a small qualitative study versus a larger measurement study, since the sample size changes what a number is allowed to mean. Second, note the exact definition of each metric — what counts as "complete," what counts as an "error" — because sloppy definitions produce misleading results. Third, watch how satisfaction is treated as its own dimension, separate from whether a user actually succeeded.
This short video from Nielsen Norman Group discusses what happens when you collect numeric measures during a qualitative usability study, where the goal is insight rather than statistical precision. It addresses how metrics gathered from a handful of individual participants can be used to describe how each person performed and to support the narrative of the findings, rather than being reported as reliable averages. Expect guidance on the limits of small-sample numbers and on keeping metrics in service of the story.
It directly addresses the quantitative versus qualitative distinction that anchors this topic, and it comes from a widely cited usability research organization, so the framing matches standard professional practice.
This video introduces benchmark usability testing: studies designed to measure key performance indicators of an interface so that performance can be compared over time or against another design. It is likely to cover the kinds of KPIs typically tracked in such studies — including success or completion rates, time on task, errors, and satisfaction — and how a benchmark is structured so results remain comparable across rounds. The emphasis is on measurement with a purpose rather than numbers for their own sake.
Benchmarking is where completion rates, error rates, and time on task are used most rigorously, so this video ties several of the subtopics together and shows why consistent metric definitions matter for iterative redesign.
The longest of the three videos, this one explains the System Usability Scale, a standardized ten-question survey given at the end of a usability session to capture perceived usability. It covers what the instrument is, how it is administered, and how the resulting score is interpreted as a measure of a user's subjective experience. Expect discussion of why a standardized, well-established questionnaire is preferable to ad hoc satisfaction questions.
It gives concrete, widely adopted grounding for the satisfaction scores subtopic and demonstrates how a subjective impression can be turned into a comparable number for use across design iterations.
Together these videos establish the measurement vocabulary the rest of the module depends on. Understanding which data are qualitative and which are quantitative, and how completion, error, time, and satisfaction measures are defined, is what allows you to read a set of test results and spot recurring patterns and failure points (MO1). The benchmarking and metrics videos show how frequency and magnitude are captured numerically, which is the basis for ranking issues by severity and user impact when deciding what to fix first (MO2). The emphasis on consistent, repeatable measures — especially standardized satisfaction scoring — supports iterative redesign by giving you comparable evidence across rounds and a documented rationale for each change you make (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.
Usability testing produces a flood of raw material: observation notes, screen and audio recordings, task success and failure records, time-on-task numbers, quotes, and your own impressions. Collecting and organizing test data is the discipline of capturing that material consistently during sessions and then structuring it so that patterns across participants become visible. Without a plan for recording and organizing, findings tend to collapse into anecdotes about whichever participant was most memorable.
This topic covers four practical pieces. Data collection methods address what you capture and how (note-taking templates, recordings, observer roles, consistent prompts and session openings). Affinity diagramming is the technique of writing individual observations on separate notes and clustering them until themes emerge from the bottom up. Usability issue logs give each problem a stable identifier, description, location in the interface, affected participants, and a severity rating. Synthesizing across participants is the step where you count how many people hit the same obstacle and decide what the evidence actually supports.
As you watch the videos below, pay attention to the habits that make later analysis possible: scripting the parts of a session that should be identical for every participant, using a small and explicit set of criteria so severity ratings stay consistent, and describing findings in terms that match the strength of the underlying data. These are the same habits that will let you defend your redesign priorities in this course's project work.
A short demonstration from Nielsen Norman Group showing how a facilitator introduces a participant at the start of a usability test session, including the use of a facilitator's script. The description points to covering standard opening elements such as explaining the purpose of the session, setting expectations, and working through the script so nothing is forgotten. Expect to see the interaction modeled rather than only described.
Consistent data starts with consistent sessions, and this clip makes the case for scripting the opening so every participant receives the same framing, which is a prerequisite for comparing results across participants.
This video explains how to assign severity ratings to design issues found through usability studies or heuristic evaluation, using a small set of criteria rather than ad hoc judgment. It is likely to discuss factors such as how many users are affected, how much the problem impedes task completion, and whether the issue is persistent. The focus is on reporting findings in a way that distinguishes major problems from minor ones.
Severity rating is the core of a usable issue log, and a short criteria-based approach from NNgroup gives students a defensible, repeatable way to record and rank issues rather than relying on gut feeling.
A brief treatment of how to present UX research results to stakeholders truthfully and responsibly. Based on its description, it addresses representing data honestly, avoiding overstating what a small study can support, and being careful with how numbers and claims from qualitative work are framed. It connects the analysis stage to the communication stage of a project.
It reinforces the synthesis subtopic by showing how aggregated findings should and should not be characterized once you move from raw notes to claims about users.
Together these videos trace the path from session to decision that this module asks you to walk. The facilitation demonstration supports MO1 by showing how standardized sessions yield comparable data in which recurring patterns and pain points can actually be detected rather than confused with facilitator variation. The severity prioritization video maps directly onto MO2, supplying explicit criteria for weighing frequency, severity, and user impact when ranking which issues to fix first. The responsible reporting video supports MO3 by modeling how to state findings accurately, which is exactly the kind of evidence-based rationale you are expected to document alongside each iterative design change.
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.
When a usability test session ends, you are left with a pile of observations: a participant clicked the wrong button, backtracked three screens, typed a date in the wrong format, or quietly gave up. Error analysis is the discipline of turning those raw observations into a diagnosis. Instead of reporting "the user got confused," you classify what kind of error occurred (a slip, a mistake, a mode error, a data-entry error), trace it back to a root cause, and name the specific interface element — a label, an affordance, a layout, a feedback message — that produced it.
This matters in CEN3722 because redesign decisions are only as good as the diagnosis behind them. Two errors that look identical on a screen recording can have completely different causes: one may be a momentary slip by an otherwise capable user, while the other reveals a fundamental mismatch between the user's mental model and the system's conceptual model. Those two findings call for very different fixes. You also need a defensible way to separate critical errors (data loss, task failure, security or safety consequences) from minor ones (a brief hesitation, an easily recovered misclick), because you will never have time to fix everything.
The videos below approach this from three angles: the metrics you use to quantify errors and task performance, the research methods that generate error data in the first place, and a research-level look at how touch-based errors are captured and investigated on real devices. As you watch, keep asking three questions: How would I count and record this kind of error? What would I need to observe to infer its cause rather than just its symptom? And how would I decide whether this error is worth a redesign cycle?
This video from the Eleken design agency walks through six commonly used UX metrics and explains what each one measures and when to apply it. Based on its title and description, expect coverage of performance and satisfaction measures such as task success or error rates, time on task, and standardized satisfaction scores, framed around the problem of knowing whether a product actually works for real users rather than just for the team that built it.
Error analysis depends on quantification — you cannot judge severity or frequency without metrics — and this video gives you the vocabulary for counting errors and task failures in a consistent, reportable way. It supports the subtopic of distinguishing critical from minor errors by showing how numbers are used to argue that an issue matters.
Kerev Design contrasts user testing with usability testing, two methods that are frequently confused in practice. The video situates both within the broader UX research process and clarifies what question each method is designed to answer — roughly, whether people want the product versus whether people can actually operate it.
Correctly interpreting an error requires knowing what the study was designed to reveal, since an error observed in a usability test points at the interface while a problem surfaced in user testing may point at the concept itself. This distinction directly supports root cause analysis and keeps students from attributing the wrong cause to an observed failure.
This short conference presentation from ACM SIGCHI describes a new data collection approach for investigating touch-based errors, using a smartphone system as its case study. As a research talk it is likely to cover how touch interaction data is instrumented and captured, what kinds of touch errors the method distinguishes, and what the collected data reveals about where and why mistouches occur.
It is a peer-reviewed research source from the premier HCI professional organization, and it demonstrates error analysis at the most granular level — mapping specific errors to specific interface elements and target regions on a screen. The case-study format shows students what rigorous, evidence-based error classification looks like beyond informal note-taking.
Together these videos move students from observation to diagnosis to prioritization. The metrics video supplies the measurement vocabulary needed to spot recurring patterns and quantify frequency and severity, supporting MO1 and MO2. The user testing versus usability testing comparison helps students match findings to the right level of cause — concept, task flow, or control — which is essential for the accurate pain-point identification required by MO1 and for writing a defensible rationale behind each proposed change under MO3. The SIGCHI case study models fine-grained mapping of errors to specific interface elements, giving students a concrete example of the evidence trail that justifies a targeted redesign rather than a guess, and reinforcing the severity judgments called for in MO2.
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.
Usability testing almost always produces more problems than you have time or budget to fix. The real skill is deciding what to fix first. Prioritizing usability improvements means taking a raw list of findings and turning it into an ordered, defensible plan: which issues block users outright, which merely annoy them, which are cheap to repair, and which require architectural change.
This topic introduces four related tools. Severity rating frameworks give you a consistent scale (typically combining how badly the problem hurts the user, how often it occurs, and how persistent it is). Impact versus effort mapping plots findings on a simple grid so quick wins and expensive long shots become visible. Aligning priorities with design goals keeps the ranking honest, so that you fix what matters for the product's purpose and target users rather than what is easiest to argue about. Finally, communicating priorities to stakeholders is what makes the whole exercise useful, since prioritization only pays off if developers, product owners, and clients accept the ordering.
As you watch the videos, pay attention to the specific criteria each method uses, and notice how a judgment call ("this feels bad") gets converted into something comparable and reportable. Ask yourself how you would apply each framework to the findings from your own test sessions, and what evidence you would cite when someone pushes back on your ranking.
A short Nielsen Norman Group explainer on assigning severity ratings to problems found in usability studies or heuristic evaluations. It walks through the small set of criteria normally used to judge severity, so that findings can be reported on a consistent scale rather than described subjectively. Expect practical guidance on how to phrase and justify a rating when writing up results.
This is the most direct coverage of the severity rating framework subtopic, from the research group that popularized the approach, and it is short enough to use as a reference while scoring your own findings.
A broader survey of prioritization methods used in UX work, built on the premise that you cannot and should not build everything. It is likely to compare several approaches for ranking work items and explain when each is appropriate. Watch for how different methods weigh user value against cost or effort.
At six minutes it gives the widest view of the topic, covering impact versus effort style trade-offs and the general logic of prioritizing against product and design goals.
An introduction to applying the Pareto principle, the idea that a small share of items produces most of the effect, to design decisions. The description points to applications across features, usability problems, customers, and personas. Expect guidance on identifying the vital few issues worth concentrated attention.
It supplies a simple mental model for focusing limited resources, which complements formal severity scoring and supports the argument you will need to make to stakeholders about why some issues are deferred.
Together these videos move you from raw findings to an ordered plan of action. The severity video supports MO1 and MO2 by giving you consistent criteria for rating the pain points and failure patterns you identified in your test data. The prioritization methods and Pareto videos directly serve MO2, offering impact-versus-effort reasoning and a focusing heuristic for deciding which issues deserve scarce time. Because each method makes its criteria explicit, all three also feed MO3: the rating or ranking you assign becomes the documented rationale you cite when you justify each iterative design change to instructors, teammates, or stakeholders.
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.
Iterative redesign is the engine of user-centered design. Rather than treating a design as something you get right once, iterative practice treats every version as a hypothesis: you build it, put it in front of users, learn where it fails, change it, and test again. Each pass through this cycle should be smaller, more focused, and better informed than the one before it.
In this module you are working with real testing results, so the key question becomes what to do with them. Some findings call for targeted refinement — a label, a control, a step in a flow — while others reveal that the underlying concept or structure is wrong and a wholesale rethink is cheaper than patching. Deciding which situation you are in, recording why you made the change (your design rationale), and defining in advance what "better" would look like in the next round are the skills this topic develops.
As you watch, look for three things: how each speaker describes the loop itself (what happens at each stage and what triggers another pass), how they distinguish refining an existing idea from exploring alternative ideas, and how testing is positioned as a source of evidence rather than opinion. Note also how different process models — design thinking, agile — frame iteration, since the vocabulary differs even when the underlying cycle is similar.
A short Nielsen Norman Group talk arguing that generating more design options leads to better outcomes, and comparing three strategies for doing so: iterative design (improving one concept across rounds), parallel design (developing several concepts side by side), and competitive testing (learning from existing products). Based on the title and description, it addresses how teams combine these approaches to move quickly rather than treating them as mutually exclusive.
NN/g is a leading authority in usability research, and this video directly frames the choice between refining one design and exploring alternatives — the core of the targeted versus wholesale redesign distinction.
This video places usability testing within the design thinking process, picking up after prototyping to explain how testing validates the assumptions made in earlier stages. It is likely to cover what happens when testing reveals problems and how findings send the team back into earlier phases of the process.
It supplies the cyclical framing the topic depends on: testing is not an endpoint but the step that feeds the next iteration, which is exactly how the design cycle should be understood.
An Interaction Design Foundation video featuring Laura Klein that contrasts agile and waterfall approaches to software development and explains what an agile model means for UX work. Expect discussion of why working in short, repeated cycles with feedback differs from planning everything up front in a single linear pass.
It gives the process-level case for iteration over one-shot design and connects incremental cycles to the idea of setting goals for each round of work.
Together these videos build the conceptual frame students need before acting on their own test data. The design thinking video reinforces that testing findings loop back into design rather than closing it out, supporting the analysis work in MO1. The NN/g video on iterative, parallel, and competitive design gives students a basis for judging whether a finding warrants a focused fix or a fresh alternative, which underpins the prioritization decisions in MO2. The agile versus waterfall discussion models working in short, goal-bounded cycles, reinforcing MO3's expectation that revisions are made deliberately, one iteration at a time, with reasons that can be stated and defended.
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.
Once usability testing is finished and the findings are sorted, the real work begins: turning what you learned into a revised prototype that can be tested again. This topic walks through the practical decisions that revision involves — how much fidelity a change actually requires, how to translate an observed problem into a specific interface change, how to annotate what you changed and why, how to keep versions organized so you can compare and roll back, and how to sanity-check changes before putting them in front of users again.
Fidelity is a judgment call, not a default. A confusing label or a missing confirmation step may only need a sketch or a wireframe edit, while a problem with flow, timing, or feedback usually has to be felt by a user, which means you need a clickable prototype with real transitions and states. The tooling matters here because it determines how cheaply you can make a change, show it to someone, and change it again.
The videos below focus on the prototyping craft in Figma: building clickable flows, connecting frames with interactions, and using interactive components to handle states such as hover, selected, toggled, or error. While watching, pay less attention to the specific visual styling and more to the mechanics that support iteration — how prototype connections are created and edited, how components let you change one thing and have it propagate everywhere, and where you could attach notes or duplicate a page to preserve an earlier version for comparison.
A beginner-oriented walkthrough of Figma's prototyping mode, likely covering how to link frames, set interaction triggers and actions, choose animations and transitions, and preview a clickable flow. It is aimed at people building their first working prototype rather than a static mockup.
It gives you the baseline skill set needed to produce a testable, medium-to-high fidelity prototype, which is the foundation for deciding how far to take fidelity when implementing redesign changes.
A shorter, more recent prototyping tutorial from the same creator that condenses the core Figma prototyping workflow into a quick, focused run-through. Expect current menu locations and a streamlined path from frames to a working clickable prototype.
Its brevity and recency make it a good refresher when you need to implement a revision quickly between test rounds, reinforcing that iteration should be cheap and fast.
An official Figma tutorial on interactive components, showing how to define interactions inside a component so that states such as hover, pressed, toggled, or selected behave consistently wherever the component is used. It covers variants and how state changes are wired within the component itself.
Produced by Figma, so the mechanics are authoritative; component-level changes are directly relevant to version management and propagating a single redesign decision across an entire prototype rather than patching screens one by one.
These videos support the module outcomes on the implementation side of iteration. After you analyze test data for recurring patterns (MO1) and prioritize which issues to address by frequency and severity (MO2), you still need a concrete way to express those decisions in a prototype that can be retested — that is what the Figma prototyping and interactive component tutorials provide. They are most directly tied to MO3: the ability to rebuild flows quickly, change component states in one place, and keep separate prototype versions is what makes genuinely iterative revision practical, while the course's annotation and documentation practices supply the rationale record that accompanies each change.
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.
Usability work does not end when you finish testing or even when you ship a revised interface. The final professional step is documenting what you found, what you changed, and why — in a form that teammates, stakeholders, and future designers can actually use. That means usability testing reports that tie claims to evidence, before-and-after comparisons that make the change visible, and metrics tracked consistently across iterations so improvement (or regression) is measurable rather than anecdotal.
Communicating those outcomes is its own skill. The people who approve your redesign are often not interface specialists, so findings must be framed in terms they care about: task success, time on task, error rates, user frustration, and business consequences. At the same time, you have an ethical obligation not to overstate what a small study shows. Selective quoting, cherry-picked clips, and percentages drawn from five participants can mislead an audience that has no way to check your work.
The three short videos below come from Nielsen Norman Group, a long-standing usability research and consulting firm. As you watch, pay attention to three things: how they define usability in measurable components you can report on, how they recommend handling participant quotes so they illustrate rather than distort, and what responsible presentation of study data looks like when the sample is small. Try mapping each recommendation to a section you would write in your own redesign report.
A brief talk on how to share UX research results with stakeholders without misrepresenting what the data actually supports. Based on its title and description, it likely addresses common reporting pitfalls such as overgeneralizing from small samples, presenting percentages that imply more certainty than exists, and framing findings honestly while still being persuasive.
It speaks directly to the "presenting findings to non-technical audiences" and "usability testing reports" subtopics, and it reinforces evidence-based reporting as a professional obligation rather than a formatting exercise.
This video focuses on using participant quotes when communicating research insights, offering three practical tips for selecting and preparing them. It suggests that raw quotes usually need editing for clarity and context, and that quotes work best as support for a finding rather than as the finding itself.
Quotes are the most common qualitative evidence in a usability report, and this video gives concrete guidance on using them persuasively without distorting participant meaning — useful for both report writing and stakeholder presentations.
A foundational explainer defining usability and its five quality components, including learnability and efficiency. It establishes the vocabulary and measurable dimensions that underlie usability evaluation.
These components give you a consistent framework for tracking metrics across iterations and for structuring before-and-after comparisons, so your documentation reports on the same dimensions each round rather than shifting criteria.
Together these videos support the module outcomes by supplying both the vocabulary and the communication practices that turn analysis into documentation. The usability components explainer gives you consistent categories for naming recurring patterns and pain points (MO1) and for judging severity and impact when prioritizing fixes (MO2). The quotes and responsible-presentation videos address MO3 directly: iterative redesign is only defensible when each change is accompanied by a documented rationale, with evidence reported accurately and framed so that non-technical stakeholders can follow the reasoning from finding to design decision.
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.