Requirements documentation is the written record of what a system must do, how well it must do it, and why those decisions were made. In HCI work this record begins with user research: who the users are, what they are trying to accomplish, and what problems they currently face. From that evidence you derive functional requirements (specific behaviors and features the interface must support) and non-functional requirements (qualities such as responsiveness, accessibility, learnability, and error tolerance). You also capture design constraints — platform limits, standards, budgets, deadlines, accessibility rules — along with the rationale explaining where each constraint came from.
This matters in CEN3722 because your course project report has to do more than describe a finished interface. A reader should be able to trace a line from a research observation, to a stated requirement, to a design goal, to the design decision that satisfies it. When that chain is missing, design choices look arbitrary; when it is present, your report becomes a defensible argument supported by user data.
The three videos below come from the Nielsen Norman Group, a long-established UX research and consulting firm. As you watch, pay attention to three things: what information belongs in a written plan or spec versus what stays informal, how documentation survives in fast-moving project settings, and how precise language reduces ambiguity for the people who have to build and evaluate the design. Try to map each practice you see onto a section of your own project requirements document.
A short overview of why user research should begin with a written research plan, and what a reusable plan template typically forces you to specify before data collection starts — things like objectives, questions, participants, and method. The video frames the plan as a document that keeps a study focused and prevents important details from being overlooked. It is aimed at practitioners preparing to run a study rather than at analyzing results.
It directly supports the Documenting User Research subtopic by showing that research documentation starts before the sessions, and the template-driven approach it describes is a model you can adapt for the research section of your project report.
This video discusses UX documentation as organizational memory — the record of processes and design decisions that lets a team remember why things were done a certain way. It addresses the tension between Agile's preference for minimal documentation and the real need to preserve decisions and their reasoning. Expect guidance on keeping documentation lightweight but still useful over time.
Its focus on recording design decisions and their reasoning maps onto the Rationale for Design Constraints subtopic and reinforces why your report must explain the why, not just the what.
An introduction to design specifications: the detailed written and visual statements that tell developers how a design should behave. The description points to specs covering layout, interactions, and related details, and frames missing specs as a common reason designs get rejected in development review. The video explains what a solid spec needs to contain to be actionable.
Specs are where functional and non-functional requirements become concrete and testable, making this a practical illustration of Stating Functional and Non-Functional Requirements and of linking stated requirements to what actually gets built.
Together these videos give you models for the requirements portion of your HCI design document (MO1): the research plan shows how to document the user research that justifies your requirements, the design spec video shows how to state system behaviors and qualities precisely enough to build and test against, and the Agile documentation video shows how to preserve decision history across iterations. All three emphasize structured, purpose-written documents over ad hoc notes, which reinforces the technical writing conventions expected in your development reports (MO2). Most importantly, the recurring theme of recording rationale and organizational memory supports MO3 by training you to connect each documented design choice back to user data, HCI principles, and the stated project requirements.
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.