Error page guidance

Posted on 23 June 2025

The problem

The NHS App had no definitive, agreed upon design pattern or guidance for error pages, with a lot of variation.

Screenshots of various error pages used across the NHS App

Without consistent error page patterns, designers repeatedly solved the same problems from scratch, creating fragmented experiences across different parts of the NHS App. This approach led to internal inefficiency and inconsistent error handling throughout the NHS App.

We recognised that we needed standardised error guidance to ensure cohesive, predictable error patterns across all areas of the NHS App.

Past work

A team updated a set of 27 native error pages in 2023. Their work made some progress in exploring a potential design pattern for error pages.

We had a small amount of past user research evidence available, and we found some past content guidance on Confluence.

User insight: “Users do not read information on error pages when a primary (green) button is present, as it prompts them to move on”.

Gathering existing error pages

We gathered details of existing error pages (more than 80) across the NHS App to understand the current landscape and identify inconsistencies.

We categorised and defined different types of errors, mapping them to user scenarios and technical causes.

Reviewing existing guidance

We researched existing guidance and best practice from established design systems, including:

This helped us identify gaps between current NHS App error handling and proven approaches.

Design and research

We tried out some updated designs using the prototype kit and the latest NHS App design components.

Screenshots of of the error pages designs we tested

We ran usability testing on two error scenarios as part of wider design system research to validate our approach with real users.

Design hypothesis 1

If a primary button is changed to a secondary button, then users will read the information on error pages.

We’ll know this is true when users can be observed spending time reading the information before acting on the information presented on the error pages.

Design hypothesis 2

If we remove the red warning icon, then users will still understand what the page is about.

We’ll know this is true when users correctly interpret the purpose of the error message.

Research findings

We found that:

using a secondary button didn’t make much difference in slowing users down
most users read the page heading and then promptly selected the button
most users didn’t read content below the button
without a red warning icon they still understood the purpose of the page
most overlooked error codes on the pages, at least initially
users were not always clear whether the problem was their fault or a fault with the app
all users were able to navigate from the tested error pages towards either a resolution or an alternative service

“I just want to bulldoze my way through”

Iterating guidance

We iterated our draft pattern guidance many times, incorporating feedback and learnings from other teams.

We spoke with the Service Management team and developers to start thinking about error codes, and how we might better help users to ‘self-serve’ in common error scenarios in the future.

We held regular meetings with developers to ensure we addressed feasibility and implementation considerations.

support teams who are updating error screens within their service journeys, including the GP services and prescriptions teams
continue capturing user insights and improving guidance based on real-world usage and feedback
share our work with the NHS service manual team for potential inclusion in the main NHS design system