Final implementation documentation is the part of your HCI design report that answers a simple but demanding question: what did you actually build, and why does it look and behave the way it does? It includes a clear description of the delivered interface (screens, components, navigation, key interactions), a record of the decisions you made while implementing it, an honest account of where the final product departs from your prototype, and a trace that links each significant design choice back to requirements, user data, or evaluation findings.
This matters in CEN3722 because your project is assessed not only on the artifact but on the reasoning behind it. Reviewers, instructors, teammates, and future maintainers rarely have access to your hallway conversations; the document is the only durable evidence that your choices were deliberate rather than accidental. Deviations from the prototype are normal — time limits, technical constraints, and usability test results all force changes — but undocumented deviations look like mistakes, while documented ones look like engineering judgment.
The video below approaches documentation from the outcomes side rather than the screens side. As you watch, think about how you would phrase your own design decisions in terms of the user outcome each one was meant to produce, and how that framing would make the "tracing design decisions to outcomes" section of your report easier to write and easier for a reader to verify.
A short Nielsen Norman Group talk arguing that UX work is shifting from designing a single fixed interface toward defining the outcomes a user needs to achieve, with the interface being one of several possible means to that end. Based on its title and description, it likely contrasts interface-first thinking with outcome-first thinking and discusses what this shift means for designers working with AI-driven systems. Expect a conceptual framing piece rather than a step-by-step documentation tutorial.
NN/g is a well-established authority in usability research, and the outcome-oriented framing maps directly onto the "tracing design decisions to outcomes" subtopic, giving you vocabulary for stating what each implementation decision was intended to accomplish for the user.
The video supports MO3 most directly: by framing design work around intended user outcomes rather than screens, it models the kind of justification language you need when connecting implementation decisions to HCI principles, user data, and project requirements. It also feeds MO1, since a section of your design document must record decisions and their rationale in a form a reader can audit, and MO2, because outcome statements are a concise, structured way to present design rationale in professional technical writing. Use it as a framing lens, then apply your course materials and project artifacts to write the concrete interface description and deviation log.
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.