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.

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.

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?

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.

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.

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.

Together these videos supply the raw material for the evaluation portion of your design document (MO1): a documentable method in the heuristic evaluation walkthrough, a structured way to present and prioritize findings via severity ratings, and a model for writing a limitations section. The severity and method vocabulary supports the technical writing conventions emphasized in MO2, giving you consistent, professional terms instead of informal descriptions of problems. And because severity ratings and an honest account of evaluation scope are exactly what let you argue why one issue was fixed in the next iteration and another was deferred, these videos directly feed the evidence-based justification of design choices required by MO3.

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