An HCI development report is the written record that accompanies an interface project from first requirements to final evaluation. It is not a diary of everything you did; it is a structured, selective account of what you set out to build, what you learned about users, which design decisions you made, and what evidence supports those decisions. In professional practice this document is read by teammates, managers, clients, and sometimes auditors or future maintainers, so it has to stand on its own after you have left the room.
In this course the report matters for two reasons. First, it is how you demonstrate that your project decisions were reasoned rather than accidental — a claim like "we moved the checkout button" is only credible when it is tied to a usability finding or an HCI principle. Second, the report is itself a design artefact: it captures traceability, showing a reader the chain from requirement to design to evaluation to revision. Audience and tone follow from that purpose, since a report written for a mixed technical and non-technical readership must explain jargon, lead with findings, and keep the evidence visible.
The three videos below are short, practice-oriented pieces from Nielsen Norman Group. As you watch, do not look for a report template; look for how experienced practitioners frame design work for an audience. Notice what they choose to include and leave out, how they move from user problem to decision to outcome, and how evaluation methods produce the kind of findings you will later need to cite in writing.
This video covers how to present a UX case study to an interview audience: what to include, how to sequence the story of a project, and how to make your own contribution and reasoning visible. Based on its title and description, it focuses on showcasing skills and experience by walking an audience through a piece of design work. Expect guidance on framing the problem, the process, and the results rather than simply displaying screens.
A case study is the spoken cousin of a development report, so this is a direct model for the purpose, audience and tone subtopics — it shows how to pitch design reasoning to a reader or listener who was not involved. Nielsen Norman Group is a long-established UX research and training organisation, which makes the advice reliable professional practice rather than opinion.
This video explains the cognitive walkthrough, a task-based usability inspection method used to judge how learnable an interface is for a first-time user. It describes the general procedure of stepping through tasks and asking structured questions about whether users would know what to do and recognise progress. The result is a set of specific, task-linked learnability problems.
Evaluation methods like this are what generate the findings a development report has to record and justify decisions against, so it supports the idea of the report as a traceable design artefact. It also gives you concrete, citable evidence language — problems tied to tasks and steps — rather than vague impressions.
This video treats video game design as a special case of user interface design, highlighting where game user goals differ from productivity software and where usability principles still apply. It is likely to discuss how deliberate challenge and discovery change what counts as a design problem. The comparison makes the underlying HCI principles more visible by testing them against an unusual context.
It reinforces that design decisions must be justified against stated user goals and context, which is exactly the argument structure a development report needs. Reading design through a contrasting domain helps you write justifications that name the principle and the context instead of asserting that something is simply good design.
Together these videos support the module outcomes by modelling how design work is communicated and evidenced. The case study video speaks to MO2, offering a professional template for structuring and pitching a project narrative to a defined audience. The cognitive walkthrough video feeds MO1 and MO3, showing how an inspection method produces specific evaluation findings and iteration triggers that belong in the design document and can be cited when justifying changes. The game design video strengthens MO3 by demonstrating that design choices are defensible only in relation to user goals and HCI principles. None of the videos is a writing guide, so use them as sources of reasoning and evidence that you then express using the report conventions taught in this module.
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.