Making error messages more consistent
We have error messages to help users if they make a mistake.
The GOV.UK design system has standard components that we should use for error messages and error summaries.
There is a problem
An error summary summarises all the errors that need fixing on the page. This links to each error message which shows the user where the error is and tells them how to fix it.
Why inconsistency is a problem we should spend time on
Consistent design and language make things predictable. When things feel simple or familiar, people don’t have to think too hard about how to complete a task. Users feel like they know how to use the system and are confident when completing tasks because it feels easy.
While we haven’t received user complaints specifically about inconsistent error messages, we felt it was important to address to make sure meet accessibility needs. It’s also important to us to improve the system alongside designing and building new features.
Inconsistent components
In some cases, we were missing either a whole component (having an error summary but no error message) or parts of the component.
This may have been because of team changes and less familiarity with the GOV.UK design system.
The GOV.UK design system’s components are designed and tested for accessibility, so missing components or part of one could introduce the risk of not meeting users’ accessibility needs.
In this example where users are expected to record the start date and end date of a School Resource Management Adviser (SRMA) visit, they only saw the error summary. There was no error message.
If a user had accessibility needs that meant they needed to zoom in on sections of the system to read it, the error summary would be out of sight once they scrolled down.
This could make it harder for the user to tell which date needed correcting unless they remembered which date was specified in the error summary.
While the error summary in this example does specify the start date, accessible design doesn’t expect people to remember information. It was a good reminder that not all users can see everything on the page at the same time.
Inconsistent language
Ideally, error messages should “let the user know what went wrong and how to fix it”.
Depending on the page users were looking at on the system, there were also different error messages for the same error type.
When users did something like add a date that didn’t make sense, such as 13 in the month field, they would see different error messages depending on the page they were on.
“Start date -- is an invalid date”
“Date decision made: 1-13-2023 is an invalid date”
The GOV.UK design system error message guidance also advises against using words like valid and invalid because they don’t clearly explain why the information is invalid or how to fix it. It puts the mental load back on the user to work out why something is not valid and assumes the user can work this out.
We also had different language when someone missed a field in a date.
“Please enter a complete date (DD MM YYYY)”
'Enter a complete date’ doesn’t make sense out of context because users could get confused about which field it related to if there was more than one date. The error message guidance also advises against using ‘please’ as it implies the user has a choice when it’s the only possible way to resolve the issue.
When we chose to give the user an example of “DD MM YYYY”, we assumed that this would make sense to users. The format ‘DD’ and ‘MM’ could suggest that users must enter ‘01’ for the day or month when the system accepts ‘1’ for both fields.
How we made error messages and error summaries more consistent
Where we had missing components or component parts, we added the error message and linked to it from the error summary. This means the user can select the error summary link and be taken to the corresponding error message and field they need to correct.
We also kept the information the user was adding instead of deleting it once an error message was triggered.
Instead of a vague “Enter a valid date”, the error message now says “Date trust was contacted must be a date that exists. For example, 17 5 2022”.
While making the error messages and error summaries consistent, our developers also used common components so any changes to a case action’s error message would update all the case action error messages at the same time.
We also reviewed the accessibility of our error messages and add ARIA labels to error messages and fields where needed.
Next steps
We now have a backlog of tickets to continue standardising our error summaries and error messages.
As we continue testing concepts with users, we’ll include scenarios that include users triggering an error message to check the language makes sense and helps the user overcome the issue.
We’ve worked with the other content designers in our programme team to agree on wording that can be used across our digital products. The content designers also pointed out that the example date is usually shown in the hint text.
As the GOV.UK design system guidance is to only show examples once, we’ll leave the examples in the error messages for now and will consider moving the examples to hint text in the future.
