← QCE Digital Solutions Unit 3

Heuristic review of an interface

Checking an existing interface against usability rules of thumb (e.g. Nielsen's heuristics), then recording each problem found with its severity and screen evidence.

Part of: QCE Digital Solutions Unit 3 — Innovative Digital Solutions — Module 79

Understanding Heuristic review of an interface in QCE Digital Solutions Unit 3

What it does: Severity ratings let the team prioritise fixes. A rating of 4 is the highest on the common 0-4 scale and is fixed first. A review record names the screen, the heuristic broken and the evidence, so others can see exactly where the problem was found. A heuristic review judges an existing interface against recognised usability rules (like Nielsen's heuristics). It is not code testing. Users should always be told what the system is doing, for example with a loading bar or a 'Saved' message. Good design stops errors before they happen, for example by limiting the field to digits or checking as the user types.

Common mistakes: Nielsen's severity rating scale runs from 0 to 4, so 7 is not a valid rating. The severity should be a number from 0 to 4, such as 3. A missing loading indicator breaks 'visibility of system status', not 'help and documentation'. The line should be rule = "System status".

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Heuristic review of an interface to a class →

This module's key terms are also in a printable crossword (Modules 251–337) and word search (Modules 194–337).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which best describes a heuristic review?
Checking an interface against usability rules of thumb and recording each problem foundRunning the program with test data to see if the code crashes
Matches
Finding: I just don't like the colours on the Login screen.
↓
This is a personal opinion, not a problem linked to a named heuristic. A heuristic review must say which usability rule is broken and give evidence.
Applying
Meanings
Term
heuristic review
Meaning
Checking an existing interface against usability rules of thumb (e.g. Nielsen's heuristics), then recording each problem found with its severity and screen evidence.
Practice
Screen: Checkout page
Testing
Gaps
Heuristic:
Check Answer
Spots
3 "heuristic": "Consistency",
4 "severity": 7

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Giant Squid' badge — Nested Navigator, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Which best describes a heuristic review?
A. Running the program with test data to see if the code crashes
B. Checking an interface against usability rules of thumb and recording each problem found ✓
A heuristic review judges an existing interface against recognised usability rules (like Nielsen's heuristics). It is not code testing.
2. A student taps Submit on a form and nothing shows that it is loading or saved. Which heuristic is broken?
A. Visibility of system status ✓
B. Consistency and standards
Users should always be told what the system is doing, for example with a loading bar or a 'Saved' message.
3. A form lets users type 'abc' in a phone number field and only complains after submitting. Which heuristic would you record?
A. Error prevention ✓
B. Aesthetic and minimalist design
Good design stops errors before they happen, for example by limiting the field to digits or checking as the user types.
4. One screen uses a red button labelled 'Delete' and another uses a green button labelled 'Remove' for the same action. Which heuristic is broken?
A. Consistency and standards ✓
B. Help and documentation
The same action should look and be named the same across screens so users do not have to guess.
5. Which is the best way to record evidence for a problem found in a heuristic review?
A. Write 'the app is confusing' with no screen or detail
B. Note the screen name, attach a screenshot and describe what you saw ✓
Evidence should be specific and traceable so another reviewer can find and verify the problem.

Match the Pairs

Heuristic: Visibility of system status → The interface keeps users informed about what is happening, for example with a progress bar or a confirmation message after an action.
Heuristic: Error prevention → The design stops mistakes before they happen, for example by greying out invalid options or asking for confirmation before a delete.
A reviewer rates how serious a problem is on a 0-4 scale, where 4 is a usability catastrophe that must be fixed first → Severity: 4 (catastrophe)
Each problem is logged with the heuristic it breaks, the screen it was found on and the evidence, so the review can be checked by others → Screen: Checkout | Heuristic: Consistency | Evidence: Screenshot 3
Finding: I just don't like the colours on the Login screen. → This is a personal opinion, not a problem linked to a named heuristic. A heuristic review must say which usability rule is broken and give evidence.
Finding: Delete button has no confirmation. Severity: none recorded. Evidence: none. → The finding has no severity rating and no screen evidence, so the team cannot prioritise the fix or check that the problem is real.

Key Term

heuristic review
Checking an existing interface against usability rules of thumb (e.g. Nielsen's heuristics), then recording each problem found with its severity and screen evidence.

Fill in the Blanks

1. Problem: No progress bar after tapping Pay Heuristic: Visibility of system status
Hint: Type the Nielsen heuristic that is broken when the user gets no feedback about what the system is doing
2. Problem: Delete button has no confirmation Heuristic: Error prevention
Hint: Type the heuristic about stopping mistakes before they happen
3. Problem: Save icon differs on each screen Heuristic: Consistency and standards
Hint: Type the heuristic about using the same look and behaviour across screens
4. Scale: 0 = no problem, 4 = catastrophe Problem: Checkout crashes for every user Severity: 4
Hint: Type the severity rating from the scale that suits the worst kind of problem
5. Screen: Login page Problem: Error message only says Code 0x4F Evidence: Screenshot 3, red error banner
Hint: Type the label for the field that records proof taken from the screen

Spot the Error

Question 1
A finding = {
B "screen": "Checkout",
C "heuristic": "Consistency",
D "severity": 7
E }
Line D — Nielsen's severity rating scale runs from 0 to 4, so 7 is not a valid rating. The severity should be a number from 0 to 4, such as 3.
Question 2
A problem = "No loading indicator"
B severity = 3
C rule = "Help and docs"
D print(problem, "-", rule)
Line C — A missing loading indicator breaks 'visibility of system status', not 'help and documentation'. The line should be rule = "System status".
Question 3
A findings = []
B findings.add("Tiny font")
C findings.append("No undo")
D print(len(findings))
Line B — Python lists have no add() method. To record a new problem in the list, use findings.append("Tiny font").
Question 4
A evidence = "Screenshot 4"
B problem = "Button label unclear"
C note = problem - " / " - evidence
D print(note)
Line C — Strings cannot be subtracted. Join the problem and its screen evidence with +: note = problem + " / " + evidence.
Question 5
A severity = 4
B if severity >= 3
C print("Fix before release")
D else:
E print("Fix later")
Line B — An if statement must end with a colon. It should be: if severity >= 3:

Student with a class code? Join your class →