Unhappy path pages

[Graham-Pembrey]

What

Pattern for unhappy path pages (terminology TBC).

These pages show when the NHS App stops a user from continuing with their journey for an expected reason. For example, because:

• they are not eligible for a service or the whole NHS App
• they do not have access
• they need to update the app
• there is a lack of availability for the thing they need

These pages happen when the system is functioning correctly by stopping the user from continuing. This is different from unexpected error pages, where there is a technical problem and something has gone wrong.

Why

Teams have been using our error page guidance to design both technical errors and 'unhappy path' pages. We've started to realise there may be a need to separate the two and create a clearer distinction.

Related issues

• NHS App error pages
• NHS service manual not eligible page pattern

[Graham-Pembrey]

Some existing examples:

[zachrigby-nhs]

What

On the GP Services team we recently spent some time uplifting all of our error screens in the appointment booking journey to conform to the recently published error guidance.

Why

We uncovered many 'error' screens in the user journey with various triggers causing them. Some triggers had multiple, very similar screens and many were generally lacklustre in terms of patterns, content and signposting.

How

One of the first tasks we did to help us redesign the screens was to group the screens into 'errors' and 'unhappy paths'.

In appointment booking, an 'error' would be a scenario where something has gone wrong, such as a server or API issue. An 'unhappy path' occurs when a user who tries to book an appointment experiences an undesirable outcome not caused by something breaking. For example, a user who's GP doesn't give them permission to book appointments directly via the NHS App will see a screen informing them that they cannot book appointments. In this scenario, everything has worked as expected, just not in a way that the user would have liked.

Once we had distinguished these groups, we started designing the uplifted error pages and initially conformed as closely as possible to the error guidance. After we had applied the changes across our error screens, we stood back and made some observations about their effectiveness.

Observations

1. 'If the problem continues' subheading is not useful in such permissions-based unhappy paths

• There is nothing a user can do in this scenario to fix the problem (the problem will very much continue)
• The problem will continue unless the GP changes the permissions
• 'If the problem continues' subheading implies that there has been a problem, when technically nothing has gone wrong

For these reasons, permissions-based unhappy paths on the appointment booking journey likely shouldn’t include the 'if the problem continues' subheading, but keen to hear thoughts

2. Error codes should always be displayed to help the Service Management team better understand the issue a user is reporting, but they don't help the user find routes to care as well as other content on the page might

• After speaking with the Service Management team, promoting the use of error codes can save them days in being able to provide guidance to users encountering issues in the app, so they should be presented wherever possible
• 'Make a note of the error code...' sounds quite directive when the action is optional and doesn’t quickly help the user find alternative routes to care. If we are to start showing this content on more error and unhappy pages (as the Service Management team would prefer), to prevent users taking this action ahead of other potentially more useful actions on the page, we’ve experimented with softening the content. ‘For more information, make a note of the error code…’ under the subheading ‘Contact the NHS App team’ further down the page, to promote other options on the page they can pursue to find care first.

3. 'Other options in the NHS App'

• Some of the 'other options in the NHS App', such as the OLC option ('Contact your GP about a health problem) might be a much better option for them, and in many cases a preferred option for their GPs and should be presented to the user further up the page ahead of less useful content. In these instances, we’ve experimented with removing the subheading and raising the panel link up the page, along with making it a primary panel link in instances where its highly likely to help solve the users problem.

Before and after screenshots of following the current guidance more closely vs making some tweaks based on our own observations: