Evaluating Interfaces — Nielsen's 10 Usability Heuristics
A single-lesson introduction to heuristic evaluation for Year 11 Digital Technologies. Students learn Jakob Nielsen's ten usability heuristics, watch a modelled evaluation, then apply the heuristics themselves to a real website or app — building the evaluative vocabulary that underpins good interface design.
NCEA note: heuristic evaluation is standard evidence-gathering practice for Digital Technologies internals that require testing and justifying a digital outcome against usability criteria (Outcome Development & Delivery). This page deliberately does not cite a specific NZQA achievement standard code — confirm the exact standard and its wording against your department's current assessment before treating this lesson as assessment evidence.
Lesson Overview
Students already have a strong, if unarticulated, sense of when an interface is frustrating to use. This lesson gives that instinct a name and a method. Jakob Nielsen's ten usability heuristics (1994) are the industry-standard "rules of thumb" used by UX practitioners worldwide to evaluate interfaces quickly, without needing real user testing. The lesson moves from an intuitive hook, through direct instruction and a modelled evaluation, to students independently evaluating a real site or app and proposing a concrete fix.
Learning Intentions
- Explain what a usability heuristic is and why interface evaluation matters
- Identify and describe Nielsen's 10 usability heuristics
- Apply the heuristics to evaluate a real website or app and identify specific violations
- Propose a concrete, actionable design fix for at least one violation found
Success Criteria
- I can name and describe at least 6 of Nielsen's 10 heuristics
- I can identify a specific heuristic violation in a real interface and explain why it violates that heuristic
- I can propose a specific, actionable fix — not just "make it better"
Key Competencies
Thinking is the primary demand — evaluating a real interface against an abstract criterion and building an evidence-based argument for severity. Using language, symbols and texts is developed through the technical UX vocabulary and through writing precise, actionable design language rather than vague complaint. Managing self is required by the structured, time-boxed paired task with a concrete deliverable.
Key Concepts
A broad rule of thumb for good interface design — not a rigid rule, but a lens experts use to spot likely problems fast.
An expert-led method of checking an interface against a small set of heuristics — fast, cheap, and needs no real users (Nielsen's "discount usability engineering").
Nielsen's 0–4 scale for how serious a usability problem is, from cosmetic to catastrophic — used to prioritise what gets fixed first.
Designing around what real users need and how they actually behave, rather than what is easiest for the system to build.
Lesson Sequence
| Time | Phase | Activity | AFL |
|---|---|---|---|
| 5 min | Hook — Priming | Show two contrasting interfaces (or describe a genuinely annoying app/site everyone knows). Quick think-pair-share: "What exactly made that frustrating to use?" Capture 4–5 answers on the board without naming any heuristic yet — most will map loosely onto one. | Listen for intuitive schema; note which frustrations surface unprompted |
| 15 min | Direct Instruction — Building the Framework | Introduce Jakob Nielsen (1994) and the idea of a heuristic as a rule of thumb, not a rigid law. Walk through the 10 heuristics using the reference card, one concrete example each. Explicitly connect 2–3 heuristics back to the board answers from the hook. | Pause-and-check: "Which heuristic does that board answer belong to?" |
| 5 min | Modelled Evaluation | Teacher evaluates one heuristic live on a real site (e.g. checking Visibility of System Status on a checkout or form flow), thinking aloud through the worksheet's four columns: evidence, severity, and — critically — a specific proposed fix, not a vague complaint. | Check understanding of "specific fix" vs. "make it better" |
| 22 min | Application — Paired Evaluation | Pairs choose a website or app from the provided list (or one they already use). Complete the Heuristic Evaluation Worksheet for at least 4–6 of the 10 heuristics, prioritising evidence and a genuine fix over covering all 10. | Circulate; probe weak evidence ("what exactly did you see?") and vague fixes ("what would you actually change?") |
| 8 min | Share-Out | 2–3 pairs present their worst violation and proposed fix. Class briefly votes which is most severe and why, using the severity scale as shared vocabulary. | Peer evaluation against the severity scale |
| 5 min | Exit Ticket | "Name one heuristic, one app or site that violates it, and how you'd fix it." Collected. | Evaluates uptake of heuristic vocabulary and transfer beyond the lesson's chosen site |
Resources
Nielsen's 10 Heuristics Toolkit (Lesson Resource)
Ten printable reference cards (one per heuristic, with a plain-English restatement and a concrete example), the severity scale, and the full evaluation worksheet with reflection questions. Print one set per pair.
🖨️ Open printable resource →- Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group.
- Exit ticket slips (print from the toolkit, or use scrap paper)
Design Note
The hook deliberately withholds the heuristic names. Students should generate their own frustration-language first ("it doesn't tell you what's happening," "I couldn't undo it") so that the direct-instruction phase can show them that experts already have a name and a method for exactly what they noticed. This is the same design move as a card sort: the concept lands harder when the vocabulary arrives after the intuition, not before it. Resist the temptation to over-explain all 10 heuristics with equal depth — the 2–3 that connect to the hook deserve the most airtime.
Prior Knowledge
- Daily lived experience using apps and websites — no formal UX vocabulary assumed
- An intuitive but unarticulated sense of "annoying" vs. "easy to use"
- No prior knowledge of Nielsen, heuristics, or formal evaluation methods required — the lesson is designed to work from zero
Key Vocabulary
Differentiation
| Extension | Support / Scaffolding | ESOL / EAL |
|---|---|---|
| Evaluate against all 10 heuristics instead of 4–6. Research one additional framework (e.g. Shneiderman's 8 Golden Rules) and note one point where it agrees or disagrees with Nielsen. | Work through the teacher-modelled example row together before starting independently. Reduce the target to 3 heuristics. Allow verbal completion of the evidence column with the teacher or a peer scribing. | Reference cards already pair the technical heuristic name with a plain-English restatement — point students to that line first. Accept bullet-point evidence rather than full sentences. Pair with a first-language buddy where available. |
Transition Management
- →Hook → direct instruction: move straight from the board answers into the framework while the frustration examples are still fresh — don't let the energy drop.
- →Direct instruction → modelled evaluation: have the demo site already open in a tab before instruction ends, so there's no dead time finding it live.
- →Modelled evaluation → paired application: hand out the toolkit and confirm pairs before releasing them to choose a site — a slow site-choice negotiation eats the task time fast.
- →Application → share-out: give a 1-minute warning before time is up so pairs can pick their "worst violation" to present rather than scrambling at the bell.
Teacher Reflection (Post-Lesson)
Did the hook generate frustration-language that genuinely mapped onto the heuristics, or did the connection feel forced? What would sharpen the hook next time?
Were students able to write specific, actionable fixes, or did most default to vague "make it better" statements? What scaffold would close that gap?
How many heuristics did most pairs realistically complete well in the time given? Was 4–6 the right target, or should the next iteration narrow further?
What patterns appear in the exit tickets? Which heuristics transferred to a new app/site the student chose themselves, versus only the one used in class?