Error message

[davidhunter08]

Use this issue to discuss the error message in the NHS digital service manual

[7homwon6]

I appreciate the sentiment behind this.

[sarawilcox]

It would help to explain to content designers why we shouldn't include a full stop in an error message. That's GDS practice and here's the explanation (via Amy Hupe): "We discussed this a lot. We didn't want to include full stops on the end of error messages that end in examples (for instance, if your error message says "Enter a valid post code like SW1 2AA.") as we thought it could confuse users about the format." "The same was true for hints and we wanted them to be the same if they appeared next to each other. We also wanted to minimise unnecessary characters where necessary. So we decided to use no full stops by default as consistently as possible." "Needless to say, this approach isn’t perfect. For example, if you have a 2 sentence hint, it’s tricky should you include a stop on the end of the second sentence or not? Or if the hint or error contains a question mark, what then? Etc."

[sarawilcox]

Another comment: Out of interest—did you find this had any #Accessibility implications?

With many of the common #ScreenReaders using punctuation for pauses, did removing them cause any issue with the Screen Reader running into the next sections?

[sarawilcox]

We're seeing users react badly to date of birth and postcode error messages that ask them to fill in a "real" date of birth or postcode as in this GDS page: https://design-system.service.gov.uk/patterns/addresses/.

People seem to prefer something like:

• Enter a date of birth like this: 15 3 84
• Enter a postcode like AA1 1AA (there is an example here: https://design-system.service.gov.uk/components/error-summary/)

[GrilloPress]

For NDOP we hated the word "real" so we went with:

Check that you've entered your postcode correctly

Our H1 was already Enter... So we didn't use enter

[GrilloPress]

Not ideal but strongly suggest staying away from "real"

[henocookie]

Error messages in the NHS coronavirus status checker

How the NHS coronavirus status checker service uses the error message guidance:

Focus on telling users how to fix the problem rather than describing what's gone wrong

Words like "select" and "Tell us" frontloaded error messages to ensure users knew what action to take next.

How are you feeling now?

Select all the options that are relevant to you or select "None of these"

This error message was used as the question contains a list of checkbox options, including "none of these".

A user can select as many items as they want (excluding "none of these") or just select "none of these".

When did you start feeling like this?

Select an approximate time

This error message was used as user research revealed that some users may not remember exactly when they started feeling in a particular way, especially when they feel very unwell. The use of approximate allows users to be comfortable they can estimate an answer and it doesn't need to be 100% accurate.

Do you have any of these health problems?

Tell us which of these health problems you have or select "No - I do not have any of these health problems" if you do not have any

This error message was used as the question contains a list of checkbox options for health problems, including "No - I do not have any of these health problems".

A user can select as many items as they want (excluding "No - I do not have any of these health problems") or just select "No - I do not have any of these health problems".

[sarawilcox]

I'm collecting examples of error messages we use in NHS services, ones based on GDS guidance and ones we've developed ourselves. If you have some good, tested error messages - or examples of error messages you think do not work, please let me know. I'll share what I've collected once I've organised them.

[sarawilcox]

Note also these comments noted by @JackMatthams, copied over from this ticket: https://github.com/nhsuk/nhsuk-service-manual-backlog/issues/180, which I'm now closing.

Error messages in radios and checkboxes

What

We currently follow GOV.UK guidance on how to phrase error messages on both radios and checkboxes. Our revised guidance uses these examples:

• "Select yes if you have changed your name" for radios
• "Select if you have 1 of these conditions" for checkboxes

Why

We have concerns that the example radio error message is leading, and the example checkbox message is unclear as to how many boxes people should select, and what they should do if they apply to a 'none' or 'other' box. They both go against other current guidance.

Suggested improvements for checkbox error messages include:

• "Select all of the conditions you have, or select none"
• "Select the conditions you have, or select none"

Suggested improvements for radio error messages include:

• "You need to tell us if you have changed your name"
• "Tell us if you have or have not changed your name"
• "Select an option to tell us if you have changed your name, or not"
• "Select if you have or have not changed your name"

Anything else

We are contacting GOV to ask about their reasoning behind phrasing the radio and checkbox error messages like this. We are also conducting research into this. We plan to bring this to a future content style council.

GOV.UK's guidance on radio error messages: https://design-system.service.gov.uk/components/radios/#error-messages

GOV.UK's guidance on checkbox error messages:

https://design-system.service.gov.uk/components/checkboxes/

Our current guidance on radio error messages can be seen here: https://beta.nhs.uk/service-manual/styles-components-patterns/radios

Our current guidance on checkbox error messages can be seen here: https://beta.nhs.uk/service-manual/styles-components-patterns/checkboxes

[colouringinteam]

Would be very useful if the online guidance gave an example of the use of the error summary in relation to a login screen.

In that situation you might legitimately wish to have an error summary stating that the sign in info was incorrect, without actually showing which (the username or password) was the incorrect element.

It would also be good to have a definitively stated position on whether that error summary should come before the overall title (i.e. "Please sign in") or after it. Before seems to make sense from an accessibility POV, but having that explicitly declared might be worthwhile.

[davidhunter08]

Thank you @colouringinteam

For the:

In that situation you might legitimately wish to have an error summary stating that the sign in info was incorrect, without actually showing which (the username or password) was the incorrect element.

Have you tested a solution with users? It'd be really useful to know how it tested to help us form the guidance.

And for the placement of the error summary, we say it should go above the page heading <h1>

Put the error summary at the top of the main container. If your page includes breadcrumbs or a back link, place it below these, but above the <h1>.

https://service-manual.nhs.uk/design-system/components/error-summary#where-to-put-the-error-summary

[colouringinteam]

Regarding the above, it's more something you'd do for security reasons rather than to address an immediate user need (though you might argue that not having your account hacked is a legitimate user need!)

That is, if you explicitly state that the password is wrong then you've effectively confirmed to a would-be intruder that the username is a valid one, and so they should concentrate their attack on the password field. You've also effectively given away some user information in the sense that you've confirmed that a specific username or email is signed up to your service.

This approach undoubtedly makes correcting the error less easy for the user, but in this instance I would say that the need for account security is probably more important.

Interestingly I note that the Government Gateway sign in already operates a variation of this approach, and does not disclose which element (Gateway ID or password) is incorrect.

[davidhunter08]

Examples from the Government Gateway sign in page:

https://www.access.service.gov.uk/login/signin/creds

If left blank:

If password not long enough:

If user ID OR password are wrong:

[colouringinteam]

FYI, that last one should read "If user ID OR password are wrong"

[davidhunter08]

@colouringinteam for your example, I suggest:

• link to each of the answers that have validation errors
• show the same error messages next to the inputs with errors

[Tosin-Balogun]

System error developed at NHS login

We developed a series of error screens to help user recover from system related errors

We tested the middle pattern with 10 users

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.

Needs further testing

We were able to build guidance on how to apply the pattern based on the usability feedback but more testing is required in order to refine it

You can read more here https://megaspiderweb.medium.com/helping-users-recover-from-an-error-144a0d8b9500

[sarawilcox]

We've had a query about how to handle the red stripe when the question includes a details component.

There's an example on the national data opt-out service.

The red line connects the question, error message and input.