Evaluating Peer Prototypes

Heuristic Evaluation (HE) is one of the most widely used and respected usability inspection methods in UX and interaction design. In this module, you will move beyond practice exercises and apply the complete HE process independently to three prototypes created by your peers. This is a significant step: you are no longer evaluating a controlled example with known issues, but instead bringing your expert eye to real design work produced in real conditions, with all the ambiguity and variation that entails. The expectations for this module are correspondingly higher — both in the rigour of your methodology and in the professionalism of your conduct.

Understanding the full scope of this assignment before you begin is essential. Rushing into the first evaluation without a clear picture of what is required across all three can lead to inconsistent depth, missed heuristics, or reports that vary wildly in quality. Read through the requirements carefully, organise your materials, and approach each evaluation as a discrete, self-contained professional task.

Module Assignment Overview

The assignment requires you to evaluate three distinct peer prototypes. Each prototype is a separate design artefact, and each must receive its own dedicated, formally structured Heuristic Evaluation report. You cannot combine findings from two prototypes into a single report, nor can you cross-reference issues between prototypes as a way of shortening your documentation. Each report must stand alone as a complete, professional deliverable.

During each evaluation, you are required to systematically consider all ten of Nielsen's usability heuristics. This is not optional, and it does not mean simply listing the heuristics at the top of your report. It means actively and deliberately testing the prototype against each heuristic in turn, asking whether the design satisfies, partially satisfies, or violates the principle — and documenting your reasoning with specific, observable evidence for every finding you record.

Every finding you document must be accompanied by a severity rating using the standard 0–4 scale. This scale provides a shared, structured language for communicating how serious a usability problem is, independent of subjective impression. The ratings are defined as follows:

Severity ratings must be applied thoughtfully, not mechanically. A severity 3 finding in one prototype should reflect the same level of impact as a severity 3 finding in another — your scale must remain consistent across all three reports. When in doubt, ask yourself: how much does this problem impair a real user's ability to complete their goal? That question should anchor every rating you assign.

Maintaining Evaluator Independence

Perhaps the most critical procedural requirement of this assignment is that you complete all individual evaluations independently, without sharing or discussing your findings with classmates until every report is fully documented. This is not a bureaucratic rule — it reflects a foundational principle of rigorous evaluation methodology. The entire value of running multiple independent evaluators is that each person surfaces problems the others might not notice, because they each bring their own mental model, prior experience, and attentional focus. If evaluators compare notes mid-process, those independent perspectives collapse into a single shared view, and the evaluation loses much of its power to surface the full range of issues.

Consider a concrete example: suppose you evaluate a prototype and find a confusing navigation structure but miss an inconsistency in the iconography. A classmate finds the icon issue but misses the navigation problem. If you compare findings before finalising your reports, you each add the other's discoveries to your own list — but neither of you independently validated those findings. Your reports now contain findings you did not personally discover or assess, which undermines the integrity of both evaluations.

Independence also requires a specific habit during the evaluation itself: record findings as you discover them, in real time. Do not make mental notes with the intention of writing them up later. Memory is selective and reconstructive — by the time you sit down to write, you will have forgotten the exact screen, the precise interaction, or the specific wording that made a problem evident. Write your observations directly into your notes or report draft as you move through the prototype. A simple timestamped log of findings, captured screen by screen, will make your final report far easier to write and far more accurate.

Collaboration before all individual reports are complete does not just reduce evaluation quality — it also undermines the academic validity of the work. Each report must reflect your own expert assessment. Submitting a report that incorporates another evaluator's undisclosed contributions misrepresents your individual work, regardless of intent.

Professional Conduct in Peer Evaluation

Evaluating a classmate's prototype introduces a social dimension that professional HE of a commercial product does not. It is natural to feel cautious about identifying problems in a peer's work, or conversely to be harsher than you would be with a professional product because the context feels less formal. Neither of these tendencies serves the designer or the evaluation. Your job is to be a rigorous, fair, and constructive professional evaluator — not a critic, and not a cheerleader.

