↑ HCI Design Documentation and Development Reporting

HCI Design Documentation and Development Reporting

Introduction to HCI Development Reporting

1

Introduction to HCI Development Reporting

▶

An HCI Development Report is a structured, formal document that records every significant stage of a human-computer interaction design project, from the earliest identification of user needs through to the final evaluation of a working prototype. Unlike an informal lab notebook or a reflective journal, the development report is written for an external audience and must stand on its own as a complete, self-contained account of the design process. Understanding what the report is for, who will read it, and what role it plays in the broader design workflow is essential before a single word of it is written.

The importance of this kind of document extends well beyond the immediate project. It creates a permanent, inspectable record that connects every design choice to the evidence and reasoning that motivated it. When a team decides to adopt a tabbed navigation structure rather than a hamburger menu, or to increase font size after a usability test revealed readability problems, those decisions must be traceable in the report. A reader who has never encountered the project should be able to follow the chain from a stated user requirement through a design decision and on to an evaluation finding that either validates or challenges that decision. This traceability is the defining characteristic of a professional HCI report and what distinguishes it from a simple project summary.

Purpose of an HCI Development Report

At its most fundamental level, the report serves three interconnected purposes. First, it functions as a traceable document that links design decisions to user requirements and evaluation outcomes. Every interface choice documented in the report should be anchored to something observable: a requirement gathered from user interviews, a finding from a heuristic evaluation, a pattern identified during prototype testing. This anchoring prevents design decisions from appearing arbitrary and demonstrates that the team was responding to real evidence rather than personal preference.

Consider a concrete example. Suppose a team is designing a mobile application for elderly users managing medication schedules. During requirements gathering, interviews reveal that users struggle with small touch targets. The team responds by adopting larger buttons with a minimum tap area of 44 × 44 pixels. In the report, this decision should appear with an explicit reference to the interview findings, possibly cross-referenced to an appendix containing interview transcripts or a summary table of user needs. Later, if usability testing confirms that tap errors have decreased, that evaluation outcome should be linked back to the same decision. The reader can then trace a complete arc: user need → design response → evaluation outcome. Without this traceability, the report fails its primary purpose.

Second, the report demonstrates professional practice. HCI as a discipline has established methodologies — user-centred design, iterative prototyping, formative and summative evaluation — and a professional report shows that the team applied these methodologies systematically rather than improvising. Stakeholders reading the report — whether they are academic assessors, client organisations, or future team members inheriting the project — use it to judge whether the design process was conducted rigorously. A report that skips from initial sketches directly to a final prototype, with no account of user involvement or iterative refinement, signals poor professional practice regardless of how polished the final interface looks.

Third, the report gives stakeholders a basis for assessing the quality of the HCI process independent of the product itself. An interface might appear clean and attractive, but if the report reveals that no user testing was conducted, or that accessibility needs were never considered, informed stakeholders will rightly question whether the design would actually perform well in real use. Conversely, a report that meticulously documents iterative testing, identifies limitations honestly, and proposes well-reasoned future improvements inspires confidence even if the prototype is not yet fully polished. The report and the prototype together constitute the deliverable; neither is sufficient alone.

Audience and Tone

Identifying the audience correctly shapes every aspect of how the report is written. HCI development reports are typically addressed to readers who possess a working knowledge of HCI principles and terminology — they will understand terms such as affordance, cognitive load, Fitts's Law, or think-aloud protocol without requiring definitions. However, they will not be familiar with the specific project, its particular users, the organisation it serves, or the design rationale that emerged during the team's work. This means the writer must strike a careful balance: use professional vocabulary confidently, but never assume the reader shares background knowledge about the project itself.

The tone must remain formal and objective throughout. This applies even when describing activities that are inherently exploratory or iterative, such as brainstorming sessions, paper prototyping, or early-stage user walkthroughs. It is natural for design work to involve uncertainty, false starts, and revision, and the report should not pretend otherwise — but it must describe these activities analytically rather than anecdotally. The difference can be illustrated by contrasting two ways of describing the same event:

  • Inappropriate (informal, first-person): "We tried a dropdown menu but users hated it, so we changed it to radio buttons."
  • Appropriate (formal, objective): "Initial evaluation of the dropdown implementation revealed that three of five participants were unable to locate the correct option within the allotted time. The interface was subsequently revised to present the same choices as a set of visible radio buttons, reducing the interaction to a single step."

The second version conveys the same events but does so with precision, quantification where possible, and no reliance on subjective language. It also eliminates first-person reference. Most HCI development reports are written in the third person or in the passive voice to maintain this formal register. References to the team should use constructions such as "the design team," "the developers," or passive constructions such as "a decision was made to..." or "the prototype was revised to..." This is not mere stylistic convention; it signals that the decisions described belong to a professional process, not to individual personalities, and makes the document easier to read critically and objectively.

Consistency of tone also matters across sections. The introduction, the methodology description, the evaluation findings, and the conclusions should all feel like they come from the same document. A common error is to write the methodology section in careful formal prose and then slip into a more casual register when describing evaluation results or limitations. Readers notice this inconsistency, and it undermines the overall impression of professionalism.

The Report as a Design Artefact

One of the most important conceptual shifts required when approaching an HCI development report is to understand that the report is not merely a description of something that happened — it is itself a product of the design process and carries its own design obligations. A well-structured, coherent, and complete report demonstrates that the team followed a principled HCI methodology; a poorly organised or incomplete report creates doubt about whether that methodology was actually applied, regardless of what the text claims.

The report provides an auditable trail of decisions. The word "auditable" is significant: it means another competent practitioner should be able to read the report and not only understand what was done, but also assess whether it was done correctly, identify what was omitted, and potentially replicate the process with a different design team or in a different context. This is analogous to the role of a methods section in empirical research — it should be detailed enough to support scrutiny. An HCI report that describes its evaluation process only as "user testing was conducted" fails this standard; one that specifies the number of participants, their characteristics, the tasks they were given, the protocol followed, and the measures recorded meets it.

Completeness and coherence are therefore as important as the interface prototype itself. A development report might cover some or all of the following major components, depending on the scope of the project:

  • Project context and problem statement: What problem is being addressed, who the users are, and what constraints govern the design.
  • Requirements specification: Functional and non-functional requirements derived from user research, presented in a structured form.
  • Design rationale: An account of why particular design directions were chosen, often with reference to HCI principles, guidelines, or standards.
  • Prototype description: A detailed account of the prototype(s) produced, sufficient for a reader to understand what was built and at what fidelity.
  • Evaluation methodology and findings: A rigorous account of how the prototype was tested, what was found, and how findings were interpreted.
  • Iterative revisions: Documentation of how early designs were modified in response to evaluation findings.
  • Limitations and future work: An honest assessment of what was not achieved and what further design or evaluation work would be needed.

Coherence means that these components must connect logically. Requirements introduced early in the report should reappear in the evaluation section, where the reader learns whether they were successfully met. Design decisions documented in the rationale section should be reflected in the prototype description. If a section could be removed without affecting the sense of any other section, it is probably not well integrated and the report's coherence is weakened.

Finally, it is worth recognising that writing the report is not a task to be completed after the design work is finished. The best HCI development reports are built incrementally alongside the design process itself, with sections drafted and revised as each stage of the project is completed. This practice not only reduces the burden at the end of the project but also improves the quality of the documentation, since decisions and findings are recorded while they are fresh rather than reconstructed from memory. Treating the report as a living document — a genuine companion to the design work rather than a retrospective summary — is one of the clearest markers of professional HCI practice.

NotesEstablishes the purpose of professional HCI development reports and explains how they function as a traceable record of design decision-making from start to finish.
2

Videos on This Topic

▶

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.

3

Video 1: Presenting Your UX Case Study in an Interview

▶

NNgroup · 6:20 · 14,153 views · 1y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Cognitive Walkthroughs Help Assess Interface Learnability

▶

NNgroup · 4:45 · 14,522 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Video Game Design and User Experience

▶

NNgroup · 5:25 · 13,360 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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

1

Requirements Documentation

▶

Requirements documentation is the structured process of capturing everything discovered during the research and planning phase of a design or development project. It forms a foundation upon which all subsequent decisions rest. When done well, requirements documentation ensures that the final product genuinely addresses real user needs, operates according to defined behavioral expectations, respects realistic constraints, and pursues coherent design goals. Poor or incomplete documentation at this stage leads to misaligned solutions, costly redesigns, and outcomes that fail users. This section explores each major component of requirements documentation in depth, with practical guidance and illustrative examples throughout.

Documenting User Research

The first responsibility of requirements documentation is to provide a faithful, evidence-based account of the user research that was conducted. This section of a requirements document is not simply a list of conclusions — it must explain how those conclusions were reached and provide supporting evidence so that readers can assess the quality and credibility of the findings.

Specifying and justifying the research method is the logical starting point. Different research methods are suited to different situations, and your documentation must make the choice transparent. Common methods include semi-structured interviews, contextual inquiry, surveys, diary studies, focus groups, and usability walkthroughs. For each method used you should state what it is, why it was selected over alternatives, and why it was appropriate for the specific target user group.

For example, if your target users are elderly residents using a healthcare portal, you might justify semi-structured interviews over an online survey by noting that the target group has lower digital literacy, that interviews allow the researcher to probe ambiguous responses, and that face-to-face interaction surfaces nuanced concerns that survey scales cannot capture. The justification should be specific to your users — not a generic statement that "interviews are a good method."

Once the method is explained, the documentation must summarize key user needs and pain points. A pain point is a specific problem, frustration, or barrier that users currently experience. A user need is a goal or requirement that, if met, would meaningfully improve the user's experience. Both must emerge from the research data rather than from the team's assumptions.

A well-structured summary might look like the following:

  • Need: Users need to locate appointment information without navigating more than two levels deep in the menu hierarchy.
  • Pain point: Participants repeatedly struggled to locate the prescription renewal page, often abandoning the task within ninety seconds.
  • Need: Users with low vision need text to be resizable without breaking the page layout.
  • Pain point: Several participants described feeling "overwhelmed" by the volume of notifications presented simultaneously on the dashboard.

Critically, each stated need or pain point should be supported by anonymized evidence drawn directly from the research. Anonymized data samples may include paraphrased observations, behavioral counts, or direct quotes with identifying details removed. Evidence anchors the documentation in reality and prevents the team from projecting its own assumptions onto users.

