Confusing Terms — Prevention vs. Recovery, Flexibility vs. Control
Students already know all 10 of Nielsen's heuristics by name from Task 3. This lesson doesn't teach new heuristics — it teaches students to tell two genuinely confusable pairs apart, because the external exam rewards precision, not recognition.
Learning Intentions
- Distinguish "Help Users Recognise, Diagnose & Recover from Errors" from "Error Prevention"
- Distinguish "Flexibility & Efficiency of Use" from "User Control & Freedom"
- Find and justify a real example of each of the four heuristics inside a live interface
Success Criteria
- I can classify an interface element as prevention or recovery, and use timing and function as evidence
- I can classify a feature as flexibility or control, and explain my reasoning when the surface answer is ambiguous
- I can identify, explain and evaluate one real usability issue in my own learning platform
Say this out loud in class: the formal progression is Achievement — demonstrates understanding; Merit — examines; Excellence — evaluates. Describe and explain are useful response moves inside that progression, but “identify / explain / evaluate” is not the standard's formal ladder. Full evaluation adds like-for-like comparison and a principle-grounded improvement.
Lesson Sequence
| Time | Phase | Activity | AFL |
|---|---|---|---|
| 5 min | Retrieval Hook | Pairs: "Name as many of Nielsen's 10 heuristics as you can in 90 seconds." Collate on the board. Frame the lesson: "Today isn't new heuristics — it's telling confusable ones apart, because that's exactly what the exam tests." | Gauge retention from Task 3 |
| 5 min | Frame the Stakes | Show the current Achievement/Merit/Excellence progression: demonstrates understanding / examines / evaluates. Translate that into describe purpose and use / explain application and effect / compare and improve. | Check students can distinguish the formal criteria from response-building verbs |
| 10 min | Direct Instruction — Pair 1 | Teach Recovery vs. Prevention using the reference cards. Treat colour and visual state only as possible clues; timing and function decide whether a feature prevents an error or helps after it occurs. | Cold-call: “when does it appear, what does it do, and why?” |
| 10 min | Guided Classify — Table 1 | Whole class works through the 4-item Recovery/Prevention table together. Cold-call for reasoning, not just the label — see the answer key below for the one genuinely ambiguous item. | Listen for reasoning language, not guessing |
| 8 min | Direct Instruction — Pair 2 + Paired Classify | Teach Flexibility/Efficiency vs. Control/Freedom. Pairs then work Table 2 independently — circulate specifically to the two trap items (Ctrl+Z, revert to default). | Probe the two trap items directly |
| 15 min | Your Learning Interface | Teacher models one example live on Google Classroom first (see modelled examples below), then pairs screenshot one real example of each of the four heuristics from their own class's Google Classroom. | Circulate; check evidence, not just a label |
| 7 min | Exit — Understand / Examine / Evaluate | Written: describe the purpose, feature and principle; explain the effect on a named user/task; compare the same action in another learning interface; then suggest and justify one specific improvement. | Formative — direct rehearsal of the current achievement progression |
Answer Key — with Reasoning
Table 1 — Recovery vs. Prevention
"A red box says 'Password must include a number'" Discussion point
Recovery after submit; prevention if it acts before the errorIf the message appears after a failed submission, it helps the user diagnose and recover. If it appears live before submission and blocks the invalid state, a prevention argument is defensible. The same visual element can serve either heuristic depending on when it appears and what it enables, not its colour.
"The 'Next' button is greyed out until all steps are done"
Error PreventionMatches the given example almost verbatim (submit button greyed out until required fields filled).
"A pop-up says 'Are you sure you want to delete this file?'"
Error Prevention; user control/freedom also defensibleA confirmation can interrupt a likely destructive error before it is completed. It can also give the user a final escape from an action, so user control/freedom is defensible when the response explains that mechanism. Reward causal justification, not one-label matching.
"You click a broken link and get a 404 error page with help links"
Help Users Recognise, Diagnose & Recover from ErrorsThe error has already happened; the page explains what went wrong and offers a way forward.
Table 2 — Flexibility vs. Control
"Ctrl+Z to undo" Trap item
User Control & FreedomThis is the whole point of the confusable pair. Ctrl+Z is invoked by a keyboard shortcut, which looks like it belongs under Flexibility ("look for: keyboard shortcuts"). But classify by function, not input method: what the feature does is reverse a mistake — an escape hatch — which is Control & Freedom's whole definition. A keyboard shortcut is just how you trigger it; ask "what does this let the user escape or reverse?" before "how do you activate it?"
"A drop-down with filter by price or rating"
Flexibility & Efficiency of UseA genuine sorting/filter tool, offering a different route to the same task — no ambiguity here.
"'Cancel order' button"
User Control & FreedomA direct match to the "cancel buttons" example in the reference card.
"Option to revert to default settings" Trap item
User Control & FreedomTempting to call this Flexibility (it's a "settings/personalisation option"), but the same test applies: reverting is undoing accumulated changes to get back to a known-safe state — an escape hatch from your own customisation, not a new route to a task.
Modelled Examples — Your Learning Interface
Model ONE example live before releasing pairs — these two are drawn directly from this class's own Google Classroom, so they're real, not generic. Confirm they still match before the lesson, since Classroom's UI can change.
Unposted classwork (Task 6, Task 7 items) sits as "Draft" — invisible to students until the teacher deliberately clicks Post. This prevents the error of unfinished material appearing in the live class feed before it's ready.
Posted classwork can be edited after publishing (visible as "Edited Jul 20", "Edited Yesterday" in the feed). The teacher isn't locked into what was first posted — a genuine escape hatch for a mistake made after publishing, not before it.
Error Recovery and Flexibility/Efficiency examples are better modelled live in front of the actual class feed on the day — Classroom's exact UI at the time of teaching will show clearer, more current examples than anything pre-written here.
Resources
Task 6 Student Worksheet (clean, no answers)
The two explainer cards, both classify tables, the Your Learning Interface screenshot task, and the demonstrate-understanding/examine/evaluate reflection — safe to upload directly to Google Classroom.
🖨️ Open printable resource →- New Zealand Qualifications Authority. (2023). Current Level 1 Digital Technologies standard — Demonstrate understanding of usability in human-computer interfaces.
- Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group.
Design Note
The two "trap" items (Ctrl+Z, revert to default) are the actual teaching point of this lesson, not edge cases to smooth over. Resist giving the answer fast — let a wrong first guess happen, then ask "what does this feature let you do?" rather than "what triggers it?" That question is the transferable skill: students who can separate a heuristic's function from its input mechanism will handle novel exam interfaces they've never seen, not just the ones rehearsed in class.
Transition Management
- →Hook → framing: keep the board list of heuristics visible/on-screen through the framing step — don't erase it before naming the achievement ladder.
- →Guided Table 1 → Pair 2 instruction: don't let the Table 1 discussion (especially the "when does it appear" debate) run long — bank it as "great exam-level thinking" and move on, or Table 2 loses its allotted time.
- →Paired Table 2 → Your Learning Interface: have Google Classroom already open and logged in before releasing pairs to the screenshot task — no dead time hunting for the tab.
- →Application → exit ticket: give a 1-minute warning so pairs pick their strongest example to write up, rather than scrambling at the bell.
Teacher Reflection (Post-Lesson)
Did the "when does it appear" discussion on the password example land as intended — genuine exam-level reasoning — or did it just confuse students? Worth keeping next time?
Could most pairs correctly classify Ctrl+Z and "revert to default" by the end, or does the function-vs-mechanism distinction need a second pass before Task 7?
Did the modelled Google Classroom examples (Draft status, Edited posts) still match the live UI? Update this page if not.
In the exit tickets, did students genuinely evaluate (compare, judge and justify an improvement) or stop at demonstrating understanding/examining? What's the scaffold for next time?