Heuristic Evaluation & Usability Inspection
Heuristic Evaluation
& Usability Inspection
Inspect key user tasks against ten usability principles, record evidence and explain the severity of the problems you identify.
Module overview & learning objectives
Heuristic evaluation is a structured inspection of an interface against established usability principles. It helps evaluators identify potential barriers that could prevent users from understanding the interface, completing tasks or recovering from mistakes.
Use the pages and three to five key tasks selected in Module 1. Apply ten usability heuristics, record evidence, explain potential user impact and assign severity ratings.
By the end of this module, you should be able to:
- Explain the purpose and limitations of heuristic evaluation.
- Apply ten usability heuristics to pages and interactions.
- Inspect complete task sequences on desktop and mobile.
- Record findings with clear, reproducible evidence.
- Assign severity ratings using consistent criteria.
- Produce a completed checklist and UX issue log.
Heuristic Evaluation Checklist & UX Issue Log
Understanding heuristic evaluation
A heuristic is a general principle that guides the assessment of usability. The evaluator examines how well the interface supports that principle within a specific task context.
A useful finding connects the observed interface behaviour to a relevant principle and a potential effect on the user’s task.
Example: enquiry submission
A loading indicator communicates that the system is processing an enquiry. If the interface then returns to a blank form without confirmation, the user may be unsure whether the submission succeeded.
Inspect the feedback throughout the interaction, including loading, success, empty and error states.
Expert inspection identifies likely usability barriers. User research and usability testing provide evidence of how people actually behave.
The ten usability heuristics
Expand each heuristic to review its inspection focus and a course-website example. The examples illustrate potential problems rather than findings from a live audit.
1. Visibility of system status
Keep users informed about what is happening through timely, understandable feedback.
Inspect for
- Loading and processing indicators
- Confirmation after an action
- Progress through a multi-step process
- The current page, selection or state
Example issue: After an enquiry submission, the interface shows no confirmation or next step.
Potential impact: Users may repeat the submission or leave uncertain whether it succeeded.
2. Match between the system and the real world
Use language and concepts users understand, with information in a familiar, logical order.
Inspect for
- Plain language and meaningful labels
- Familiar date, price and measurement formats
- Explanations of specialist terminology
- Information ordered around user needs
Example issue: A course application uses “intake code” without explaining its meaning.
Potential impact: Prospective learners may struggle to select the correct course start date.
3. User control and freedom
Allow users to leave unwanted states, revise choices and recover from accidental actions.
Inspect for
- Clear cancellation and back options
- Opportunities to edit previous answers
- Undo or recovery where appropriate
- Preservation of information between steps
Example issue: Returning to an earlier application step clears all previously entered information.
Potential impact: Users must repeat their work and may abandon the task.
4. Consistency and standards
Use consistent words, controls and interaction patterns, and follow familiar conventions.
Inspect for
- Consistent terminology
- Predictable button and link behaviour
- Consistent navigation and form patterns
- Familiar visual and interaction conventions
Example issue: Apply, Register and Enrol describe the same action on different course pages.
Potential impact: Users may be unsure whether these actions lead to different processes.
5. Error prevention
Help users avoid mistakes before they occur.
Inspect for
- Clear instructions before data entry
- Suitable input controls and constraints
- Required formats explained
- Confirmation before consequential actions
Example issue: A date field provides no format guidance and accepts an ambiguous entry.
Potential impact: Users may submit an unintended date or encounter avoidable validation errors.
6. Recognition rather than recall
Make relevant information and options visible so users do not need to remember them across steps.
Inspect for
- Visible labels and instructions
- Summaries of previous selections
- Accessible reference information
- Clear options at decision points
Example issue: A comparison page requires users to remember fees from separate course pages.
Potential impact: Comparing courses becomes more demanding and error-prone.
7. Flexibility and efficiency of use
Support efficient task completion for users with different experience levels.
Inspect for
- Useful search, filtering and sorting
- Shortcuts for repeated actions
- Appropriate autofill or saved information
- Avoidable steps and repeated entry
Example issue: The course listing cannot be filtered by study mode.
Potential impact: Users must browse many course pages to find a suitable option.
8. Aesthetic and minimalist design
Prioritise relevant information and reduce unnecessary distractions.
Inspect for
- Clear visual hierarchy
- Relevant content at each step
- Prominent primary actions
- Promotional elements competing with essential information
Example issue: Promotional banners appear before entry requirements and course fees.
Potential impact: Users may overlook information needed to make a decision.
9. Help users recognise, diagnose and recover from errors
Explain the problem in understandable language and help users correct it.
Inspect for
- Specific messages near the affected field
- Clear explanations of what went wrong
- Practical correction instructions
- Preservation of valid entries
Example issue: A form displays “Invalid input” without identifying the affected field.
Potential impact: Users must guess what to change and may repeatedly fail to submit.
10. Help and documentation
Make relevant assistance available when users need it.
Inspect for
- Help near complex tasks or unfamiliar fields
- Searchable or clearly organised support
- Practical instructions
- Accessible contact options
Example issue: Entry requirements mention equivalent qualifications without explanation or a contact route.
Potential impact: Users cannot confidently determine their eligibility.
Prioritise useful information. Removing necessary instructions can make the interface harder to use.
Inspecting pages & task sequences
Use the scope and key tasks from Module 1. Follow the complete sequence needed to achieve each goal.
- Record the starting page, device context and relevant conditions.
- Follow a realistic route towards the task goal.
- Examine information, controls and feedback at each step.
- Inspect relevant alternative states, such as missing information or invalid form entries.
- Record potential heuristic violations with supporting evidence.
- Determine whether the task can be completed and what may obstruct it.
| Desktop inspection | Mobile inspection |
|---|---|
| Visible navigation and information hierarchy | Collapsed menus and stacked content |
| Keyboard interaction and focus behaviour | Touch controls and on-screen keyboards |
| Routes between relevant pages | Information inside expandable sections |
| Form entry and system feedback | Form entry, error messages and confirmation |
Use the same task goals across devices. Record the browser and viewport, and identify simulated mobile contexts explicitly. If several evaluators participate, inspect independently before comparing findings.
Use authorised test accounts or environments for submissions and record changes. If access is unavailable or an action cannot be inspected safely, record that limitation.
Heuristic evaluation checklist
Use the checklist to record what you evaluated. Repeat it for relevant pages and interactions within your scope.
| Heuristic | Inspection question |
|---|---|
| System status | Does the interface explain what is happening during and after an action? |
| Real-world language | Are labels, terminology and information sequences understandable? |
| User control | Can users cancel, return or revise without unnecessary loss? |
| Consistency | Do similar elements use consistent language and behaviour? |
| Error prevention | Does the interface help users avoid foreseeable mistakes? |
| Recognition | Is necessary information visible when users need it? |
| Efficiency | Can users complete the task without avoidable effort? |
| Minimalist presentation | Are essential information and actions easy to distinguish? |
| Error recovery | Do messages explain the problem and how to correct it? |
| Help | Is relevant assistance available at the point of need? |
For each assessment, record its status, supporting notes and any linked issue ID.
| Assessment status | Meaning |
|---|---|
| No issue observed | No problem identified in the inspected context. |
| Issue observed | A finding needs an entry in the UX issue log. |
| Not applicable | The principle does not apply to this interaction. |
| Not evaluated | You did not inspect this aspect. Explain why. |
“No issue observed” applies only to the inspected context. It does not establish that the interface has no usability problems.
Recording findings in the UX issue log
Write each finding so another evaluator can locate and understand the problem. Use one entry per distinct problem. Associate secondary heuristics where useful without duplicating the finding.
| Field | What to record |
|---|---|
| Issue ID | A unique reference, such as UX-01. |
| User task | The task affected. |
| Page or location | The page, component or interaction. |
| Device context | Desktop or mobile, with browser and viewport details. |
| Steps | The sequence needed to reproduce the observation. |
| Observation | What the interface displayed or did. |
| Evidence | Screenshot, message, URL or documented state. |
| Heuristic | The primary principle affected. |
| Potential user impact | How the issue could affect the task. |
| Severity | A rating with a brief justification. |
| Improvement direction | An initial suggestion addressing the problem. |
| Limitations | Assumptions, access restrictions or untested behaviour. |
| Evidence layer | Example |
|---|---|
| Observation | On mobile, fees appear in a collapsed section labelled “Additional details.” |
| Interpretation | The label does not indicate that the section contains pricing. |
| Potential user impact | Users comparing costs may overlook the fees. |
Worked example: UX-01
Task: Submit a course enquiry.
Location: Enquiry form, email field.
Device: Mobile viewport, 390 pixels wide.
Steps: Enter an email address without “@” and select Submit.
Observation: “Invalid input” appears above the form without identifying the email field.
Evidence: In a real audit, attach a screenshot of the message and record the exact test steps. This example is illustrative.
Primary heuristic: Error recognition and recovery.
Potential impact: Users may be unsure which entry needs correction.
Severity: 3, because the issue interrupts a key task and correction may require substantial guessing.
Improvement direction: Identify the affected field and provide a specific correction message.
Limitation: Actual user behaviour has not been tested.
Assigning severity ratings
Severity communicates how seriously an issue may affect the user experience. Use a shared scale and justify each rating in context.
| Rating | Description | Typical consequence |
|---|---|---|
| 0 | No usability problem | No actionable problem established. |
| 1 | Cosmetic problem | Minor presentation concern with little effect on task completion. |
| 2 | Minor usability problem | Friction, while the task remains reasonably achievable. |
| 3 | Major usability problem | Substantial difficulty, errors or a demanding workaround. |
| 4 | Critical usability problem | An essential task is blocked, or a serious consequence has no reasonable recovery. |
Factors to consider
- Impact: How much does the issue interfere with the task?
- Frequency or reach: Under what conditions, and for which users, might it occur?
- Persistence: Can users recover easily, or does the problem recur?
Distinguish observed occurrence from estimated frequency. A single walkthrough establishes that an issue exists under particular conditions. It cannot establish how often users encounter it.
Severity is one input to prioritisation. Module 4 will also consider implementation effort, business context and dependencies.
Practical activity & submission
Evaluate the pages and interactions within your Module 1 audit scope.
- Prepare the heuristic evaluation checklist.
- Walk through each selected task on the included devices.
- Record findings with clear evidence.
- Assign a primary heuristic and severity rating to each issue.
- Explain the potential impact and rating.
- Review vague wording, duplicate findings and unsupported claims.
Learning output requirements
- A completed checklist for the inspected pages and interactions.
- Clear task and device context.
- Distinct, reproducible findings with supporting evidence.
- Relevant heuristic classifications.
- Consistent severity ratings with brief justifications.
- Explicit assumptions, exclusions and evaluation limitations.
Another evaluator should understand where each problem occurs, why it matters and what evidence supports it. This output contributes to Module 3’s navigation audit and Module 4’s prioritisation work.
Review & reflection
Consider each prompt before expanding the suggested response.
What distinguishes observation from potential impact?
An observation describes directly verifiable interface behaviour. Potential impact explains how that behaviour could affect a user task. Research or testing is needed to establish actual behaviour.
Can one problem relate to multiple heuristics?
Yes. Record one distinct finding, select a primary heuristic and add relevant secondary principles. Avoid duplicate entries for the same underlying problem.
What supports a severity rating?
Explain the task impact, likely conditions of occurrence and ease of recovery. State assumptions and distinguish estimated frequency from measured evidence.