Every finding you document must be grounded in two things: a specific heuristic and observable evidence from the prototype. This framing protects both you and the designer. When you write "the error message on screen 4 provides no indication of what went wrong or how to recover, violating Heuristic 9 (Help users recognise, diagnose, and recover from errors)," you are making a professional, evidence-based observation. You are not making a judgment about the designer's competence. The problem exists in the design artefact, and it can be fixed in the next design artefact. That distinction matters enormously.

Avoid all personal commentary about the designer's skill, effort, or intent. Phrases such as "the designer clearly didn't think about the user," "this is a lazy implementation," or even well-meaning observations like "I can tell a lot of effort went into this" have no place in a formal HE report. They introduce subjectivity, they shift focus from the design to the person, and they reduce the professional credibility of your evaluation. A finding should read as if it could have been written about any interface by any qualified evaluator — not as if it was written by someone who knows whose work they are assessing.

Recommendations should be constructive and should respect the designer's creative direction. If a prototype uses an unconventional layout that creates a genuine discoverability problem, your recommendation should address the discoverability problem — not suggest abandoning the unconventional layout entirely. You are not the designer. Your role is to identify where the current design creates friction for users and to suggest directions for improvement, not to impose your own aesthetic or structural preferences.

It is also worth internalising a broader professional truth: usability problems are not failures. Every design — including the products built by the most experienced teams in the world — contains usability issues. That is precisely why iterative design, user testing, and heuristic evaluation exist. Finding problems in a prototype is not an indictment of the designer; it is the purpose of the evaluation. Approach every report with that understanding, and your findings will be more honest, more useful, and more professionally presented.

Calibrating Evaluations Across Prototypes

One of the subtler challenges of evaluating multiple prototypes in sequence is maintaining a consistent evaluative standard. Humans naturally calibrate their expectations based on recent experience. If the first prototype you evaluate is exceptionally polished, you may unconsciously raise your bar and apply a harsher standard to the second. If the first is rough, you may become more lenient. Neither response produces fair or useful evaluations, and the problem compounds across three prototypes evaluated over several days.

The most effective countermeasure is procedural consistency. Use exactly the same systematic walkthrough process for every prototype, regardless of your initial impression of its quality. This means defining your walkthrough tasks before you begin each evaluation, working through the interface in a structured sequence rather than exploring freely, and completing at least two full walkthroughs per prototype — one focused on task completion and one focused on systematic heuristic checking.

Before starting each new evaluation, take a moment to review all ten Nielsen heuristics explicitly. This is not just a memory exercise — it is a deliberate cognitive reset. Reading the heuristics reactivates your evaluative framework and prevents you from drifting into a mode where you are only watching for the types of problems you found in the previous prototype. Each prototype may violate a very different subset of heuristics, and your walkthrough should be open to that full range.

The ten heuristics you must systematically apply to each prototype are:

• H1 — Visibility of system status: Does the interface keep users informed about what is happening through appropriate, timely feedback?
• H2 — Match between system and the real world: Does the system use language, concepts, and conventions that are familiar to the user rather than system-oriented terminology?
• H3 — User control and freedom: Can users easily undo and redo actions, and escape from unwanted states without having to go through extended processes?
• H4 — Consistency and standards: Are conventions followed consistently throughout the interface, and does the design conform to platform and industry norms?
• H5 — Error prevention: Does the design proactively prevent problems from occurring in the first place, rather than relying on error messages after the fact?
• H6 — Recognition rather than recall: Are options, actions, and information visible and retrievable without requiring the user to remember information from earlier in the interaction?
• H7 — Flexibility and efficiency of use: Does the interface support accelerators and shortcuts that allow experienced users to complete tasks more quickly?
• H8 — Aesthetic and minimalist design: Does the interface avoid presenting irrelevant or rarely needed information that competes with important content?
• H9 — Help users recognise, diagnose, and recover from errors: Are error messages expressed in plain language, do they precisely identify the problem, and do they suggest a constructive solution?
• H10 — Help and documentation: If help or documentation is necessary, is it easy to find, task-focused, and genuinely useful?

