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:

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:

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.

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.

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.

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.

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.

Together these videos give you the writing conventions needed to turn project work into a submittable document. The report-structure tutorial supports MO1 and MO2 by showing where requirements, design decisions, evaluation findings, and iteration history belong within a conventional section sequence. The APA formatting video reinforces MO2 by modelling consistent, professional presentation across a whole document, including headings and reference lists. The in-text citation video supports MO3, since justifying design choices against HCI principles and published guidance requires you to cite those sources correctly in the body of your argument rather than asserting them.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.