Throughout this course you have made dozens of design decisions: where to put a button, how to label it, what feedback to show after a click. This topic asks you to look back at those decisions and name the theory behind them. Concepts such as affordances, the human-computer interaction cycle, and direct manipulation are not just vocabulary for an exam — they are the reasoning you use to explain why an interface works, and the evidence you cite when someone challenges your design.
Connecting theory to outcomes runs in two directions. Forward, theory guides choices before you build: a model of how users perceive, act, and interpret feedback tells you what to prototype in the first place. Backward, theory gives you a yardstick for evaluation: you can inspect your finished product and ask whether its controls actually signal their use, whether feedback closes the loop of interaction, and whether users manipulate meaningful objects or wrestle with hidden commands.
The three short videos below revisit core concepts at a practical level. As you watch, keep your own project on screen or in mind. For each idea presented, try to find one place in your interface where you applied it well, and one place where you did not — those paired examples are exactly the material you need for your final reflection, your design rationale presentation, and your list of proposed improvements.
A short explainer on affordances, one of the foundational concepts in interaction design, illustrated with a concrete example. Based on its title and description, it defines what an affordance is, distinguishes perceived cues from actual possible actions, and shows how affordances contribute to apps that feel intuitive and effective.
Affordances are among the most frequently invoked theories when designers justify control styling, button shapes, and clickability cues, making this a direct bridge from concept to design decision. The Interaction Design Foundation is a well-established HCI education provider, and the compact format suits a review before you audit your own interface.
This video presents the cycle of interaction between humans and computers — the loop in which a user forms a goal, acts on the interface, and interprets the system's response. Its description frames this understanding as essential groundwork for designing effective user interfaces and experiences, so expect coverage of the stages of that loop and why each one matters.
The interaction cycle is the framework that lets you explain feedback, visibility of system status, and error recovery in your final product rather than describing them as isolated features. It maps cleanly onto the subtopic of moving from concepts to real-world application, giving you a structure for walking an audience through a user's path in your interface.
NNgroup introduces direct manipulation as an interaction technique in graphical interfaces where users act on visible representations of objects rather than issuing abstract commands. The video is likely to define the technique, show examples such as dragging and resizing objects, and discuss when this style of interaction helps or hinders users.
Direct manipulation is a classic HCI principle with clear trade-offs, so it is a strong test case for evaluating how closely your final product aligns with established theory. Nielsen Norman Group is a widely cited usability research organization, which makes this a defensible source to reference in a design rationale.
These videos supply the theoretical vocabulary you need for the module's evaluation and reflection work. Affordances and the interaction cycle give you specific criteria for inspecting your finished interface against usability benchmarks and original requirements (MO1), and they give you named, citable concepts for defending design choices when you present your rationale (MO2). Revisiting direct manipulation and the perception-action-feedback loop prompts a sharper critique of your own process, including where psychological and accessibility considerations were handled well or overlooked (MO3). Finally, any gap you find between what theory recommends and what your product delivers becomes a concrete, well-justified candidate for your list of future improvements (MO4).
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.
Before you can judge whether your final interface succeeded, you have to revisit where it started. The analysis phase is the stretch of work that happens before any screens are drawn: talking to users, observing how they currently accomplish their goals, breaking those goals into tasks, and translating all of it into a set of requirements with a realistic scope. Decisions made here quietly determine almost everything that follows — which features exist, which users are served well, and which usability problems were avoidable from the beginning.
In this module you are reflecting rather than starting fresh, so the purpose of reviewing analysis is diagnostic. Which research method did you choose, and did it actually surface the information you needed? Did your task analysis capture real workflows, or an idealized version of them? Were your requirements specific enough to test against later, and did scope creep or scope gaps show up in the final evaluation? These questions give you the evidence you will need when you defend design decisions and propose improvements.
The three videos below revisit the fundamentals of qualitative user research, the overall shape of the UX process, and the range of research methods available. As you watch, resist treating them as introductory review. Instead, compare each practice described to what you actually did on your project, and note specific gaps you can name and explain in your reflection.
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.
Prototyping is the bridge between an idea and a working interface. In this topic you look back at the prototyping phase of your project and examine how low-fidelity artifacts such as sketches and wireframes helped you generate and compare design alternatives quickly, and how high-fidelity prototypes added visual detail, realistic interaction, and a closer approximation of the final product. The distinction matters because fidelity is a deliberate choice: low fidelity invites criticism and change, while high fidelity invites detailed feedback on layout, typography, color, and flow.
This review also focuses on iteration. Prototypes are rarely right the first time, and the value of the method comes from cycling between versions as user feedback, usability testing, and accessibility checks reveal problems. Being able to trace how a screen changed from sketch to wireframe to interactive prototype is exactly the kind of evidence you will need when you present and defend your design decisions at the end of the course.
As you watch the videos below, pay attention to three things: what level of detail is appropriate at each stage, what kind of feedback each fidelity level can realistically produce, and how the designer decides what to change between versions. Try to map each step shown back to a decision you actually made in your own project, including the ones you would make differently now.
Part of the Google UX Design Certificate series, this video covers the transition from lower-fidelity work into high-fidelity design, building new iterations that incorporate visual design elements. It is likely to address typography, color, imagery, spacing, and how a polished prototype communicates the intended look and feel. The framing emphasizes iteration rather than starting over.
It maps closely onto the high-fidelity prototyping and design refinement subtopic, and the Google UX curriculum is a well-established, industry-aligned source for process guidance.
A beginner-oriented tutorial from CareerFoundry that explains what a wireframe is and walks through creating one, covering the low-fidelity structure of a screen before visual styling is applied. It is likely to cover layout, content hierarchy, placement of interface elements, and the role wireframes play early in the design process. Expect practical, step-by-step guidance rather than theory alone.
It directly supports the low-fidelity prototyping and ideation subtopic by showing how rough, fast artifacts let designers explore structure and alternatives before committing to detail, and it comes from a widely used UX education provider.
A hands-on Figma tutorial for beginners focused on the prototyping features of the tool, likely showing how to connect frames, define interactions and transitions, and test a clickable flow. It demonstrates the mechanics of turning static screens into something a user can actually click through. The pace and scope suit students who have built screens but not yet linked them.
It grounds the iteration subtopic in practice by showing how prototype versions are assembled and revised in a common tool, making it easier to connect classroom concepts to the artifacts you produced.
Reviewing these videos helps you reconstruct and critique your own prototyping history, which is the foundation for this module's work. The wireframing and high-fidelity videos give you vocabulary and criteria for evaluating your final interface against the requirements and usability goals you set early on (MO1) and for explaining, in a presentation, why a design changed between versions (MO2). Seeing the standard progression from sketch to styled, interactive prototype also supports honest reflection on where ergonomic, psychological, cultural, or accessibility concerns were caught late or missed entirely (MO3). Finally, understanding prototyping as an ongoing cycle rather than a finished step makes it natural to propose a next iteration that addresses unresolved usability issues (MO4).
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.
The evaluation phase is where design claims meet evidence. Across this course you have moved from user research and requirements through sketches, prototypes, and iteration; now you look back and ask what your evaluation activities actually told you, how trustworthy that information was, and whether the changes you made in response were the right ones. Reviewing the evaluation phase means being honest about method choice (usability testing with real users, heuristic or expert inspection, or a combination), about the quality and quantity of feedback you gathered, and about the gap between what you intended to measure and what you could measure in the time available.
This review also feeds directly into your final deliverable. When you present your project, you will be expected to justify design decisions with evaluation data rather than preference, to show how specific findings became specific interface changes, and to state plainly which problems remain unresolved. That requires a shared vocabulary: what usability actually means as a measurable quality, how heuristic evaluation is performed in a disciplined way, and how findings are prioritized so that limited effort goes to the issues that matter most.
The three short videos below come from Nielsen Norman Group, a long-standing source of practitioner guidance on usability. As you watch, map each idea back to your own project: which usability components did you actually test, which heuristics would have caught the problems your users hit, and how would you assign severity to the issues still sitting in your backlog. Take notes you can reuse in your reflection and final presentation.
A walkthrough of how to run a heuristic evaluation: systematically inspecting a product against a set of recognized usability heuristics to surface potential problems without recruiting users. It is likely to cover who should evaluate, how evaluators work independently before combining results, and what kind of output the process produces. The emphasis is on being systematic rather than ad hoc.
Heuristic and expert evaluation is a named subtopic here, and this video comes from the group that popularized the method, so it is a reliable account of the standard procedure you can compare against what your team actually did.
A compact introduction to usability as a measurable property of an interface, framed around five quality components: learnability, efficiency, memorability, errors, and satisfaction. Expect definitions and short examples that distinguish usability from broader notions of user experience or visual appeal. It establishes the vocabulary used in the other two videos.
It gives you the measurement language needed to compare a finished interface against the usability goals you set at the start of the project, which is the core of the "measuring design quality against initial goals" subtopic.
Covers how to rate the severity of usability problems found in testing or inspection, using a small set of criteria such as frequency, impact on the user, and persistence of the problem. It addresses how severity ratings shape a findings report and help teams decide what to fix first. The focus is on turning a raw list of issues into an actionable, ranked set.
This is the bridge between findings and design changes: it models the prioritization reasoning you need to defend why some issues were fixed, some deferred, and some left as future work.
Together these videos equip you to carry out the final review the module asks for. The usability overview supplies the benchmarks against which you judge your finished interface (MO1), while the heuristic evaluation walkthrough gives you a repeatable inspection method and a defensible evidence base for the design rationale you will present (MO2). Severity rating supports both the critical self-assessment of your process, including where accessibility or psychological factors were under-tested (MO3), and the construction of a prioritized list of unresolved issues that becomes your proposal for future improvements (MO4).
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.
Near the end of a design project, the most valuable input you receive is rarely "I like it" or "I don't like it." It is structured feedback: comments tied to specific dimensions of design quality such as usability, learnability, consistency, visual hierarchy, accessibility, and fit with the users' actual tasks. This topic looks at how to frame a critique so that it produces that kind of comment, how to deliver criticism that a teammate can act on, and how to receive criticism without becoming defensive or rewriting your design in response to every stray opinion.
Structured feedback also serves a second purpose in this course. When several reviewers independently flag the same screen, the same control, or the same confusing label, you are no longer looking at one person's taste; you are looking at a pattern. Those patterns are what you carry into your final reflection and your list of proposed improvements, and they are the evidence you will cite when you defend your design decisions to an audience.
The three videos below come from the Nielsen Norman Group, a long-established usability consultancy. As you watch, pay attention to the mechanics: how a critique session is set up before anyone speaks, what makes a comment specific enough to act on, and how a quality dimension like accessibility can be defined precisely enough to be reviewed rather than vaguely praised. Then apply the same mechanics to your own project review.
A short, practical set of three tips for giving feedback during a UX design critique, aimed especially at designers who feel uncertain about speaking up. The video addresses the confidence problem behind weak or overly polite feedback and suggests ways to phrase observations so they are useful to the person receiving them.
It targets the "providing constructive critique" subtopic directly, and because it is written for newer designers it matches the position most students are in when reviewing a classmate's final project.
This video focuses on the receiving side of the exchange: how to set up a presentation of UX work so that stakeholders give you feedback you can actually use. It covers providing context before showing the work and framing what kind of input you are asking for, rather than opening the floor to unstructured reactions.
It fills in the half of the topic that students usually neglect, and it ties closely to presenting your final project and design rationale to an audience that may not share your HCI background.
An explanation of the difference between accessible design and inclusive design, two terms that are frequently used as synonyms but have different focuses and scopes. The video clarifies what each term covers so that the distinction can be applied when reviewing a product.
Accessibility and inclusion are core dimensions of design quality in this course, and having precise definitions lets you critique a project against a real standard instead of offering a general impression.
Together these videos support the module outcomes by giving you a working method for the evaluation and reflection phase. The accessibility and inclusive design distinction sharpens the criteria you use to judge the finished interface against usability and accessibility standards (MO1) and to reflect on the accessibility and cultural considerations you did or did not address during the project (MO3). The guidance on setting up a presentation to get useful feedback maps onto defending your design rationale to an audience with evidence rather than opinion (MO2), while the critique tips help you both contribute to and absorb peer review. Finally, the habit of collecting specific, structured comments is what lets you spot recurring problems and turn them into a concrete, prioritized list of future improvements (MO4).
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.
Designing an interface is only half the work; the other half is managing the process and the people who carry it out. This topic asks you to look back at how your team actually operated over the semester: how you planned and sequenced design activities, how work was divided among members, how you communicated and handled disagreement, and which tools and documents kept everyone aligned. These are the factors that most often explain why a project ran smoothly or fell behind, and they are rarely visible in the finished product alone.
In this course, honest reflection on process is part of your final evaluation. Employers and clients care not just about whether your prototype works, but about whether you can diagnose what went wrong, credit what went right, and describe how you would run the next project differently. A clear account of role distribution, meeting rhythm, conflict resolution, and documentation practice makes your final presentation far more credible than vague claims that "the team worked well together."
The three videos below come from Nielsen Norman Group, a long-established UX research and consulting firm. As you watch, map what you hear onto your own experience: Which phase of team development did your group get stuck in? Which workshop activities would have helped you converge on decisions faster? Where did stakeholder or instructor feedback get lost because no one documented it? Take notes you can quote directly in your reflection.
This short video walks through the five classic phases of team development as they apply to UX design groups, from an uncommitted collection of individuals to a high-performing team. It is likely to describe the behaviors typical of each phase, including the friction and disagreement that commonly appear early on, and what moves a team forward to the next stage. Expect practical signals you can use to diagnose where a team currently sits.
It speaks directly to role distribution, communication, and conflict resolution by framing team tension as a normal, nameable stage rather than a personal failure, which gives you vocabulary for your reflection. The Nielsen Norman Group framing keeps the model grounded in design team practice rather than generic management theory.
This video reduces the wide variety of UX workshop exercises down to seven foundational activities that underlie most of them, such as generating ideas, grouping and prioritizing them, and deciding as a group. It should explain what each activity is for and when in a session you would use it. The emphasis is on structuring collaborative work so a group reaches an outcome rather than just talking.
Workshop structure is the practical core of design process planning and execution, and knowing these building blocks helps you explain how your team ran (or failed to run) productive working sessions. It also offers concrete techniques you can recommend as a process improvement in your reflection.
This video presents an eight-step process for UX designers and researchers to work more effectively with stakeholders, covering how to involve them, communicate progress, and build buy-in for design decisions. It likely addresses identifying who the stakeholders are, when to bring them in, and how to keep them informed across a project. The focus is on collaboration as an ongoing practice rather than a one-time handoff.
Your instructor, client, or test participants function as stakeholders, so this maps onto communication practices and documentation habits that keep external parties aligned with the team. It is a compact, step-based framework that is easy to cite when you describe how you managed feedback and approvals.
These videos support the module outcomes by giving you structured language for critiquing your own design process (MO3): team development phases, foundational workshop activities, and a stakeholder collaboration sequence. That vocabulary strengthens your final presentation and design rationale, since you can explain not only what you decided but how and with whom decisions were made and defended (MO2). Identifying where planning, role distribution, communication, or documentation broke down also helps you connect unresolved usability issues back to process causes when you evaluate the finished interface (MO1) and propose concrete improvements for future iterations (MO4).
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.
Reflection is the step that turns a finished project into durable learning. Now that your interface has been built, evaluated, and presented, this topic asks you to look backward with discipline: what design decisions held up under user testing, which assumptions about your users were wrong, where did ergonomic, psychological, cultural, or accessibility considerations surprise you, and what would you do differently if you started the project again tomorrow? Reflection here is not a vague feelings exercise — it is a structured, evidence-based critique of your own process.
The topic has two levels. Individual reflective practice asks you to write honestly about your own contributions, skills, and blind spots, supported by concrete evidence from your design artifacts and evaluation data. Team-level lessons learned asks the group to meet, surface what worked and what did not without blaming individuals, and record outcomes that a future team could actually act on. Both levels should connect explicitly back to course concepts — usability heuristics, user-centered design, accessibility standards, cognitive load, and the evaluation methods you used.
As you watch, look for structure: how a reflective statement moves from description to analysis to action, how a lessons-learned meeting is facilitated so that criticism stays constructive, and how reflection is built into project-based HCI work rather than tacked on at the end. Your goal is to come away with a small number of specific, actionable improvements you could carry into your next design project.
A practical walkthrough of how to plan and run a lessons learned meeting at the close of a project, from a project management consultant. Based on its title and description, it likely covers when to hold the session, who to invite, how to prepare questions, how to facilitate the discussion so people speak candidly, and how to capture and store the results so they get used again.
It directly supports the Team-Level Lessons Learned subtopic by giving your group a repeatable meeting format instead of an unstructured gripe session, and it comes from an experienced project management practitioner who focuses on facilitation technique.
A guide to writing reflective assignments aimed at students who are unsure what reflection should actually look like on the page. The description promises concrete examples, so expect coverage of what to include, how to move beyond simply describing events, and how to phrase analysis and conclusions in your own voice.
This maps closely to Individual Reflective Practice and is useful if you have to submit a written reflection, since it models the description-to-analysis-to-action structure that distinguishes a graded reflective piece from a diary entry.
A conference presentation from ACM SIGCHI on pedagogical strategies for building reflection into project-based HCI courses that involve real end users. It is likely to discuss how and when students should be prompted to reflect during a design project, and what instructors have observed about students working with external users and stakeholders.
This is the most discipline-specific of the three, connecting reflection directly to HCI design education and to the Connecting Course Concepts to Project Experience subtopic, and it comes from the main professional community in human-computer interaction.
Together these videos give you the method, the format, and the HCI context for closing out your project. The lessons learned meeting guide supports team-level critique of the design process (MO3) and helps the group converge on concrete next steps for the interface (MO4). The reflective writing guide gives you a structure for individually critiquing your own process and evidencing claims with project data, which also strengthens how you defend design rationale to an audience (MO2, MO3). The SIGCHI presentation situates all of this inside project-based HCI education with real end users, reinforcing the habit of judging your work against requirements, usability benchmarks, and accessibility considerations rather than personal preference (MO1, 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.