Examples of how evidence might be presented:

  • Direct quote (anonymized): "I just give up and phone them. I can never find what I'm looking for on the website." — Participant 4, aged 71, healthcare portal study.
  • Behavioral observation: Six of eight participants attempted to use the browser's back button to return to the home screen, rather than the in-application navigation, suggesting that the navigation structure does not match users' mental models.
  • Survey data: 74% of respondents rated "finding account information quickly" as their top priority when using the platform.

When multiple research methods were used — for example, initial interviews followed by a validation survey — each method should be documented separately with its own justification, findings, and evidence.

Stating Functional and Non-Functional Requirements

Requirements are formal statements that define what a system must do or how it must perform. They translate user needs and research findings into actionable specifications that designers and developers can work from. There are two principal categories: functional requirements and non-functional requirements. Both must be documented with precision.

Functional requirements specify a discrete system behavior or capability — that is, something the system must do. Each functional requirement should be written as a single, unambiguous statement that describes one specific behavior. Compound requirements that bundle multiple behaviors together are difficult to test and trace, and should be broken apart.

Functional requirements are typically written in one of two standard forms:

  • The system shall… form: "The system shall allow a registered user to reset their password via a link sent to their registered email address."
  • User story form: "As a returning user, I want to be able to view my last three prescriptions so that I can identify which medication I need to reorder."

The following table illustrates a small set of numbered functional requirements for a hypothetical healthcare portal:

Ref Functional Requirement Source (User Need)
FR-01 The system shall display all upcoming appointments on the user's dashboard without requiring further navigation. UN-02: Users need appointment information accessible within one click of login.
FR-02 The system shall allow users to request a prescription renewal through a form accessible from the dashboard. UN-05: Users need to initiate prescription renewals without phoning the clinic.
FR-03 The system shall send the user an email confirmation within five minutes of a successfully submitted appointment request. UN-08: Users need assurance that booking requests have been received.
FR-04 The system shall allow users to filter their appointment history by date range and appointment type. UN-03: Users need to locate historical appointment records efficiently.

Notice that each requirement is numbered. Numbering requirements is essential for traceability — it allows design decisions, prototypes, and evaluation findings in later sections of a project to reference the specific requirement they address or test. Without numbering, it becomes impossible to demonstrate that requirements have been fulfilled or to identify which requirements remain unmet.

Non-functional requirements define the quality attributes of a system — how well it performs its functions rather than what functions it performs. They typically address performance, accessibility, reliability, security, usability, scalability, and compliance. The critical rule for non-functional requirements is that they must reference measurable criteria wherever possible. Vague statements such as "the system should be fast" or "the interface should be accessible" provide no basis for testing or verification.

Compare these two formulations:

  • Weak (unmeasurable): "The system should load quickly."
  • Strong (measurable): "NFR-01: All primary page views shall load within 2.5 seconds on a standard broadband connection (minimum 10 Mbps) under normal server load conditions."

A further set of examples illustrates the range of non-functional requirements and how measurability is applied:

Ref Non-Functional Requirement Category
NFR-01 All primary page views shall load within 2.5 seconds under normal network conditions (10 Mbps broadband). Performance
NFR-02 The interface shall conform to WCAG 2.1 Level AA accessibility guidelines in its entirety. Accessibility
NFR-03 All user-entered personal data shall be encrypted in transit using TLS 1.2 or higher. Security
NFR-04 The system shall achieve a minimum System Usability Scale (SUS) score of 70 in user testing with the target demographic. Usability
NFR-05 The system shall maintain 99.5% uptime measured across any rolling 30-day period, excluding scheduled maintenance windows. Reliability

Where a precise numerical target is genuinely not yet determinable, the documentation should at minimum specify the measurement instrument or evaluation method that will be used to assess it, and flag that the threshold will be set once baseline data is collected.

Rationale for Design Constraints

Design constraints are conditions that limit how the system can be designed or built. They are distinct from requirements in an important way: requirements define what the system must achieve, while constraints define boundaries within which those achievements must be made. Confusing the two leads to documentation that is unclear about what is aspirational versus what is fixed.

Constraints typically arise from four sources:

  • Technical constraints: The existing technology stack, platform compatibility requirements, or infrastructure limitations. For example: "The solution must be deployable as a responsive web application compatible with Google Chrome, Firefox, and Safari, as these are the browsers supported by the organization's IT policy."
  • Legal and regulatory constraints: Statutory requirements such as data protection law (e.g., GDPR in the UK/EU), healthcare information regulations, or copyright restrictions.
  • Organizational constraints: Budget ceilings, staffing limitations, existing supplier relationships, or mandated use of a specific content management system.
  • Standards-based constraints: Requirements to comply with recognized external standards. Referencing authoritative standards — such as the Web Content Accessibility Guidelines (WCAG), ISO 9241 for usability, or BS 8878 for web accessibility — adds credibility and situates the constraint within an established professional framework rather than presenting it as an arbitrary internal rule.

For each constraint, the documentation should explain:

  • What the constraint is and where it originates
  • Why it is a constraint rather than a requirement (i.e., it limits the solution space rather than specifying desired behavior)
  • How it will affect subsequent design decisions

For example, an accessibility constraint might be documented as follows:

Constraint C-01: The interface must conform to WCAG 2.1 Level AA. Source: Organizational policy mandated by the client's public sector equality duty under the Equality Act 2010 and the Public Sector Bodies Accessibility Regulations 2018. Impact on design: All color choices must achieve a minimum contrast ratio of 4.5:1 for standard text and 3:1 for large text. Interactive elements must be operable by keyboard alone. All images must include descriptive alternative text. These constraints will influence color palette selection, component design, and content authoring guidelines throughout the design phase.

Acknowledging the impact of each constraint on subsequent design decisions is particularly important. It demonstrates that the team has genuinely thought through the practical implications rather than listing constraints as an afterthought. Where constraints are in tension with one another — for example, a strict brand color palette conflicting with WCAG contrast requirements — the documentation should acknowledge this tension and indicate how it will be resolved.

Referencing recognized standards such as WCAG is valuable not only for credibility but also because it ties the constraint to an objective, testable benchmark. Instead of defending an accessibility decision on the basis of personal judgment, the team can point to a defined, publicly available standard that specifies exact success criteria.

Linking Requirements to Design Goals

Requirements documentation does not conclude with lists of requirements and constraints. A critical final element is the articulation of design goals — high-level objectives that translate user needs and requirements into the positive outcomes the design is intended to achieve. Design goals give the project team a shared sense of purpose and provide explicit criteria against which later design and evaluation work can be assessed.

The relationship between user needs, requirements, and design goals should be direct and demonstrable. A design goal that cannot be traced back to a user need or stated requirement is a signal that it may reflect the team's preferences rather than genuine user-centered thinking. Conversely, a user need that does not give rise to at least one design goal suggests that the need may have been identified but not actually addressed in the design response.

Design goals must be specific enough to evaluate against in later testing phases. Broad statements like "create a pleasant user experience" are of limited value because they cannot be measured. Well-formed design goals specify the user group, the context, the behavior, and an implied or explicit success criterion.

Consider the contrast between vague and well-formed design goals:

  • Vague: "Make the portal easy to use."
  • Well-formed: "Enable users aged 60 and over to locate and request a prescription renewal within 90 seconds of logging in, without requiring assistance."

The following table demonstrates how a chain of traceability might be documented, linking user needs through requirements to design goals:

User Need Requirement(s) Design Goal Evaluation Method
UN-02: Users need appointment information accessible within one step of login. FR-01 DG-01: The dashboard shall surface all upcoming appointments without requiring sub-navigation, enabling users to read appointment details within 10 seconds of login. Task-based usability test: time-on-task and success rate measured during prototype evaluation.
UN-05: Users need to initiate prescription renewals without phoning the clinic. FR-02 DG-02: Users shall be able to complete a prescription renewal request entirely within the portal with no need for telephone contact. Observation during usability test; post-task questionnaire.
UN-07: Users with low vision need text to be resizable. NFR-02, C-01 DG-03: The interface shall remain fully functional and readable when browser text size is increased to 200% without horizontal scrolling. WCAG 2.1 Success Criterion 1.4.4 automated and manual audit.

Documenting this linkage explicitly — rather than leaving it implicit — serves several important purposes. It demonstrates that design decisions were user-centered rather than arbitrary, providing an auditable rationale for why particular choices were made. It enables evaluators and stakeholders to verify that all identified needs have been addressed in the design. It also creates a contractual-style accountability within the project: each design goal effectively commits the team to achieving a defined outcome that can be tested.

In practice, the complete requirements document — covering user research, functional and non-functional requirements, constraints, and design goals — becomes the single most referenced artefact throughout the rest of a design project. Designers return to it when making decisions, evaluators reference it when constructing test tasks, and stakeholders use it to assess whether the delivered solution fulfils the original brief. Investing care and precision in its construction pays dividends at every subsequent stage.

NotesCovers all four major subtopic clusters for Topic 1: documenting user research (method justification, needs/pain points, anonymized evidence), functional and non-functional requirements (discrete behaviors, measurable criteria, numbering for traceability), rationale for design constraints (distinguishing from requirements, source and impact, standards references), and linking requirements to design goals (derivation from user needs, specificity for evaluation, demonstrating user-centered rationale). Tables are used for requirements lists and traceability mapping. Examples are drawn from a consistent healthcare portal scenario for coherence.
2

Videos on This Topic

▶

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.

3

Video 1: Creating a UX Research Plan

▶

NNgroup · 4:21 · 39,204 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: UX Documentation in Agile

▶

NNgroup · 3:06 · 21,645 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: What are Design Specs?

▶

NNgroup · 3:43 · 2,845 views · 2mo ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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

1

Design Process Documentation

▶

Design process documentation is the practice of creating a comprehensive, evidence-based record of every meaningful decision, experiment, and iteration that shaped a product's development. Far from being a bureaucratic formality, good documentation serves multiple vital purposes: it makes your reasoning transparent to stakeholders and evaluators, it creates an institutional memory that helps teams avoid repeating mistakes, and it demonstrates the rigour of a human-centred design approach. A polished final interface tells you what was built; thorough process documentation tells you why it was built that way, and what was learned along the journey. The sections below address each major documentation responsibility in depth, from the earliest sparks of ideation through to the fully-realised high-fidelity prototype and the narrative thread that ties all iterations together.

Documenting Concept Generation

Concept generation is the creative engine of the design process, and documenting it well means capturing not just the outputs — the sketches, diagrams, or written descriptions of ideas — but also the process by which those ideas were produced and evaluated. Readers of your documentation should be able to understand exactly how your team moved from a problem statement to a shortlist of candidate designs.

