Custom error and fail pages
edwardhorsford opened this issue · 8 comments
Sometimes a service will need to tell the user about an error and will need more space to describe the problem than the typical error summary and error message allows for.
This is typically where the error isn't as simple as validation but because the data provided conflicts with other data already in the system.
Reasons you might want this:
- You want to link to guidance or to another page in the service
- Fixing the error might take more than editing the data in the field - eg the entire section is wrong
- There's a number of choices for how to proceed
In these cases I've typically made what I've called 'bespoke fail pages' - an error page to cover the specific situation.
Sharing here in case it helps anyone else and in the hopes something gets added to the design system at some point.
Example 1
Example 2
Some from Passports from 2015
Example 3
Example 4
Example 5
Example 6 - bespoke radio fail page
Example 7 - user using browser back after paying successfully
Another example is a business matching case where a UTR and name didn’t match and which could present a dead-end for a user if only normal error validation was used.
Trying to show that in various ways on the page (eg “this field doesn’t match the other field” on both inputs or trying to wrap them in a fieldset for a single error) would result in an overly complex or confusing page and would not help users who believed they had the correct information.
Instead the user can be taken to another page where the entered data can be replayed explaining it didn’t match the records. The user would be presented with the option to return to edit the data, or if they belived the data to be correct they could be presented with a way forward - for example calling a helpdesk or using another service to update their information.
Love the 'bespoke fail page' SO MUCH.
Dr Kathryn Summers at the University of Baltimore specialises in design for people with low literacy (which turns out to also be design for people with other sorts of reading difficulties.
She's advocated 'bespoke fail pages' for years, for all errors not just unusual ones - but hasn't used that exact terminology, which I find useful.
The essence of her recommendation is the same as yours:
- error or errors happen on page A
- user receives a fresh page, B, that tells them about the problem and what do to
- the conversation continues from there.
Having errors that appear within the same page can be highly confusing for someone who doesn't read well. Less so for our typical government pages now, where many services are trying hard to keep to one thing per page - but even that can be problematic for all the good reasons you explain.
Thanks for creating the examples and a term for them.
@edwardhorsford thanks for sharing these examples. We have a similar case to the renew your passport 'already submitted application' example. I was wondering what URL you used for this? And did it show when a user tried to return the confirmation page or just if they tried to return to screens within the application flow?
The apply journey I'm working on requires users to sign in to the service and if they are logged in but have already completed the application they won't be able to return to those pages. So a similar page to this would work well, either when using the back button or when returning and trying to access the apply URLs. But we are planning to show the confirmation message if they return, after sign in (later to become an account area, hence the sign in).
@dalcJ I'm afraid I don't recall. I suspect it likely if they visited a random page within the service we would have redirected to the start page. But if visiting any of confirmation pages, we'd show the above if we thought they had evidence of an existing (but expired) session.
Answering this has reminded me! I wrote a blog about this very thing as I thought it was interesting that users were bookmarking confirmation pages.
@edwardhorsford thanks for your reply, this is useful. We'll do some testing on how we're setting this up and I'll post any findings back here. Current thinking of what we're going to try, as we've got sign in, is:
- show the start page if the user is not signed in and they try to view a page in the service
- show the confirmation page if the user is signed in and they try to view a page in the service (on next iteration this will show the account home page)
- show an 'already submitted application' page if the user has just completed the application and uses the browser back button, so that they are shown a different page.
@dalcJ I think you've got a fourth case to cover: a user visiting the confirmation page who isn't signed in - eg they've bookmarked it (as per my blog post) and are now returning.
We will be implementing something similar - if we have evidence that the user has submitted an application (finished the task in our service), including if their session has timed out we will show this:
Something already implemented in one of our services, where the user has to apply and confirm their identity a different way to the one they tried (there are a few different reasons this is the case):
Applying a different way:
We have more but thought I'd share just a couple of examples!