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.
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.
Design process documentation is the written and visual record of how an interface came to be: the ideas you generated, the sketches and low-fidelity prototypes you tested, the reasoning behind each choice, the higher-fidelity versions you built, and the way all of this changed across iterations. In practice, a design document is not a scrapbook of pretty screens — it is an argument. It shows a reader what problem you were solving, what alternatives you considered, why you kept one and discarded others, and what evidence supported that call.
This matters in CEN3722 because your course project is judged largely through what you write about it. Graders, teammates, and future maintainers cannot watch you work, so your report must make the invisible parts visible: the discarded concepts, the trade-offs, the usability findings that forced a redesign. Clear documentation of design rationale is also what separates a defensible HCI decision from a personal preference.
The three videos below come from practicing designers and from the Nielsen Norman Group. As you watch, pay attention to the artifacts each one produces at every stage — diagrams, annotated prototypes, specification notes, explanation slides — and ask how you would capture that same artifact in a section of your own report. Also notice how each speaker explains a choice to someone who was not in the room; that framing is exactly what your rationale sections need.
A working product designer walks through her end-to-end process using the Double Diamond framework, moving through discovery, problem definition, ideation, and delivery. Based on its title and description, it is a project-style walkthrough that shows how a real design effort progresses rather than a purely theoretical lecture, and it acknowledges that the process varies from project to project. Expect to see the stages where concepts are generated and narrowed, and the artifacts that result from each phase.
It gives you a concrete, named structure (Double Diamond) for organizing the narrative of your design process section, which directly supports documenting concept generation and capturing design evolution across iterations.
This short Nielsen Norman Group video introduces three types of prototype specifications — element, functionality, and content — as a way to document the details of a prototype. It explains what each specification type captures and why written specs are needed alongside the prototype itself, since a visual artifact alone rarely communicates intended behavior. At under four minutes it is dense and directly practical.
NNgroup is a widely cited authority in usability, and this is the most directly on-topic piece for describing low- and high-fidelity prototypes in writing — it gives you vocabulary and categories you can use as headings in your own prototype documentation.
This video addresses what to do with a large, messy sandbox of ideas: how to organize design explorations and present them to others for feedback. Judging from the title and description, it covers selecting and grouping explorations, structuring them for an audience, and framing them so reviewers can respond productively rather than being overwhelmed by raw variations. It is aimed at the moment between generating many concepts and committing to one.
Presenting explorations for feedback is essentially the live version of writing design rationale, so this video models how to justify and compare alternatives — the core skill behind the concept generation and design rationale subtopics.
Together these videos trace the arc your module asks you to document. The Double Diamond walkthrough supplies an overall process narrative and the record of how a design evolved from problem to solution, which feeds the iteration history required by MO1. The exploration-organization video models how to select among alternatives and explain those choices to an audience, which is the habit behind MO3's requirement to justify decisions rather than merely report them. The NNgroup video on prototype specifications supplies precise, structured conventions for describing prototypes in writing, supporting both MO1's record of design decisions and MO2's emphasis on clear, professional technical reporting. Watch them with your own project document open and note which section each idea belongs in.
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.
Evaluation documentation is the part of an HCI report that makes your usability work verifiable. It records what you did (the method, the participants or evaluators, the tasks, the setting), what you found (the specific problems, with evidence and severity), and what you changed as a result (the design iterations your findings triggered). Without this record, evaluation results become opinion; with it, they become justification that a reader can trace from a user's struggle to a concrete design decision.
In this course, the evaluation section is where your project report earns its credibility. Your audience — instructors, teammates, and in professional practice, stakeholders and developers — needs to know how confident to be in each finding and what to prioritize first. That requires writing methodology precisely enough to be repeated, reporting findings in a structured and rated way rather than as a loose list of complaints, and stating honestly what your evaluation could not tell you.
The three videos below come from the Nielsen Norman Group and cover complementary pieces of this workflow: running and recording a heuristic evaluation, rating and reporting findings by severity, and reasoning about the limits of small-sample testing. While watching, note the vocabulary each video uses for method steps and severity criteria — borrow that vocabulary for your own report — and keep asking: what would I need to write down during this activity so that someone reading my report later could follow my reasoning?
A short walkthrough of how to run a heuristic evaluation: systematically reviewing an interface against established usability heuristics to surface potential problems before or alongside user testing. Based on its title and description, it likely covers who should evaluate, how to work through the product in a structured way, and how individual evaluators' findings are combined. Treat each step it names as something you should be recording in your methodology section.
It gives you a concrete, named evaluation method to document accurately, and Nielsen Norman Group is the organization that originated the heuristic evaluation technique, so the terminology you pick up here will match what professional reports and your course readings use.
This video explains how to assign severity ratings to usability problems found in testing or heuristic evaluation, using a small, consistent set of criteria. It addresses the reporting stage directly: once you have a list of issues, how do you communicate which ones matter most. Expect discussion of the factors that push an issue up or down the priority scale.
Presenting findings and linking them to design iterations both depend on prioritization — this video supplies a defensible rating scheme you can cite in your report so that your choice of what to fix first looks reasoned rather than arbitrary.
This talk responds to the common stakeholder objection that five test users cannot represent all customers and that acting on such limited data is risky. It discusses what small-sample qualitative testing can and cannot support, and how to weigh limited evidence against the alternative of shipping with no evidence at all. It frames evaluation limitations as something to state and reason about rather than hide.
It maps directly onto the reflecting-on-limitations subtopic, giving you language for writing an honest limitations paragraph that acknowledges sample size and generalizability without undermining the value of your findings.
Together these videos supply the raw material for the evaluation portion of your design document (MO1): a documentable method in the heuristic evaluation walkthrough, a structured way to present and prioritize findings via severity ratings, and a model for writing a limitations section. The severity and method vocabulary supports the technical writing conventions emphasized in MO2, giving you consistent, professional terms instead of informal descriptions of problems. And because severity ratings and an honest account of evaluation scope are exactly what let you argue why one issue was fixed in the next iteration and another was deferred, these videos directly feed the evidence-based justification of design choices required by 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.
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.
When you submit a group development report, your instructor is reading two things at once: the quality of the interface you designed, and the quality of the process your team used to get there. This topic focuses on the second part — how to document who did what, how decisions were made collectively, and how the project was planned and tracked over the term. Good collaboration documentation is specific and verifiable: it names roles, points to artifacts (meeting notes, task boards, design critiques, version histories), and explains how individual contributions fit into the whole.
There are four things a strong report usually covers. First, team roles and responsibilities — who owned research, wireframing, prototyping, usability testing, and writing, and how overlaps were handled. Second, the collaborative design process — how the team moved from research to sketches to prototypes to evaluation, and where group critique or shared decision-making changed the design. Third, project management activities — scheduling, task assignment, milestones, risks, and how scope was adjusted. Fourth, reflection — an honest account of what worked in the group process and what you would do differently.
The videos below come at this from two angles. Two are project management tutorials that give you concrete, reusable structures for recording responsibility and project scope; the third walks through a UX design process end to end, which is the kind of narrative your report needs to tell. As you watch, pay less attention to the specific tools being shown and more to the structure: what categories of information are captured, what level of detail is useful, and how each artifact could become a labeled section or table in your own group report.
A short, practical explanation of the RACI matrix — a chart that labels each person on a task as Responsible, Accountable, Consulted, or Informed. The video defines the four roles and, based on its description, walks through worked examples of assigning task roles across a project team. It is aimed at project managers who need to remove ambiguity about ownership.
RACI is one of the cleanest formats for the "Documenting Team Roles and Responsibilities" subtopic, since it forces you to distinguish doing the work from owning the outcome — exactly the distinction a group report needs to make. TeamGantt is an established project management software company, so the treatment is standard and industry-aligned rather than idiosyncratic.
This tutorial explains what a project brief is, how it is used in project management, and what sections it should contain, with a downloadable template and examples referenced in the description. Expect coverage of elements such as objectives, scope, deliverables, stakeholders, timeline, and success criteria. It is pitched at someone writing the document for the first time.
It models the structured, section-based technical writing your development report requires, and the brief's components map directly onto the project management activities (scope, milestones, deliverables) you are asked to document. Having a concrete template makes it easier to see what level of detail counts as professional documentation.
A designer narrates the UX design process step by step using a real mobile app project as the running example, moving through the typical stages from problem framing and research to wireframes, prototypes, and refinement. Because it follows one project throughout, it shows how each stage feeds the next rather than treating the steps as isolated. It is a widely viewed overview from a practicing designer's perspective.
It gives you a model for the "Describing Collaborative Design Processes" subtopic — a clear narrative of how a design moved from stage to stage, which is the shape your process section should take. Watching someone explain their own decisions also previews the reflective, justify-your-choices voice expected in the report.
Together these videos supply the process and documentation vocabulary behind the module outcomes. The RACI and project brief tutorials give you concrete, standard structures for recording responsibilities, scope, and milestones, supporting MO1's requirement that the design document capture the full project history and MO2's emphasis on clear, structured, professional technical writing. The UX process walkthrough models how to narrate a design from research through iteration, which is the backbone of both the iteration history in MO1 and the connection of decisions to user data and requirements in MO3. Use them as templates to adapt, then make your group's own roles, meetings, and design decisions the actual evidence in your report.
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.
An HCI development report is more than a collection of findings — it is a document that a reader who was not part of your project should be able to pick up and follow from problem statement to design decisions to evaluation results. That readability comes from structure: a predictable sequence of sections (introduction, methods, findings, discussion, conclusion, references, appendices), each doing a distinct job, with transitions that carry a single argument across them. In this course, your project report is the main artefact that records what you designed, why you designed it that way, and what users told you.
Two supporting skills make that report credible. The first is referencing: when you claim that your layout follows a usability heuristic or that your task-completion metric is a standard measure, you must point to the source, both in the text and in a reference list. The second is presentation — consistent headings, readable typography, properly numbered and captioned figures, screenshots, wireframes, and tables that are referred to in the prose rather than dropped in silently.
The three videos below cover these skills from complementary angles: general report structure, APA formatting of a full document, and the mechanics of in-text citation. While watching, note the function of each section rather than just its name, and pay attention to the small conventions — caption placement, citation punctuation, heading levels — that distinguish a professional report from a rough draft. Also check your assignment brief, since your instructor may specify a referencing style or section list that differs from the examples shown.
A six-minute Scribbr walkthrough of formatting a complete paper in APA 7th edition, covering the title page, running head and page numbers, abstract, body text, headings, and the reference list. It demonstrates the formatting choices concretely rather than just describing them.
It maps onto the Presentation and Formatting Standards subtopic by showing a full document being formatted consistently end to end, which is exactly the level of polish expected in a submitted HCI report.
A focused Scribbr explainer on APA in-text citations: what information an in-text citation must contain, where it goes within a sentence, and how to handle awkward cases such as missing authors or dates. It also illustrates the relationship between the in-text citation and the full reference entry.
Accurate in-text citation is the core mechanic of the Academic Referencing subtopic, and Scribbr is a widely used, reliable source for current APA 7th edition rules.
A short tutorial from a university study-skills team walking through the key sections of an academic or technical report and what each one is for. Based on its title and description, it covers the standard structure students are expected to follow — elements such as the title page, introduction, main body, conclusions and recommendations, references, and appendices — and how the sections fit together.
It directly addresses the Standard Report Structure and cohesive-narrative subtopics, and comes from a university learning service, so the conventions it presents are the ones assessors typically expect.
Together these videos give you the writing conventions needed to turn project work into a submittable document. The report-structure tutorial supports MO1 and MO2 by showing where requirements, design decisions, evaluation findings, and iteration history belong within a conventional section sequence. The APA formatting video reinforces MO2 by modelling consistent, professional presentation across a whole document, including headings and reference lists. The in-text citation video supports MO3, since justifying design choices against HCI principles and published guidance requires you to cite those sources correctly in the body of your argument rather than asserting them.
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.