Helping users recover from an error
People’s expectations around accessing public health services digitally doesn’t include an error-404-deadend. So, how do we ensure public expectations are met
Introduction
As someone who uses websites and apps, errors are something I barely think about. Errors are like that corner of a city people often pass through but rarely remember. This is despite ‘404 page not found’ being one of the most common webpage people encounter. So, when I was asked to ‘help fix the help centre’ by the team responsible for helping users register to use the NHS app, I wasn’t quite sure what to expect.
THE PROBLEM
The NHS app allows people to book GP appointments, order repeat prescriptions among other things, but before people can access these goodies, they first must complete a registration process through NHS login. This registration process has different steps of security checks which ranges from simple to complex. Within these steps are where users often encounter errors and get stuck. This leads to them not completing registration and not getting the benefits the app provides.
The Help Centre
There was a collective effort to help users get unstuck by creating a ‘help centre’. The hope was that whenever a user encountered an error, the help centre will provide enough information to the user why the problem happened and what they could do to fix it.
It was difficult to tell if the suggested help centre was working as intended so a research audit was conducted.
When the research audit was done, it discovered that only 1.3% out of 1.5 million users who encountered an error visited the help centre in November 2020. Fast forward to May 2021, out of 6.8 million people who completed the registration journey, only 78k (1.1%) visited the help centre. There was no clear sign the solution was working or not.
When the help centre was tested with users, it found that:
- Users did not feel there was a need to send them to another page to explain why the error happened
- Users felt more confused rather than helped when navigating the help centre
- There were a lot of inconsistencies in how things were presented to the user
- The user flow to the ‘contact us’ form was confusing, thus users clicked on any they found which led to incorrect calls being logged to support staff
Examples of what users told us
User 6: “If it knows that’s what the problem is, it would be useful to just show it on the previous page rather than having to click onto a different page. I don’t need any of this other information”
User 8: Scrolls up and down the page and remarks “All these numbers are bit confusing to me”
User 10: “I’m guessing it (contact form) goes to a human…who will have to see whether I selected the right code vs what I wrote in the message…”
What we did
The initial ask was to “fix the help centre”, but upon looking at the research audit, speaking to people in the know (support staff, designers and developers), it became clear the task wasn’t to ‘fix the help centre’ but to provide ways to ‘help users recover from errors’
Tackling the issue was a case of following the research recommendations, one of which was to provide much of the help in the error screen if possible. This was helpful because whenever users went from the error to the help centre, there was no obvious way for them to return to the error screen unless they clicked the native browser back button.
The team decided it was beneficial to tackle the issues in sequence of focusing on error screens first, then help centre afterwards.
WORKSHOP
So, we started our journey by taking some example error screens to a design workshop. The example errors were based on data volume for month of May 2021 which were:
- Error 1005 — The highest with 2,448 views
- Error 0003 — This had 1,140 views but it was not an error but rather a way to report accessibility issues
- Error 2011 — This had 1,015 views, but the data was not reliable due to help centre’s weak information architecture
- Error 7023 — This had 760 views, but the data was also not reliable due to help centre’s weak information architecture
At the workshop, we brainstormed ideas of how could create consistent ways to help users recover from errors, this led to a series of themes and sketches which revolved around:
- Providing much of the help within the error screen
- Using more explicit language and making the content less confusing or jargon filled
- Re-styling series of elements in order of importance
- Making sure the help centre hyperlink informs the user it will take them out of the current journey
These themes were to be funnelled into a template which could be applied consistently across all system errors.
SKETCHING
I looked at different design patterns for errors and asked around the wider design community about how they have styled errors to broaden my knowledge.
I converted these themes and sketches into prototypes in hopes that we would start building towards a template.
These consisted of:
- An error/help screen where everything was given equal importance on the page
- An error/help screen split with problems on the page and the help provided in a card
- An error/help screen with a split where only the contact us link was in a card
We were to test all these with users but to save time, we asked the design group to vote on which version we should test first. The one with help provided in a card came out as favourite.
Usability testing
We had three hypothesis we wanted to prove or disprove with the card template:
- Hypothesis A: If we put a portion of the help centre content on the error screen, would it help reduce users’ confusion about what they need to do?
- Hypothesis B: If we added a recovery option like a ‘try again button’ or a ‘refresh link’, would it help users feel confident to recover?
- Hypothesis C: If we restyled the help centre link on the page to be more obvious it would take the users outside the page, would it help users know and weigh more options available outside the error screen?
We tested the prototype with 10 people from a mix of different demographics. We found that hypothesis A and B worked as intended. Users reacted positively to the help being provided there on the error screen. In some cases, they skipped the problem description and went straight to the help card or straight to the recovery ‘try again’ button. Some users even expected a link to re-centre themselves back to the homepage of the NHS app.
Hypothesis C had ‘mixed’ results. For the most part, it worked in terms of most users recognising what it was, but 2 out of 10 users missed it. We also saw some of those who recognised the link didn’t want to click it because they didn’t trust ‘FAQs’. When users were encouraged to click to the help centre, they felt confused and disorientated when they got there, which revalidated what the earlier research audit had informed us. We also saw that users showed preference for economic use of words, especially users with reading difficulties.
The template
In creating the template, we established a user flow logic where the optimal solution is offered to the user on the error screen first. If that fails, they return to the same error screen where they can choose to escalate by clicking the link to the help centre, and if that also fails, then they will be provided a way to contact our support line.
The insights from the usability testing gave us confidence to establish a template draft, with scope to further improve on it with more usability testing. The template followed a sequence where the problem is detailed at the top of the page, the solution is offered in the card within the page and a link to the help centre if there were more recovery options available.
We were also able to establish some principles to guide how the template was to be applied. These were:
1. Give the user advice and action to recover first (Try again, re-enter something, re-do something, do this, try that… etc)
2. Give the user a way to reset themselves second if possible (Go to homepage, go to start of transaction etc)
3. Give the user choice to go to help centre if more options exist, let them know they are leaving to a different area
4. Give the user a way to contact us if the issue is complex
What next
Considering what we know about the state of the help centre, we plan to continue testing iterations of the error/help template with other errors to see how flexible it can be. The team plans to discard content in the help centre which can be fully moved onto the error screen, and to look at how we can improve the information architecture of the help centre.
The hope being that every error becomes a complete focused recovery journey, and should the user end up needing to contact us, we would design their journey so it’s easier for the support admins to know what error they are informing us about.
In summary, we are still working on it, but the result should be that users should feel empowered to problem-solve errors when all is complete.
What did I learn?
In doing this work, I learned:
- How errors can be complex and fun to solve
- How the anatomy of an error screen is set up
- How important information architecture is to everything
- How it’s important to avoid creating a solution for a problem not well understood