Begin by naming and describing the ideation method your team used. Common methods include:

  • Brainstorming: A time-boxed session in which participants generate as many ideas as possible without immediate criticism, deferring judgement until a separate evaluation phase.
  • Crazy Eights: Each team member rapidly sketches eight distinct interface concepts in eight minutes, forcing divergent thinking by limiting reflection time.
  • How Might We (HMW) prompts: Problem statements are reframed as open questions (e.g., "How might we help a new user discover core features without a tutorial?") to stimulate solution-oriented thinking.
  • SCAMPER: A structured checklist (Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse) applied to existing designs to generate variants.
  • Analogical design: Drawing inspiration from solutions in unrelated domains (e.g., borrowing a "progressive disclosure" pattern from complex medical forms to simplify an onboarding wizard).

Naming the method alone is not sufficient. Explain why that method was appropriate for your project's stage, team size, and problem type. For example, Crazy Eights suits early divergent exploration within a team of two to six people, whereas a structured design studio with HMW prompts may be better suited to cross-functional groups that need to build shared understanding before sketching.

Next, describe the criteria used to assess initial concepts. Evaluation criteria should be defined before assessment begins so that selection is principled rather than swayed by whoever argued most persuasively in the room. Typical criteria include:

  • Feasibility: Can the concept be implemented with the available technology, time, and budget?
  • Desirability: Does the concept address real user needs identified in research (e.g., interviews, surveys, contextual inquiry)?
  • Usability: Does the concept align with established HCI principles such as learnability, efficiency, or error prevention?
  • Novelty or differentiation: Does it offer something meaningfully better than existing solutions?
  • Scope alignment: Does it fit within the defined project boundaries?

A useful documentation technique is a concept evaluation matrix, which makes the scoring of each concept against each criterion visible and auditable:

Concept Feasibility (1–5) Desirability (1–5) Usability (1–5) Scope Fit (1–5) Total
Dashboard with global search 4 5 4 5 18
Card-based activity feed 5 3 4 4 16
Wizard-style onboarding flow 3 4 3 2 12

Including a table like this in your report, alongside a brief narrative interpreting the scores, demonstrates that concept selection was a deliberate, criteria-driven process rather than a matter of preference or convenience.

Documentation of concept generation must also account for the human dynamics of the process. Describe how team members contributed: who sketched, who facilitated, who critiqued. In diverse teams, individuals often bring different domain knowledge, lived experience, or technical perspectives, and those differences frequently produce more innovative concepts than homogeneous groups. Explain how divergent ideas — concepts that pulled the design in different directions — were reconciled. Common reconciliation strategies include:

  • Dot voting: Each team member places a fixed number of sticky dots or votes on their preferred concepts, producing a rapid democratic ranking.
  • Affinity mapping: Individual ideas are grouped by theme so that clusters of related concepts can be considered together rather than as isolated proposals.
  • Weighted decision matrix: Criteria are assigned importance weights, and each concept is scored against each criterion; the weighted totals determine priority.
  • Synthesis: Elements from two or more competing concepts are merged into a hybrid that captures the strengths of each.

Finally, document which concepts were selected for further development and why others were discarded. The concepts that did not advance deserve as much explanation as those that did. A concept discarded because it was technically infeasible, too similar to a competitor's product, or incongruent with user research findings tells a clear story about the team's priorities and constraints. Avoid the temptation to document only winning ideas; the rejected concepts demonstrate critical thinking and honest evaluation.

Describing Low-Fidelity Prototypes

Low-fidelity (lo-fi) prototypes are deliberately rough, inexpensive representations of a design — typically paper sketches, wireframes, or cardboard mock-ups — created to test ideas quickly before significant resources are committed. Because they are cheap and fast to produce, lo-fi prototypes encourage experimentation: it is psychologically easier to discard a pencil sketch than a polished digital interface, and this freedom is genuinely productive.

The most important rule for documenting lo-fi prototypes is: include the artefacts themselves. A written description of a hand-drawn wireframe cannot substitute for an actual photograph or scan of that wireframe. Every lo-fi prototype should be represented visually in your report — either embedded in the main body if they are central to a narrative, or collected in an appendix if the volume would interrupt the flow of reading. The relationship between artefact and text should be bidirectional: the image should be numbered and captioned, and the surrounding text should explicitly reference that number (e.g., "Figure 3 shows the initial navigation sketch discussed in this section").

Annotations are what transform raw images into documentation. An annotated lo-fi prototype might call out:

  • The purpose of each region of the layout (e.g., "This left-hand panel was intended to persist across all views as a global navigation aid")
  • Design choices that were deliberately left vague at this stage (e.g., "The content of these cards was not specified; the sketch was testing layout density, not content strategy")
  • Elements that were known placeholders (e.g., "This box represents a search bar whose exact interaction model had not yet been decided")
  • Connections between screens, indicating how a user would navigate from one state to another

Beyond the artefact itself, documentation must explain the specific design question or hypothesis each prototype was created to explore. Lo-fi prototypes are most valuable when they are targeted — each one probing a specific uncertainty rather than attempting to represent the whole design. For example:

  • Prototype A explored whether a bottom navigation bar or a side drawer would feel more natural to users completing multi-step tasks on a mobile device.
  • Prototype B tested whether displaying item counts on navigation tabs helped or confused users when tasks were time-sensitive.
  • Prototype C examined whether a wizard-style sequential form was preferable to a single long scrolling form for users completing a complex registration process.

Framing each prototype as an answer to a design question — essentially a hypothesis test — shows that your prototyping was purposeful and intellectually disciplined, not simply "making something to look at."

Also document any informal feedback gathered during the lo-fi phase. This feedback might come from a quick hallway test, a five-minute desk critique with a colleague outside the project, or a brief walkthrough with one or two representative users. Even if no formal usability study was conducted at this stage, informal responses are data. Record:

  • Who provided the feedback (a team member, a potential user, a subject-matter expert) and in what context
  • What the feedback was — specific observations, confusions, or positive reactions — not just a general impression
  • How the feedback influenced subsequent design decisions

For instance: "When shown Prototype B, two colleagues who fit the primary user persona both attempted to click the tab count badges, expecting them to filter results. This unintended affordance prompted us to either make the badges interactive or remove them entirely, which we addressed in the next iteration." That kind of specific, actionable documentation demonstrates genuine responsiveness to evidence.

Documenting Design Rationale

Design rationale is the explicit explanation of why a design decision was made — the reasoning that connects a design choice to the values, evidence, or principles that justified it. It is arguably the most intellectually demanding aspect of process documentation, because it requires designers to step back from what they built and articulate the logic that drove each significant choice.

A foundational rule is: every significant design decision should be accompanied by a stated rationale. "Significant" does not mean every pixel; it means any decision that meaningfully affected the user's experience, the system's architecture, or the project's scope. Decisions about navigation structure, information hierarchy, input mechanisms, feedback modalities, error handling approaches, colour and typography systems, and interaction patterns all warrant rationale. Decisions about exact padding values or specific icon choices generally do not — unless they were the subject of deliberate experimentation or user feedback.

Rationale should be grounded in one or more of the following sources of authority:

  • User research findings: Decisions justified by what was learned about users in interviews, observations, surveys, or usability tests carry the strongest empirical weight. For example: "We placed the 'Save' action in the top-right corner of the form because three of five interview participants looked there instinctively when asked where they expected to save their work."
  • HCI principles and guidelines: Well-established frameworks — Nielsen's ten usability heuristics, Fitts's Law, the Gestalt principles of visual grouping, WCAG accessibility guidelines, or platform-specific design systems — provide principled, peer-reviewed justifications for many common decisions. For example: "Consistent with Nielsen's heuristic of visibility of system status, we added a progress indicator to the file upload component so users always know whether their upload is pending, in progress, or complete."
  • Both in combination: The strongest rationale often combines empirical and principled justifications. For example: "Consistent with the principle of recognition over recall (Molich & Nielsen, 1990), and supported by our observation that users in contextual inquiry rarely used keyboard shortcuts, we prioritised visible action buttons over a command-line interaction model."

A common failure in design documentation is describing what was designed without explaining why. Compare these two approaches:

  • Insufficient: "The navigation bar is pinned to the bottom of the screen on mobile."
  • Sufficient: "The navigation bar is pinned to the bottom of the screen on mobile because research by Hoober (2013) found that 49% of users hold their phone one-handed and operate it primarily with their thumb, making bottom-anchored controls significantly more reachable than top-anchored alternatives. This finding was reinforced during our lo-fi feedback session, where two participants instinctively swiped upward from the bottom of the screen when asked to navigate between sections."

The second version gives an evaluator or stakeholder everything they need to understand, and if necessary challenge, the decision. That intellectual accountability is exactly what design rationale documentation is meant to provide.

Describing High-Fidelity Prototypes

High-fidelity (hi-fi) prototypes are detailed, interactive, or near-production-quality representations of the design — typically built using tools such as Figma, Adobe XD, Axure, InVision, or even coded front-end implementations in HTML/CSS/JavaScript. They are visually polished, use real or realistic content, and simulate core interactions closely enough that users can engage with them much as they would with a finished product.

Documenting a hi-fi prototype begins with visual representation. Every key interface screen should be shown as an annotated screenshot. "Key" screens are those that represent distinct states of the interface: the landing or home view, the primary task flow, any modal dialogs or overlay panels, error states, empty states, and any screen that was the subject of a significant design decision or usability finding. Screenshots should be high resolution, cropped to remove distracting browser chrome unless that context is relevant, and presented at a size large enough to read labels and controls.

Annotations on hi-fi screenshots serve a different purpose than those on lo-fi sketches. Where lo-fi annotations explain intent and uncertainty, hi-fi annotations explain specific choices: why a particular visual hierarchy was established, why a specific component (e.g., a toggle rather than a checkbox) was used for a given interaction, why content was arranged in the order it was, or how the design handles edge cases. Annotations should be numbered and cross-referenced in the report body so that a reader can move fluidly between the screenshot and its written explanation.

One of the most analytically valuable sections of hi-fi documentation is a clear account of what changed between the lo-fi and hi-fi versions, and why. This comparison makes the design process legible. Changes might be structural (an entirely different navigation pattern), visual (a shift from a dark theme to a light one based on accessibility feedback), content-related (replacement of placeholder text with real microcopy informed by user testing), or interaction-related (changing a hover-triggered tooltip to a persistent inline label after testing showed hover was unreliable on touch devices). Each change should be linked explicitly to the evidence or reasoning that motivated it — a usability test finding, a heuristic evaluation, stakeholder feedback, or a technical constraint discovered during development.

Documentation should also describe the tools and technologies used to create the hi-fi prototype, including:

  • The primary design and prototyping tool (e.g., Figma for visual design and clickable prototyping)
  • Any component libraries or design systems used or referenced (e.g., Google Material Design, Apple Human Interface Guidelines, a custom design system)
  • Any plugins or extensions that extended the tool's capabilities (e.g., a Figma plugin for generating realistic data)
  • If the prototype was coded rather than click-through: the languages and frameworks used (e.g., HTML5, CSS with a framework such as Bootstrap or Tailwind, JavaScript with React), the development environment, and any backend or API integrations that were simulated or partially implemented
  • The fidelity level of the prototype — whether it was a static click-through, a partially interactive prototype with some live components, or a fully functional front-end connected to real data

Explaining the toolchain situates the prototype in a technical and methodological context, and helps readers understand what kinds of user testing the prototype was and was not capable of supporting.

Capturing Design Evolution

Design evolution documentation is the connective tissue of the entire process report: it shows how the design changed across iterations and, critically, why it changed. Without this narrative, a reader might encounter a polished hi-fi prototype and assume it emerged from a single inspired session — which would misrepresent both the design process and the value of the team's iterative work.

The most effective way to communicate evolution is through a structured narrative or visual timeline that traces the design's progression. A timeline can be presented as a written chronology ("In the first iteration, we explored... In the second iteration, informed by feedback from... we changed..."), as a visual artefact (a horizontal or vertical timeline with thumbnail images of the design at each stage and brief annotations), or as a comparative table:

Iteration Key Design Features Evidence / Feedback Received Changes Made
Lo-Fi v1 Top navigation bar; card grid layout; search in header Hallway test: users missed the search bar; cards felt too dense on mobile Moved search to a prominent floating action button; reduced cards per row on small screens
Lo-Fi v2 Floating search button; reduced card grid; larger tap targets Informal feedback: floating button obscured content when scrolling Replaced floating button with a persistent search bar at top; increased contrast on navigation
Hi-Fi v1 Persistent top search bar; two-column card grid; bottom tab navigation Formative usability test: three of five users failed to find the filter function; colour contrast failed WCAG AA Made filter controls visible in the search bar; revised colour palette to meet accessibility standards
Hi-Fi v2 (Final) Search bar with integrated filter chips; accessible colour palette; refined typography scale Final usability test: all five users completed primary tasks; no critical errors observed Minor microcopy adjustments; added empty-state illustration for no-results scenario

A table like this makes the relationship between evidence and action explicit and scannable. Readers can trace any specific design feature back through its history of change.

The essential discipline in capturing design evolution is to explicitly link each design change to the evidence or feedback that motivated it. This linkage is what transforms a list of changes into a demonstration of rigorous, evidence-driven practice. The connection between cause (feedback, testing finding, heuristic violation) and effect (design change) should be stated directly, not left for the reader to infer. Phrases such as "in response to," "because our usability test revealed," "following the observation that," and "to address the heuristic violation identified by" are all useful signals that you are making this causal relationship explicit.

Finally — and this is both a documentation principle and a reflection of genuine intellectual honesty — avoid presenting the design as if it emerged fully formed. A common temptation, especially when preparing a polished final report, is to narrate the process as a clean, linear journey from brief to solution. Real design work is messier: ideas are pursued and abandoned, assumptions are overturned by testing, technical constraints force rethinks, and team disagreements are resolved through compromise. Documenting this messiness — judiciously, with reflection rather than apology — is not a weakness. It is evidence that the team engaged seriously with the problem, took user feedback seriously, and treated the design as a hypothesis to be tested rather than a vision to be defended. Iteration is not a sign of failure; it is the mechanism by which design quality is achieved.

NotesThe concept evaluation matrix and design evolution table are provided as illustrative examples — teams should adapt column headers and criteria to suit their specific project context. Encourage students to gather and retain artefacts (photographs of sketches, exported wireframes, version-controlled Figma files) throughout the project, since retrospective documentation from memory is significantly weaker than documentation compiled contemporaneously.
2

Videos on This Topic

▶

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.

3

Video 1: My product design process – a walkthrough of the Double Diamond UX Design Process

▶

femke.design · 14:02 · 122,467 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Prototype Specifications: 3 Types

▶

NNgroup · 3:52 · 6,105 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: How to organize and present your design explorations for feedback

▶

femke.design · 13:46 · 35,189 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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

1

Evaluation Documentation

▶

Evaluation documentation is the formal record of how a usability evaluation was conducted, what was discovered, and how those discoveries shaped the design. It serves as evidence that the design process was grounded in real user behaviour rather than assumption, and it creates a traceable chain from observation to design decision. Strong evaluation documentation allows anyone reading the report — a collaborator, a client, an assessor, or a future team member — to understand exactly what was tested, who was involved, what happened, and what changed as a result. Done well, it transforms raw session notes and recordings into a coherent, reasoned account of a design's evolution.

Evaluation documentation typically covers four interconnected areas: the methodology used, the findings produced, the design changes those findings motivated, and an honest reflection on the evaluation's limitations. Each area requires a different kind of writing and a different kind of thinking, but together they form a complete picture of the evaluation cycle.

Documenting Evaluation Methodology

The methodology section answers the question: what did you do, and why did you do it that way? It is not sufficient to simply name the evaluation method. A reader needs to understand the method well enough to judge whether it was appropriate for the stage of design and whether the findings it produced are trustworthy. This requires three things: a clear definition of the method, a justification for its selection, and a precise description of how it was implemented.

Begin by naming and defining the evaluation method. Evaluation methods vary considerably in their assumptions, procedures, and outputs. A think-aloud usability test involves participants completing tasks while verbalising their thoughts, producing rich qualitative data about confusion and mental models. A heuristic evaluation involves trained evaluators inspecting an interface against a set of established usability principles, producing expert-judgement findings without direct user involvement. A cognitive walkthrough steps through a task sequence asking whether users would know what to do at each step. Each method has a distinct identity, and conflating them — or describing only part of one — leaves the reader unable to evaluate the work's rigour.

After defining the method, explain why it was appropriate at this particular stage of the project. Different evaluation methods suit different stages of development. Early in a project, when a prototype is low-fidelity or incomplete, heuristic evaluation can identify fundamental structural problems without the overhead of recruiting participants. Later, when a higher-fidelity prototype exists, think-aloud testing with representative users produces findings that reflect real-world behaviour more directly. If you used a think-aloud test with a paper prototype at mid-fidelity, say explicitly that you chose this method because the prototype was sufficiently interactive to support task completion but not so polished that participants would hesitate to criticise it. Justification is not padding — it demonstrates methodological awareness.

Next, describe the participants. This includes how many people took part, how they were recruited, what criteria qualified them for inclusion, and what ethical protocols were followed. Recruitment criteria might include factors such as prior experience with similar software, age range, accessibility needs, or domain expertise. Ethical protocols typically include obtaining informed consent, explaining the right to withdraw without consequence, clarifying that the evaluation tests the design and not the participant, and describing how data will be stored and anonymised. Even in a student or academic context these protocols matter, and omitting them from the documentation implies they were not followed.

An example participants description might read: Five participants were recruited through a university mailing list. Inclusion criteria required that participants used a smartphone for at least one hour per day and had made an online purchase within the previous three months. All participants provided written informed consent before the session began. They were informed that participation was voluntary and that they could withdraw at any time. No personally identifiable information was recorded; participants were assigned codes (P1 through P5) used throughout the data. This level of detail gives the reader confidence that the sample was purposeful and that ethical obligations were met.