Performing a consistent number of walkthroughs per prototype is also important for controlling evaluation depth. If you conduct three walkthroughs of the first prototype and only one of the third because you are tired or pressed for time, the third report will almost certainly contain fewer findings — not because the prototype has fewer problems, but because you looked less carefully. Plan your evaluation sessions in advance, allocate similar time blocks to each prototype, and treat reduced thoroughness on a later prototype as a methodological flaw, not a time-saving measure.

Finally, keep your working notes from each evaluation completely separate. Use clearly labelled documents or folders, one per prototype, from the very beginning. Mixing notes, especially during the write-up phase, is a practical risk that can introduce errors and blur the boundaries between your three independent assessments. Treating each evaluation as a self-contained professional project — from first walkthrough to final report — is both good methodology and good professional practice.

In this topic you move from learning heuristic evaluation (HE) to performing it on real work produced by your classmates. The module assignment asks you to independently evaluate three peer prototypes, applying the full HE process to each: inspect the interface, identify usability problems, classify each problem under one of Nielsen's 10 heuristics, assign a severity rating, and recommend a concrete fix. The key word is independently — in a proper heuristic evaluation, each evaluator works alone first, and findings are only pooled afterward. Comparing notes with a peer before you finish contaminates your results and robs the designer of a genuinely independent perspective.

Two other expectations shape this assignment. The first is professional conduct: you are critiquing an interface, not a person. Write findings that are specific, evidence-based, and actionable ("the Save button gives no confirmation, violating Visibility of System Status") rather than vague or personal ("this screen is bad"). The second is calibration. Because you are reviewing three different prototypes, your severity ratings should mean the same thing across all three. A severity 3 on prototype A should represent roughly the same user impact as a severity 3 on prototype C, which usually means revisiting your earlier ratings once you have seen all three.

The two videos below come from Nielsen Norman Group, the organization that originated the method. As you watch the first, pay attention to the step-by-step workflow — especially the practice of evaluating alone and merging findings later, and how problems are tied to specific heuristics. The second video is about facilitating usability tests rather than HE, but watch it for tone: how an experienced professional frames a session, sets expectations, and makes clear that the interface is under scrutiny, not the person. That framing is exactly the attitude to bring to peer evaluation.

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

About this video

A short, practical walkthrough from Nielsen Norman Group on how to systematically inspect a product for usability and experience problems. It is likely to cover who performs the evaluation, how many evaluators are typically used, the steps of reviewing an interface against a set of heuristics, and how individual findings are recorded and later combined. Expect guidance on documenting each issue clearly enough that someone else can act on it.

Why this video

This is the core procedural video for the assignment: it comes from the group that developed the method and should directly address the independent-then-aggregate workflow you are required to follow across three peer prototypes.

NNgroup · 3:35 · 64,558 views · 3y ago · captions — Watch on YouTube

About this video

Facilitation experts demonstrate how to introduce and prepare a participant at the start of a usability test session, including the use of a facilitator's script. The demonstration shows how to set expectations, explain that the product rather than the person is being evaluated, and establish a neutral, respectful tone.

Why this video

Although it depicts usability testing rather than heuristic evaluation, it models the professional, non-judgmental communication standard expected when you deliver critique to a peer, and the scripted consistency it shows parallels the calibration you need across three prototypes.

The heuristic evaluation walkthrough gives you the procedure behind MO2: inspecting an interface systematically and attaching each observed problem to a specific one of Nielsen's 10 heuristics (MO1), which is also the backbone of the three-prototype assignment. Its emphasis on documenting findings so they can be understood and acted on by others supports MO3, where you must justify a severity rating and propose a targeted design improvement rather than a general complaint. The facilitation demonstration reinforces the professional conduct and consistency expectations of this topic, modeling the neutral, prepared tone that makes severity ratings and recommendations credible and comparable across all three peer prototypes you review.

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.