Finally, specify the tasks, scenarios, or heuristics used. If you conducted user testing, list the tasks participants were asked to complete and include the exact wording used, since wording influences behaviour significantly. Vague instructions such as "find something to buy" produce different behaviour than precise ones such as "you want to purchase a medium blue cotton t-shirt for £25 or less — please find and add one to your basket." If you used scenarios, describe the fictional context you provided to ground the tasks in realistic motivation. If you conducted a heuristic evaluation, name the heuristic set used (for example, Nielsen's ten usability heuristics) and note any modifications. Including the actual task list or heuristic set as an appendix, with a summary in the main body, is good practice.

Presenting Evaluation Findings

The findings section is where raw data becomes meaningful. Its purpose is to communicate clearly and honestly what was observed and what that means, without conflating the two. The most important discipline in writing findings is the consistent separation of factual observations from interpretive conclusions. An observation is something that could have been captured on video: a participant clicked the wrong button, a participant paused for twelve seconds on a particular screen, a participant said "I'm not sure where to go from here." An interpretation is a claim about why that happened or what it means: the participant was confused because the call-to-action lacked visual prominence.

Mixing observation and interpretation without signalling the distinction makes findings harder to challenge, verify, or build on. The cleaner approach is to state the observation first, then offer the interpretation explicitly framed as such. For example: Three of the five participants attempted to use the search bar before noticing the category menu (observation). This suggests the search bar's position at the top of the viewport made it the dominant navigational affordance, while the category menu's location in the sidebar was not perceived as a primary entry point (interpretation).

Quantitative data should be presented with appropriate metrics. If you measured task completion, report the number and proportion of participants who completed each task successfully. If you recorded time-on-task, report median times rather than means when the sample is small, since means are distorted by outliers. Error frequencies — the number of times participants made a specific mistake — should be counted and reported per task. Presenting quantitative findings in a structured table makes patterns immediately visible.

Task Participants Completing (n=5) Completion Rate Median Time (seconds) Error Frequency
Find and add a product to basket 5 100% 42 2
Apply a discount code at checkout 3 60% 87 11
Locate the returns policy 2 40% 134 7

A table like this immediately communicates where the significant problems lie. A 40% completion rate on a task that should be straightforward, combined with high error frequency and long median time, signals a serious usability problem that warrants investigation and design response.

Qualitative feedback — verbal comments made during the session, answers to post-task questions, or responses in a debrief — should be used as supporting evidence for the interpretive claims you make. Participant quotes are particularly powerful because they convey the emotional and cognitive experience of using the design in the user's own words. However, they must be anonymised to protect participant privacy. Replace names and any identifying details with participant codes. A well-chosen quote can anchor an abstract finding in lived experience: "I didn't even notice there was a code field until I'd already clicked 'pay'" (P3). This quote, placed alongside the quantitative finding that only 60% of participants successfully applied a discount code, makes the problem vivid and credible without requiring the reader to imagine it.

Avoid cherry-picking quotes that support a predetermined conclusion. If participants gave contradictory feedback — some finding a feature useful, others finding it confusing — document both responses and reflect on what might explain the divergence. Honest presentation of mixed findings is a mark of methodological integrity.

Linking Evaluation Findings to Design Iterations

An evaluation report that stops at findings is incomplete. The purpose of evaluation in a user-centred design process is to inform design decisions, and the documentation must make those connections explicit. This section explains what changed in the design as a direct result of the evaluation, and why.

For each significant usability problem identified, describe the problem clearly, then describe the design change made in response. The description should be specific enough that a reader could look at the before and after states of the design and understand what changed and why. Vague statements like "we improved the checkout flow" are not sufficient. A clear statement looks like this: Three of five participants failed to locate the discount code field before completing payment (Task 2, 60% completion rate). In response, the discount code input was relocated from a collapsed accordion element beneath the order summary to a persistently visible field immediately above the payment button, accompanied by a label reading "Have a discount code? Enter it here." This statement names the problem, cites the evidence, describes the change, and implies the rationale — all in a single, traceable passage.

Not every finding will, or should, result in a design change. Resources are finite, some problems are minor, some fall outside the scope of the current iteration, and occasionally a finding reflects a participant characteristic rather than a genuine design flaw. When a finding did not produce a design change, document this explicitly and provide a reasoned justification. Silence is not justification. If you decided not to act on a finding, say so and explain why. For example: P2 expressed difficulty reading the body text and suggested increasing the font size. This was noted but not actioned in the current iteration because the existing font size (16px) meets WCAG AA contrast requirements and all other participants read the text without difficulty. The participant's comment may reflect individual visual acuity rather than a systemic design problem, but the finding will be monitored in future evaluations. This response shows that the finding was taken seriously, evaluated against evidence, and handled with appropriate caution rather than dismissed.

To reinforce traceability — the ability to follow a finding forward to a design decision and backward from a design decision to its evidential basis — use explicit cross-references between the evaluation and design sections of your documentation. Reference specific findings by task number, participant code, or finding identifier when describing design changes in the design iteration section. Conversely, in the evaluation findings section, note where a finding connects to a design iteration already documented elsewhere. This bidirectional referencing means that any reader entering the documentation at any point can navigate to the relevant evidence or decision without having to read the entire document linearly.

Cross-referencing also demonstrates that the design process was responsive rather than arbitrary. When a design change can be traced directly to an observed problem, it is much easier to defend that change to a stakeholder or assessor than when the rationale exists only in the designer's memory.

Reflecting on Evaluation Limitations

Every evaluation has limitations. A limitations section does not undermine the value of the work — it demonstrates critical thinking and intellectual honesty, and it helps future evaluators and designers understand the conditions under which the findings should be interpreted. Omitting a limitations discussion implies either that the evaluation was perfect (implausible) or that its constraints were not considered (problematic).

Identify limitations specifically rather than generically. Generic statements like "the sample size was small" say very little. A specific limitation statement identifies the particular constraint, explains what it means for the findings, and connects it to the evaluation's actual design. For example: All five participants were undergraduate students aged 19–23 recruited from a single university department. This means the sample lacks age diversity and may not represent the intended user population, which includes adults aged 30–60 with varying levels of digital literacy. Findings related to navigation confidence and error recovery behaviour may therefore underestimate the difficulty that less technically fluent users would experience.

Common categories of limitation include participant recruitment, task design, and evaluation environment. Recruitment limitations arise when the participant sample does not fully represent the target user population — due to convenience sampling, small numbers, demographic homogeneity, or the exclusion of users with specific accessibility needs. Task design limitations arise when the tasks used in the evaluation do not adequately cover the range of actions real users would perform, when task wording unintentionally guides participants toward or away from certain behaviours, or when the scenario provided is not realistic enough to elicit genuine user behaviour. Environmental limitations arise when the evaluation setting — a quiet lab, a video call, a screen-share session — differs meaningfully from the real-world context in which the product would be used, potentially suppressing behaviours like distraction, interruption, or the use of multiple devices.

After identifying limitations, explain how they may have influenced the findings. This is the analytical step that transforms a list of problems into a meaningful discussion. If the evaluation was conducted over video call rather than in person, consider how the absence of physical co-presence might have made it harder to observe non-verbal cues, or how technical difficulties might have affected participant performance. If tasks were completed in a fixed order, consider whether earlier tasks might have taught participants skills or orientations that influenced their performance on later tasks (a learning effect).

Finally, suggest how future evaluations could address these limitations given more time or resources. This forward-looking reflection is constructive rather than merely self-critical. Suggestions might include recruiting a larger and more demographically diverse sample, conducting sessions in the environments where the product would actually be used (contextual inquiry), randomising task order across participants to control for learning effects, or including participants with disabilities to assess accessibility more thoroughly. These suggestions do not need to be exhaustive, but they should be plausible and directly responsive to the limitations identified.

Taken together, the four components of evaluation documentation — methodology, findings, design links, and limitations — create a document that is simultaneously a record, an argument, and a reflection. It records what happened rigorously enough that it could be understood and partially replicated. It argues that the design decisions made were grounded in evidence. And it reflects honestly on the conditions under which the evidence was gathered. This combination is what distinguishes professional, user-centred design documentation from a superficial account of activities completed.

NotesCovers all four subtopic clusters: methodology documentation, findings presentation, linking findings to design iterations, and limitations reflection. Includes a worked HTML table for quantitative findings, participant quote examples, cross-referencing guidance, and specific worked examples for each major concept. No headings used; structure is conveyed through bold labels and paragraph flow as required.
2

Videos on This Topic

▶

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?

3

Video 1: How to Conduct a Heuristic Evaluation

▶

NNgroup · 4:50 · 45,581 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Prioritize UX Findings by Severity

▶

NNgroup · 3:04 · 9,970 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Limited Usability Testing and Business Decisions

▶

NNgroup · 4:35 · 5,527 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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

1

Final Implementation Documentation

▶

Final implementation documentation is the capstone artifact of a design project. It serves as a comprehensive, honest record of what was built, why it was built that way, and how faithfully the finished product reflects the intentions laid out during requirements gathering and prototyping. Unlike a prototype walkthrough or a design rationale written mid-process, final implementation documentation speaks to the completed state of the system — capturing decisions that crystallised only during the act of building, deviations that were necessary or unavoidable, and evidence that user needs have genuinely been addressed. Good documentation at this stage is not a formality; it is the primary way a design team communicates the integrity and traceability of their work to stakeholders, assessors, and future maintainers.

The four major concerns of final implementation documentation are: accurately describing the finished interface, explaining the decisions made during implementation, accounting for any departures from the prototype, and demonstrating that requirements have been met. Each concern is addressed in depth below.

Describing the Final Interface

The first obligation of final implementation documentation is to give any reader — regardless of whether they have followed the project from the start — a clear, concrete picture of what the finished interface looks like and how it behaves. The most effective way to do this is through annotated screenshots of every key screen and every meaningful interaction state.

Annotated screenshots go beyond simple image captions. Each annotation should point to a specific UI element and explain its purpose, its relationship to a user task, or the design decision it embodies. For example, a screenshot of a checkout confirmation screen might carry annotations such as: "Order summary collapsed by default to reduce cognitive load on confirmation — users can expand to verify line items if needed", or "Primary action button uses high-contrast colour meeting WCAG 2.1 AA contrast ratio of 4.5:1." Annotations of this quality turn a static image into a design argument.

Key screens to document typically include:

  • The initial landing or home screen, including any onboarding state shown to first-time users
  • Each primary feature screen that directly supports a core user task
  • Empty states, error states, loading states, and confirmation or success states — because these interaction states are where many usability problems hide
  • Any modal dialogs, drawers, or overlay panels that contain significant functionality
  • Responsive or adaptive variants if the interface targets multiple viewport sizes

Beyond cataloguing screens, the documentation must explain how the interface supports the core user tasks identified during the requirements phase. This means taking each task — typically expressed as a user story or scenario, for instance "As a registered user, I want to filter search results by date so that I can find recent content quickly" — and walking through precisely which interface elements, flows, and affordances allow a real user to accomplish it. This narrative connects the finished product back to the reason it was built, making the documentation a bridge between requirements and delivery rather than a standalone description.

Grounding design decisions in recognised principles and guidelines strengthens this description considerably. When the documentation notes that a navigation pattern was chosen because it aligns with Nielsen's heuristic of recognition rather than recall, or that a form layout follows the GOV.UK Design System's field-label positioning guidelines, it demonstrates that decisions were principled rather than arbitrary. Relevant reference points include established usability heuristics (Nielsen, Shneiderman's Eight Golden Rules), platform-specific human interface guidelines (Apple HIG, Google Material Design), accessibility standards (WCAG 2.1), and any domain-specific style guides or organisational standards that applied to the project.

Documenting Implementation Decisions

Every project discovers things during implementation that the prototype never anticipated. A prototype is a controlled approximation; the act of building the real system surfaces constraints, edge cases, and opportunities that are simply invisible at the wireframe or clickable-prototype stage. Final implementation documentation must capture these emergent decisions honestly and explain them clearly.

Typical categories of unanticipated implementation decisions include:

  • Technical constraints: A chosen animation library did not support the gesture interaction designed in the prototype, requiring a different interaction model to be substituted.
  • Data-driven changes: Real data contained entries far longer than the sample data used in prototyping, causing labels to truncate or wrap in ways that broke the layout, necessitating a revised typographic approach.
  • Platform behaviour: A native mobile keyboard covered a form field that was accessible in the prototype tool but was occluded in production, requiring the form scroll behaviour to be adjusted.
  • Integration realities: An API returned data in a different structure or with additional latency, requiring a loading skeleton state that was never part of the original design.

For each such decision, the documentation should justify the choice in terms of one or more of the following lenses: usability (does the decision maintain or improve the experience for users?), technical feasibility (was the original approach simply not implementable within the available technology stack or timeframe?), and design consistency (does the decision preserve the visual language, interaction patterns, and mental model established throughout the rest of the interface?). A decision justified on only one of these grounds is weaker than one that satisfies all three; the documentation should acknowledge trade-offs honestly when they exist.

Critically, each implementation decision should also be evaluated against the original design goals. If the project's stated goal was to allow novice users to complete a task in under three steps, and an implementation decision added a step, the documentation must confront that directly: either presenting evidence that usability testing showed the extra step did not harm completion rates, or acknowledging that a goal was compromised and explaining why the trade-off was accepted.

Documenting Deviations from the Prototype

Deviations from the prototype are not failures — they are normal, expected outcomes of the transition from design artefact to working system. What matters is that they are identified explicitly, explained honestly, and assessed for their impact on the design's ability to meet its requirements. Undocumented deviations create gaps in the audit trail that make it impossible for anyone reviewing the project to understand what was intended versus what was delivered.

A structured approach to deviation documentation works best. For each deviation, the record should capture:

Feature or Element Prototype Version Implemented Version Reason for Deviation Impact on Requirements
Search autocomplete Dropdown appeared after 1 character typed Dropdown appears after 3 characters typed API query cost and latency made per-keystroke requests impractical; debounce threshold set to 3 characters Minor — user testing showed no measurable increase in task completion time; requirement for responsive search considered met
Onboarding carousel 5-screen animated carousel with video embeds 3-screen static carousel, no video Video assets were not delivered by content team within project timeline; 3 screens retained the most critical content Partial — the requirement to contextualise all four primary features for new users is only partially met; the omitted screens covered two secondary features
Dark mode toggle Prominent toggle in main navigation bar Toggle moved to user profile settings page Navigation bar became overcrowded on small viewports; toggle repositioned to reduce clutter and align with platform conventions Neutral — usability heuristic of aesthetic and minimalist design better served; discoverability of toggle reduced but no requirement specified its placement

The reasons for deviations fall into several recurring categories. Technical reasons include platform limitations, performance constraints, third-party API behaviour, or library incompatibilities. Time-based reasons include features descoped due to deadline pressure, often documented as known limitations or items deferred to a future iteration. Usability-driven reasons are in many ways the most positive category — they reflect cases where testing or real-data exposure revealed that the prototype approach was actually worse than the alternative, and the deviation represents a genuine design improvement.

The impact assessment for each deviation is the most important field in that record. The documentation should clearly state whether the deviation: (a) has no meaningful effect on the design's ability to meet its requirements, (b) partially compromises a requirement and by how much, or (c) causes a requirement to be unmet, and why that outcome was accepted rather than addressed.

Tracing Design Decisions to Outcomes

The final and most rigorous section of implementation documentation establishes a traceable line from every major requirement to its realisation in the finished interface. This is sometimes called a requirements traceability matrix in engineering contexts, but in a UX or interaction design project it is better understood as a design accountability record — a document that allows anyone to verify that the design was purposeful and evidence-based.

The structure of this tracing exercise begins with each requirement stated in the terms used during the requirements phase. For each requirement, the documentation then specifies: which interface elements, flows, or features address it; and what evaluation evidence confirms it has been met. Evaluation evidence might include usability test results (e.g., task completion rates, error rates, think-aloud observations), expert review findings, heuristic evaluation scores, or accessibility audit outcomes.

For example:

Requirement Implementation Evidence Evaluation Evidence Status
Users must be able to reset their password without contacting support Self-service password reset flow accessible from login screen; confirmation email with expiring token; inline error messages for invalid token 5/5 participants completed reset task without assistance in usability test; average time on task 47 seconds Fully met
Interface must be operable by keyboard-only users All interactive elements have visible focus indicators; tab order follows logical reading order; modal dialogs trap focus correctly; skip-to-content link implemented Keyboard navigation audit conducted against WCAG 2.1 success criteria 2.1.1 and 2.4.3; two minor focus-order issues in the settings panel identified and resolved prior to submission Fully met
New users should be able to complete core task within first session without training Contextual inline help tooltips on first interaction with each major feature; progressive disclosure used to hide advanced options until needed 3/5 participants completed core task unaided in first session; 2 participants required one prompt; learnability requirement considered partially met Partially met — further onboarding improvements identified for next iteration

Acknowledging partially met requirements is not a weakness in the documentation — it is a mark of its integrity. A design project that claims all requirements were fully met without qualification is almost certainly not being honest. Partially met requirements should be accompanied by a clear explanation: was the shortfall due to a deviation from the prototype, a scope reduction, a technical constraint, or an underestimation of the complexity of the user task? And what, if anything, has been identified as a path to fully meeting the requirement in a subsequent iteration?

This traceability record, taken together with the annotated interface description, the implementation decision log, and the deviation register, constitutes a complete and professionally credible account of the design — one that demonstrates not just what was built, but why every significant choice was made, and what evidence supports the claim that the design serves its users.

NotesExplains how to document the final implemented design, including a description of the interface, design decisions made during implementation, and any deviations from the prototype.
2

Videos on This Topic

▶

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.

3

Video 1: Outcome-Oriented Design: The Era of AI Design

▶

NNgroup · 3:33 · 350,359 views · 6mo ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

How These Videos Support the Learning Outcomes

▶

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.

5

About These Videos

▶

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.

Group Collaboration and Contribution Documentation

1

Group Collaboration and Contribution Documentation

▶

When a design project is undertaken collaboratively, the work that happens between team members — the planning, negotiating, dividing, reviewing, and reflecting — is just as significant as the final artefact produced. Group collaboration and contribution documentation is the practice of systematically recording and articulating how a team functioned throughout a project: who did what, how decisions were reached, how the work was managed, and what the team learned about working together. A well-constructed group development report does not simply list names beside tasks; it tells the story of the team's process with enough specificity and honesty that an external reader — a client, an assessor, or a future employer — can understand exactly how the project unfolded and what each person genuinely contributed.

The value of this documentation extends beyond accountability. Reflecting carefully on a collaborative process builds the professional self-awareness that experienced designers rely on. Teams that document their process rigorously are better positioned to repeat what worked and to consciously change what did not. The sections below explore each dimension of collaboration documentation in depth, with guidance on what to include, why it matters, and how to present it convincingly.

Documenting Team Roles and Responsibilities

A clear account of team roles begins with more than a simple org chart or a one-line job title. Each role should be described with direct reference to specific tasks and to the phase of the project in which those tasks occurred. This level of detail matters because roles in design projects are rarely static — a person who led research in week one may have shifted to a supporting role during prototyping, and this evolution tells an important story about how the team adapted.

When describing roles, consider structuring your account around the project's phases — for example: discovery and research, concept development, prototyping and testing, refinement, and final production. For each phase, explain what each team member was responsible for and, crucially, what that responsibility actually involved in practice. Compare the following two descriptions:

  • Vague: "Amara was responsible for research."
  • Specific: "During the discovery phase, Amara led the primary user research by designing and administering a ten-participant interview script, synthesising findings into an affinity diagram, and presenting insights to the team at the week-two review meeting."

The specific version gives a reader a genuine understanding of the scope, skill, and effort involved. It also makes the documentation useful as a professional record for each individual team member.

Equally important is explaining the rationale behind the division of labor. How were roles assigned? Did team members self-select based on existing skills? Were roles rotated deliberately to give everyone exposure to different areas? Did the team identify skill gaps early and assign roles to address them? Providing this reasoning demonstrates that the team's structure was intentional rather than accidental.

You should also document any changes to the division of labor that occurred mid-project. In practice, no initial plan survives contact with a real project unchanged. A team member may have had unexpected time constraints, a particular task may have proven more complex than anticipated, or a role may have simply become redundant as the project direction shifted. Recording these changes — and explaining why they were made — demonstrates adaptive capacity, which is a genuine professional strength. For example:

  • "In week four, after the concept development phase ran significantly over schedule, we redistributed prototyping tasks. Joaquin took on additional interface mockup work that had originally been assigned to Priya, who focused entirely on completing the user testing report. This reallocation was agreed upon in our Monday check-in and updated in our shared task board."

Finally, effective role documentation acknowledges overlapping and collaborative activities honestly. Many design tasks are genuinely shared — ideation sessions, critique meetings, co-authoring documents, peer reviewing each other's work. These should be named and described rather than omitted because they do not fit neatly into individual ownership. Overlapping work is not a weakness in a team structure; it reflects the interdependent nature of design practice and, when documented well, demonstrates the team's ability to collaborate fluidly.

Describing Collaborative Design Processes

Design is fundamentally a process of making decisions under uncertainty, and in a team context those decisions must be made collectively. The documentation of collaborative design processes should explain how the team reached agreement on the choices that shaped the project — not just what those choices were.

Begin by identifying the key design decisions in your project — the moments where the direction of the work was genuinely determined. These might include: selecting a design direction from several concepts, choosing a target user group after research, deciding on a visual language or design system, or agreeing to pivot away from an approach that was not working. For each significant decision, document the method used to reach agreement. Common methods include:

  • Structured voting: Each team member ranks or votes on options, and the team agrees in advance to follow the majority or a weighted outcome.
  • Design critiques: The team evaluates each option against defined criteria — such as user needs, technical feasibility, and project constraints — before reaching a consensus.
  • Designated decision-maker: The team agrees that the person with the most relevant expertise or role ownership makes the final call on a specific type of decision.
  • Iterative testing: Rather than arguing abstractly, the team creates quick prototypes of competing ideas and tests them, letting evidence drive the decision.

Where the team used structured review or critique sessions — whether internal team critiques or feedback sessions with tutors, clients, or peers — these should be documented in some detail. What was presented? Who participated? What criteria guided the feedback? What outcomes resulted? A critique session that is documented only as "we got feedback in week three" contributes little to the reader's understanding. Instead, describe what the critique revealed and how it specifically influenced the subsequent design direction. For example:

  • "At our mid-project critique with our tutor, all three of our initial interface concepts were reviewed. Feedback indicated that Concept B's navigation structure was more intuitive but that its visual hierarchy was inconsistent. As a result, we merged the navigation model from Concept B with the typographic hierarchy from Concept A, creating the hybrid direction that became our final design."

Honestly documenting how disagreements and competing ideas were resolved is one of the most revealing and professionally valuable parts of this section. Most design teams experience genuine disagreements — about aesthetics, about scope, about priorities. The temptation in documentation is to present the team as having been in seamless agreement throughout. Resist this temptation. Describing a real disagreement and explaining how it was worked through demonstrates maturity, effective communication, and a functioning team dynamic. It also makes the final design choices more legible, because the reader understands the alternatives that were considered and rejected.

When documenting a resolved disagreement, include: what the competing positions were, who held them, what process was used to work toward resolution, and what the outcome was — including whether everyone felt the resolution was satisfactory. If the resolution was imperfect or left some tension unresolved, acknowledging this is appropriate and honest.

Documenting Project Management Activities

Project management documentation records the infrastructure the team used to coordinate its work — the tools, systems, and habits that turned a group of individuals into a functioning unit. This section should be concrete and specific, because vague references to "staying organised" or "communicating regularly" convey very little.

Begin by describing the tools and methods used to manage tasks, deadlines, and deliverables. Many design teams use a combination of digital tools for different purposes. Common examples include:

Tool Type Example Tools Typical Use in Design Projects
Task management Trello, Notion, Asana, Monday.com Creating, assigning, and tracking tasks with due dates and status updates
Communication Slack, Microsoft Teams, Discord Day-to-day messaging, sharing quick updates, and asynchronous check-ins
File collaboration Google Drive, Figma, OneDrive Sharing, editing, and commenting on documents and design files in real time
Version control Git/GitHub, Figma version history, named file conventions Tracking changes over time, reverting to earlier states, attributing edits
Meeting coordination Google Calendar, Doodle, When2meet Scheduling meetings that accommodate all team members' availability

Do not simply list the tools — explain how they were used in practice. For example, if your team used Trello: How was the board structured? Were tasks organised by project phase, by team member, or by deliverable type? Who was responsible for maintaining it? How frequently was it updated? Were there any rules the team agreed to follow, such as moving a card to "done" only after peer review?

The documentation of version control and file management deserves particular attention in design projects, where multiple team members may be working on shared files simultaneously. Describe the system your team used to prevent conflicts, track changes, and ensure everyone was working on the most current version of a file. Even if your team used a relatively informal approach — such as a naming convention like ProjectName_ComponentName_v3_YYYYMMDD_Initials — documenting and evaluating that approach is valuable. If your team used a more sophisticated system such as Git branches or Figma's branching feature, explain how that system was structured and who was responsible for managing it.

Critically, this section should include a genuine reflection on the effectiveness of the project management approach. What worked well, and what caused friction? Be specific. For example:

  • "Our Trello board was effective during the first half of the project but became neglected during the intensive prototyping phase when team members were updating each other verbally in meetings instead of updating the board. This created confusion about current task status in week six and contributed to two tasks being overlooked. In future projects, we would implement a brief end-of-meeting board update as a standing agenda item to prevent this."

Reflections of this kind — specific, honest, and forward-looking — demonstrate far more professional maturity than an account that presents the team's project management as flawless.

Reflecting on Group Process

The reflection on group process is the most analytically demanding part of collaboration documentation. It requires the team to step back from the details of what was done and evaluate how the team functioned as a social and professional unit. Strong reflections are grounded in specific evidence, not generalisations, and they balance recognition of strengths with honest acknowledgment of difficulties.

When identifying specific strengths in the team's collaborative process, resist the temptation toward generic praise such as "we communicated well" or "we supported each other." Instead, ground every identified strength in a concrete example that demonstrates it. Consider the following:

  • Generic: "Our team was good at decision-making."
  • Evidence-based: "When we reached an impasse over two competing visual directions in week five, we used a structured decision matrix that weighted options against our user research findings, project brief requirements, and technical constraints. This prevented the disagreement from becoming personal and produced a decision that all team members felt was rationally grounded. We used a similar approach successfully later in the project when evaluating typeface options."

Meaningful strengths to reflect on might include: effective use of each member's skills, a culture of honest and constructive feedback, consistent meeting attendance and preparation, equitable distribution of effort, proactive communication when problems arose, or the ability to adapt flexibly when circumstances changed.

Acknowledging challenges encountered during collaboration requires honesty and some courage. Common challenges in student and professional design teams include: unequal contribution, communication breakdowns, difficulty reaching consensus, time zone or schedule mismatches in distributed teams, unclear ownership of tasks, and interpersonal tension. Whatever challenges your team encountered, describe them clearly — what happened, when it happened, and what impact it had on the project or the team's dynamic. Then describe how the challenge was managed. This two-part structure — challenge plus response — is essential. Simply listing difficulties without explaining how they were addressed suggests that the team was passive in the face of problems.

For example:

  • "In week three, one team member was significantly behind on their assigned research tasks due to personal circumstances that they communicated to the team only after the deadline had passed. This created pressure on the rest of the team during a time-critical phase. We held a meeting to redistribute the outstanding work, agreed on a revised internal deadline, and established a check-in text at the midpoint of each task cycle so that similar delays could be identified and addressed earlier. The team member completed their contributions in subsequent phases without further issues."

Finally, suggesting concrete improvements for future projects is the most forward-looking and professionally valuable component of the group process reflection. Improvements should be specific enough to actually be actionable — not "we would communicate better" but a description of an actual mechanism or practice that would produce better communication. Useful categories for improvement suggestions include:

  • Onboarding and role clarity: For example, drafting a team charter or responsibility assignment matrix (RACI chart) at the project outset to establish clear expectations from day one.
  • Meeting structure: For example, adopting a standing agenda format with designated time for task updates, blockers, and upcoming deadlines to make meetings more efficient.
  • Feedback culture: For example, implementing a practice of structured peer review for all major deliverables before submission, using a shared rubric.
  • Conflict resolution: For example, agreeing at the outset on a decision-making protocol to use when the team cannot reach consensus organically, such as escalating to a vote after a defined discussion period.
  • Documentation habits: For example, designating a rotating "meeting scribe" role responsible for writing and distributing notes within 24 hours of each meeting.

The most credible improvement suggestions are those that respond directly to the challenges identified earlier in the reflection — they demonstrate that the team has genuinely analysed its difficulties and thought carefully about what structural or behavioural changes would address them.

Taken together, thorough and honest group collaboration documentation serves multiple purposes. It creates an accurate professional record of each team member's contributions. It demonstrates to assessors or clients that the team's process was intentional and reflective rather than ad hoc. And it builds the kind of collaborative self-awareness that makes every subsequent team project — in study or in professional practice — more effective.

NotesThis topic covers the full scope of group collaboration and contribution documentation for a design development report. The content addresses all four major subtopic clusters: role documentation, collaborative design processes, project management, and group process reflection. Examples are illustrative and can be adapted to specific project contexts. The table of project management tools provides a concrete reference that can be used as a starting point for students to describe their own tool choices.
2

Videos on This Topic

▶

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.

3

Video 1: RACI Matrix Basics Explained with Examples | TeamGantt

▶

TeamGantt · 5:09 · 79,171 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: How to Write a Project Brief: Template & Examples | TeamGantt

▶

TeamGantt · 9:56 · 10,184 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: The UX Design Process explained step by step with a mobile app project

▶

chunbuns · 6:53 · 476,837 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Report Structure, Referencing, and Presentation

1

Report Structure, Referencing, and Presentation

▶

Producing a professional HCI development report requires far more than simply recording what was done during a project. The document must communicate a coherent, evidence-based story about how a design problem was identified, investigated, iterated upon, and ultimately resolved. To achieve that, the report must be structured predictably so that any reader — whether a client, an academic assessor, or a fellow practitioner — can locate information quickly, evaluate the quality of the reasoning, and trust that the evidence presented is properly sourced. The conventions described below are not arbitrary bureaucratic rules; each one exists because it solves a specific communication problem that arises when complex, multi-stage design work is written up for a professional audience.

Standard Report Structure

A professional HCI report is divided into three broad zones: the front matter, the body, and the back matter. Each zone plays a distinct role, and together they transform what could be a loose collection of observations and design artefacts into a navigable, self-contained document.

Front matter consists of the elements a reader encounters before the main content begins. The title page names the project, identifies the authors, states the institutional or client context, and provides the submission or publication date. Even in student contexts this page signals professionalism; a missing or carelessly formatted title page creates an immediate negative impression. The abstract (sometimes called an executive summary in industry reports) is a condensed, self-contained description of the entire project — its purpose, the methods used, the principal findings, and the key design outcomes. Crucially, the abstract must be intelligible without reading the rest of the report; many stakeholders read only this section before deciding whether to engage further. The abstract is written last, even though it appears first. The table of contents lists every numbered section and subsection with corresponding page numbers, allowing readers to navigate directly to the content most relevant to them. In longer reports, separate lists of figures and tables are added immediately after the table of contents.

Body organisation in an HCI report should mirror the chronological stages of the design process itself. This is not merely a stylistic choice — it reflects the fact that each stage of HCI work produces outputs that become inputs to the next stage, and a reader needs to follow that chain of reasoning. A typical body structure moves through: an introduction that frames the problem and the report's scope; a literature review or contextual background that situates the project within established HCI theory and prior work; a requirements section reporting the outcomes of user research (interviews, observations, surveys); a design rationale section documenting ideation and the decisions made in moving from requirements to early concepts; a prototyping section presenting low- and high-fidelity prototypes with the reasoning behind design choices; an evaluation section reporting usability testing results; and a discussion or conclusion section that synthesises findings, acknowledges limitations, and suggests future directions. When the body is organised this way, each section answers a predictable question: What did we need to know? What did we find out? What did we design? How did we test it? What does it mean?

Appendices carry supporting evidence that is necessary for completeness and reproducibility but would interrupt the flow of the body if inserted inline. Every appendix must be clearly labelled (Appendix A, Appendix B, and so on) with a descriptive title, and each must be explicitly referenced somewhere in the body text. Typical appendix content in an HCI report includes: raw interview transcripts or survey response data; completed participant consent forms and information sheets; full sets of usability test tasks and protocols; additional prototype screens or wireframes not discussed in the body; and any statistical output files. A reader should be able to consult an appendix to verify a claim made in the body without having to guess which appendix is relevant.

Writing Cohesive Narratives Across Sections

One of the most common weaknesses in student and junior-practitioner HCI reports is that the sections read as independent mini-essays rather than as chapters in a single argument. A requirements section might describe ten user needs, but the subsequent design section presents prototypes that address only four of them, with no explanation of the gap. An evaluation section might report a usability finding without connecting it back to the design decision that caused it. These disconnections make the report difficult to assess and suggest that the design decisions themselves were not properly reasoned.

Explicit cross-referencing is the primary technical remedy. When body text in the design section builds on a finding from the requirements section, name that connection directly: "The decision to use a bottom navigation bar addresses the thumb-reach constraint identified in Section 3.2" rather than leaving the reader to infer the link. Similarly, when an appendix is relevant, the referral must be active rather than passive: "Full interview transcripts are provided in Appendix B" rather than hoping the reader will look for them independently.

Section-opening signpost statements serve a related function. The first paragraph of each major section should do two things simultaneously: state the purpose of this section and articulate how it relates to what came before. For example, a prototyping section might open with: "Having established in the previous section that users require rapid access to frequently used features and that cognitive load during task completion is a significant concern, this section presents the low-fidelity wireframes developed to address those requirements and explains the design decisions that shaped the high-fidelity prototype." That single sentence prevents the section from appearing to start from scratch and reminds the reader of the through-line of the project.

The underlying principle is that the report must answer an implicit "so what?" at every transition. The requirements section must set up what the design section will resolve. The design section must create questions that the evaluation section will answer. The conclusion must synthesise what all previous sections, taken together, demonstrate. When writers treat their own report as a story with a beginning, middle, and end, cross-section coherence tends to improve naturally.

Academic Referencing

In an HCI report, references serve a specific argumentative function: they demonstrate that design decisions are grounded in established knowledge rather than personal preference. When a decision is justified by citing Nielsen's usability heuristics, Fitts's Law, Norman's principles of affordance and feedback, or a peer-reviewed usability study, the report gains credibility because the reasoning can be independently verified. A report that makes design claims without citations is simply asserting opinion.

The types of sources typically cited in HCI reports include:

  • Theoretical frameworks and models — for example, Norman's Action Cycle, Shneiderman's Eight Golden Rules, or the Technology Acceptance Model (TAM), cited when they are used to analyse user behaviour or justify interface conventions.
  • Usability guidelines and standards — for example, ISO 9241-11 (the international standard defining usability in terms of effectiveness, efficiency, and satisfaction) or platform-specific human interface guidelines, cited when a specific design standard is being followed.
  • Empirical research findings — peer-reviewed studies reporting usability test outcomes, eye-tracking experiments, or field studies, cited when they inform specific design choices such as typography sizes, menu depth, or colour contrast ratios.
  • Methodological sources — texts on user research methods (interviews, contextual inquiry, card sorting), cited in the methodology section to justify the chosen approach.

Consistency in referencing style is non-negotiable. Whether the required style is APA, Harvard, IEEE, or another system, every in-text citation and every entry in the reference list must follow the same format without exception. Mixed referencing styles — APA in-text citations with IEEE-style reference list entries, for instance — indicate careless proofreading and undermine the credibility of the entire document. The most common errors include: inconsistent use of italics for journal and book titles; missing or incorrectly formatted DOIs or URLs; inconsistent treatment of multiple authors; and missing publication years. Many institutions provide referencing guides, and tools such as Zotero, Mendeley, or citation generators can reduce formatting errors, but all automatically generated citations must be checked manually because errors are common.

The reference list appears at the end of the main body, before the appendices, and includes every source cited in the report — no more and no less. Sources that were read but not cited do not appear (that would be a bibliography, which is a different thing). The list is formatted according to the prescribed style: alphabetically by author surname in APA and Harvard systems, or numerically in order of first citation in IEEE. Every entry must contain enough information for a reader to locate the original source independently.

Use of Visual Evidence

HCI reports are inherently visual documents. Wireframes, usability test result charts, persona cards, journey maps, affinity diagrams, and prototype screenshots are not decorative — they are primary evidence. How they are presented determines whether they support or undermine the report's argument.

Numbering and captioning every visual element is the foundational requirement. Figures (which include photographs, diagrams, charts, screenshots, and any non-tabular visual) are numbered sequentially throughout the report: Figure 1, Figure 2, and so on. Tables are numbered in their own separate sequence: Table 1, Table 2, and so on. Each figure and table receives a concise but descriptive caption. In APA style the caption appears below a figure and above a table; in other styles the convention may differ, but whichever convention is adopted must be applied uniformly. A good caption describes what the visual shows and, where necessary, explains what the reader should notice: "Figure 4. Heat map generated from eye-tracking data during Task 2, showing concentrated fixations on the top-left navigation panel and near-zero attention to the bottom action bar." That caption does analytical work, not merely labelling work.

In-text referencing of visuals is a requirement that is frequently overlooked. Every figure and table must be explicitly called out in the body text at the point where it becomes relevant: "As shown in Figure 4…" or "Table 2 summarises the task completion rates across all five participants." A figure that is inserted into the document but never mentioned in the text appears to float free of the argument — the reader cannot know whether it is illustrating a point, providing raw data for inspection, or included by accident. Conversely, a visual should never be placed in the document before its first in-text reference; the reference in the text should logically precede or immediately accompany the visual.

Resolution and clarity are practical requirements with real consequences. A wireframe screenshot that is pixelated or too small to read the interface labels defeats the purpose of including it. All raster images (photographs, screenshots) should be exported or captured at a resolution sufficient to remain legible when printed at A4 size — typically 150 dpi minimum for screenshots and 300 dpi for photographs. Vector graphics (SVG, PDF-embedded diagrams) scale without quality loss and should be used for charts and diagrams wherever possible. Before submission, every visual should be inspected at 100% zoom in the final PDF to confirm legibility.

The table below summarises the key rules for presenting visual evidence consistently:

Element Numbering Caption Position In-text Reference Required? Minimum Resolution
Photographs and screenshots Figure sequence (Figure 1, 2, …) Below the image Yes — before or alongside the figure 150 dpi at final print size
Charts and graphs Figure sequence Below the image Yes Vector preferred; 150 dpi minimum if raster
Wireframes and prototypes Figure sequence Below the image Yes Legible labels at A4 print size
Data tables Table sequence (Table 1, 2, …) Above the table Yes — before the table appears N/A (text-based)
Diagrams (journey maps, affinity diagrams) Figure sequence Below the image Yes Vector preferred; all text must be legible

Presentation and Formatting Standards

Formatting is the visual layer of the report's argument. Inconsistent formatting does not merely look unprofessional — it actively interferes with comprehension by creating ambiguity about the logical hierarchy of content. A reader who cannot immediately distinguish a section heading from a subsection heading has to do extra cognitive work to understand the document's structure, and that work detracts from their engagement with the ideas.

Heading hierarchy and typography must be defined early and applied without deviation. A three-level heading system is sufficient for most HCI reports: a primary level for major sections (Introduction, Requirements, Design, Evaluation, Conclusion), a secondary level for subsections within those, and a tertiary level for sub-subsections where needed. Each level should be visually distinct — typically through a combination of font size, weight (bold or regular), and vertical spacing — and these distinctions must be maintained throughout. Body text should use a readable serif or sans-serif font at 11 or 12 point with 1.15 or 1.5 line spacing. All paragraphs should be formatted consistently, whether that means uniform indentation of the first line or uniform space between paragraphs. Code samples, if any, should appear in a monospace font within a visually distinguished block. These choices should be encoded in named paragraph and character styles within the word processor rather than applied manually, because manual formatting is the primary source of inconsistency in multi-section documents.

Word count management requires deliberate planning. Most assessed HCI reports specify a total word count, and the distribution of that count across sections is not arbitrary. The body of the report — requirements, design, evaluation — should consume the largest portion because that is where the substantive intellectual work is presented. The introduction and conclusion together typically account for ten to fifteen percent of the total. The abstract is usually excluded from the word count but is itself subject to its own limit (commonly 150–300 words). A common mistake is to write an excessively long literature review or introduction and then compress the evaluation section, which produces a document that dwells on context at the expense of the project's actual findings. A rough planning allocation for a 4,000-word report might look like this:

Section Approximate Word Count Percentage of Total
Introduction 300–400 8–10%
Background / Literature Review 400–600 10–15%
Requirements and User Research 700–900 18–22%
Design and Prototyping 800–1,000 20–25%
Evaluation 700–900 18–22%
Discussion and Conclusion 300–400 8–10%

Final formatting review is essential in any report written collaboratively, because different authors inevitably apply formatting rules differently. One author may use double spaces after full stops; another may not. One may write "Figure 1" with a capital F and another "figure 1" in lowercase. One section may have 12pt spacing after headings and another 6pt. These discrepancies are invisible to each individual author but immediately apparent to a reader encountering the full document. The final review should be conducted by a single person who goes through the entire document specifically looking for formatting inconsistencies rather than reading for content. A useful technique is to use the word processor's "find and replace" function to locate common errors (double spaces, inconsistent hyphenation, mixed heading capitalisation styles) and the styles panel to confirm that named styles are applied consistently. The document should be exported to its final submission format (typically PDF) and reviewed again in that format, because some formatting issues only become visible in the rendered output.

A consolidated checklist for the final review might include:

  • Front matter complete: title page, abstract, table of contents, and lists of figures and tables all present and correctly formatted.
  • Heading hierarchy consistent: all level-1, level-2, and level-3 headings visually uniform throughout the document.
  • All figures and tables numbered and captioned: no visual element appears without a label, and no figure or table number is skipped or duplicated.
  • All figures and tables referenced in body text: each visual is explicitly called out before or at the point of its appearance.
  • All citations match the reference list: every in-text citation has a corresponding reference list entry and vice versa.
  • Referencing style applied uniformly: consistent formatting of authors, dates, titles, and source information throughout the reference list.
  • Cross-references accurate: all section, figure, and table numbers cited in the text match the actual numbers in the document.
  • Word count within limits: total count and per-section allocation checked against the specification.
  • Appendices labelled and referenced: each appendix has a title and is cited at least once in the body.
  • Images legible in final PDF: all figures readable at standard screen zoom and at print size.
NotesThe topic covers all five subtopic clusters: standard report structure (front matter, body organisation mirroring HCI process stages, appendices), cohesive narrative writing (cross-referencing, section-opening signposts, unified flow), academic referencing (types of HCI sources, consistency requirements, reference list conventions), use of visual evidence (numbering, captioning, in-text referencing, resolution), and presentation/formatting standards (heading hierarchy, word count distribution, final collaborative review). Two HTML tables are included: one summarising visual element presentation rules and one illustrating approximate word count distribution across sections.
2

Videos on This Topic

▶

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.

3

Video 1: APA 7th Edition: Set up an APA Format Paper in 6 Minutes | Scribbr 🎓

▶

Scribbr · 5:54 · 1,554,308 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: APA 7th Edition: The Basics of APA In-text Citations | Scribbr 🎓

▶

Scribbr · 3:48 · 1,506,065 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Basics of Report Writing

▶

University of Wolverhampton · 6:13 · 32,599 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.