Confirmation pages

[govuk-design-system]

Use this issue to discuss this pattern in the GOV.UK Design System.

[timpaul]

Just capturing a conversation from yesterday. A proposed colour palette change would make the green panel on this page much darker, like this:

This may or may not be an issue. But @36degrees had a really good suggestion - why don't we use the green 'Alert' component from GOV.UK Marketplace? We're considering adopting this component for the design system anyway, and it's very close in intent to what the panel on this page is trying to achieve anyway.

So, it would look something like this:

[ghost]

@timpaul I like the darker colour in both examples. It is AAA compliant for all text sizes, not just larger text which is awesome.

[joelanman]

Is the dark green the same as our buttons? I'd be worried about using button style on things that aren't buttons, without doing user research. Obviously the outline approach doesn't have that problem, but I'd still be worried about making a large change to an important element without research.

[ghost]

@joelanman Excellent point. People could mistake them for buttons because of the similarity. It would be interesting to research with people who regularly use services with the current pattern to see if the new one meets the user need more, less or the same.

[ignaciaorellana]

Home Office has made a variation of confirmation pages https://home-office-digital-patterns.herokuapp.com/components/confirm-pages according to this, "lighter green which does not meet accessibility requirements for some smaller text."

[ghost]

@ignaciaorellana The lighter green does not meet colour contrast rules. Elements says "When using the white text on a turquoise background – ensure the minimum text size is 24px normal weight, or 19px bold. This is to meet colour contrast ratio requirements."

The Home Office colour is the green hover colour from the colour palette and is AAA compliant for any text size.

[trevorsaint]

@timpaul I really love the dark border, white background version. A massive improvement on the old style and as @stevenaproctor mentioned AAA compliance :).

[trevorsaint]

@timpaul we will require a confirmation pattern similar to this. Whereby a Judge, for example, would perform a specific case action 'make a decision'. Successfully completing a task on a case by case basis.

[jeanesims]

My comment is about the use of the heading ‘What happens next?’ and the guidance underneath it on the ‘example’ used on this page https://www.gov.uk/service-manual/design/confirmation-pages.

We’ve had feedback from an accessibility review that ‘What happens next?’ should be changed to ‘What you must do’. Typically, the next steps can be a mixture of what ‘we’ might do next and/or what ‘the user’ will need to do next.

We’ve been using the heading ‘What happens next?’ on confirmation pages. We haven’t seen users having problems with it in testing, however, if it’s not accessible we’ll need to change it.

Can the ‘example’ also be reviewed and updated? We’ve been using it as a guide.

Also do we need to have some spaces in the 'reference' numbers - like we do with telephone numbers? Sometimes they can be quite long and are harder to read when they don't have any spaces.

[joelanman]

@jeanesims Hi! Apologies, the screenshot on that page is wrong. Our recommendation is to use the statement: "What happens next", as we're not asking the user, we're telling them. You're right that 'What you must do' doesn't suit all situations.

We have some draft guidance for reference numbers here:

https://paper.dropbox.com/doc/Transaction-reference-numbers-rutTu74goUwXfKxG9NBcr

The main thing is to try to generate short, easy to remember reference numbers.

[ghost]

@joelanman @jeanesims I think 'What happens next' as a statement only works when the stuff that happens next is stuff we will definitely do for a user. If it is something they do or we might do then it does not make sense. 'What you [can, need, must] do next' is for stuff them.

If there are things we do and things they do, I would have 2 headings to give the content more structure and meaning.

[jennifer-hodgson]

@stevenaproctor and I had an interesting chat about this which I am recording below:

Does the discussion above raise a broader issue around content in examples, and making clear where content is a content pattern and where it is not? In the HMRC design system we've tried to do this by detailing any content the pattern should include.

Also, I suggest there are instances where "What happens next" is being used in order to adhere to what is perceived as a content pattern, when something like "What you need to do next" would be clearer. The distinction feels like a significant one to me.

[joelanman]

@jennifer-hodgson It's a great point, I'll make sure the rest of the Design System team see your comment

[mschwendener]

Hi

NickColley directed me here (from twitter).

As an external user, I strongly suggest that you use the darker green, to tie it together with the other steps (for example subscribing to updates for a page).

The way it looks now I got the feeling the colour of the confirmation notice was a forgotten leftover from an older design.

(Once it's changed, update http://govuk-elements.herokuapp.com/colour/#colour-sass-variables.)

[jbuller]

I've just accessibility tested a confirmation page and had a warning that the Feedback link and 'What did you think of this service?' are duplicates - same target different link text.
Not a huge problem since the link text is good in both cases but worth thinking about, from both the users and future testers perspectives.
See https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=324#qr-consistent-behavior-consistent-functionality

[terrysimpson99]

The example says "We have sent you a confirmation email.". It says nothing about confirmation email in the guidance. I propose the guidance and example are both updated with something like "We have sent you a confirmation email to bob@email.com" (note absence of trailing full stop to avoid confusion with the email text). We do this routinely.

[cristina-agramunt]

At the AfN we have used an alternative format for the confirmation page.

The first version of the service used the design’s system confirmation page with the green panel and the reference number. Below, we gave the user step by step instructions of what to do next - which was to post a copy of their documents.

After understanding that a number of applications where not being processed in the system due to users not sending their documentation for ID verification, we decided to review the confirmation page. We also understood that users believed that the reference number was their National Insurance Number and for this reason they missed the extra steps.

With that, we reviewed the architecture of the page and deprioritised the reference number. We also reviewed the content to make it easier to for the user to understand the next steps once the applications was submitted.

This was the format the best performed:

With this version online, we observed a much higher level of documents being received and successful applications being completed by the service.

Now, with the introduction of Document Upload to the service, we are once more reviewing the confirmation page. We are bringing back the green banner, with a reviewed content version where we try to ensure the user understand that the number displayed is only a reference number and not their actual National Insurance number.

[julianalders]

The MVP
At DBS we've been exploring an alternative to the confirm page, which I'd like to get others thoughts on and insights if similar situations have been experienced.

The DBS service we've been designing enables users to submit information to the DBS. When this information is received, a 'case' is automatically created by the system. However, before a caseworker can process the case, the user also needs to send in documentary evidence (by post/ email/ etc) which supports what they have input digitally.

This is the MVP state.

For the next phase release, we have designed and built a file upload function which will enable the user to submit the documentary evidence at the same time as the other information, thereby allowing the caseworker to start processing the case immediately.

The issue
So, for this MVP state (where the user needs to submit information digitally through the service, and separately send evidence by post/email etc) we found that when we used the green banner users thought they were done, finished with their submission, and tended not to read the further instructions telling them what they needed to send to DBS in support of their submission.

An alternative
We explored using from the GDS palette the orange, to prompt users that there was still something else for them to do. We also explored removing colour at together but felt that deviated to far from the confirmation pattern.

We also strengthened the 'What you need to do next' and brought that as high up the screen as possible.

Testing
Early tests proved promising which participants indicating that because it wasn't the usual green (these users tend to be familiar with Gov.uk) that made them take notice, and subsequently understand that they had to do something more before their actions were fully complete.

Any thoughts?
Has anyone come across similar situations?
We are aware that re accessibility we should not rely upon colour only to relay meaning - so are attempting to augment the colour with the messaging on the screen.

Any other thoughts, experiences or suggestions, or indeed, whether you feel this is a sensible alternative to the green, with the support of appropriate content to ensure the user is made aware that they need to do more than what they've just completed.

[joelanman]

@julianalders In my experience, if the user needs to do something, it's best to not use a Confirmation page. Otherwise there is a high risk they think they're done (the intention of the Confirmation page pattern) and don't understand they still need to do something to complete the service.

I would suggest instead having the H1 here be something that conveys what the user needs to do, something like

Send your documents in support of your referral

You can cover the other details here too, like the reference number, but if the document sending is necessary, I would emphasise that first.

[julianalders]

@joelanman Thanks for the input, I'll certainly be exploring that as we learn more and refine this experience.

Specifically about the use of orange in the banner, is this something you've come across before? ie using a different colour from the green (I notice a red one being used further up this page), and whether this sort of adjustment is acceptable within GDS standards?

[joelanman]

@julianalders general rule of thumb is, try the published patterns first, and if they don't work well for your users (or we don't have a published pattern for the context), feel free to try something else. Try to keep it simple and consistent with published patterns, has to be accessible obviously.

[julianalders]

@joelanman We'll continue testing and iterating this part of the journey. As I mentioned at the start of the thread, this is a temporary state as when document/file upload going online we can revert to the standard Confirmation pattern. Appreciate your time on this.

[LauraLian]

@julianalders Hello! I'm really interested in how your orange banner tested. I'm working on a design for a 'payment pending' screen for an edge-case scenario where applicants may have to wait up to 24 hours before their payment is processed and they can complete the application journey. For most users, payment processing will be instantaneous.

We already have screens for 'Payment successful' as per GDS standards, with the green banner and ref number. However, we have considered an alternative colour, to distinguish between this pending state and the successful state.

Any insights would be most welcome. Thanks.

[CharlotteDowns]

Interesting notes from a post shared about the confirmation pages pattern on Linkedin

The user suggested the following improvements to confirmation patterns:

Explain reference numbers

Tell people:

• what the reference number is
• why they need it
• if they should keep it (if they don't need to keep the number don't show it)

Do not use a reference number as confirmation alone.
Do not show internal reference numbers to people if it means nothing to them.
Do not make up a reference number. Someone might try to use it.
Do not expect people to remember reference numbers.

Example 1 shows a 39-digit reference number made up of numbers, letters, and dashes. This reference number is from a bowling alley, of all places.

Example 2 shows a government webpage explaining when someone might need to use a reference number. It's an example and not a real government service.

[julianalders]

@LauraLian I've rolled of the project now, but I didn't hear any bad reports about the use of orange for the time that it was in place. I'd mentioned that the use of orange was temporary, until a file upload capability was added. This is now complete and so the confirmation screen is now showing the usual green. But again, I believe it did it's job for the time it was in place.

[lalexander12]

interested to know - does it work having 2 things confirmed in the green box at the top?

[querkmachine]

@lalexander12 My 2p, the confirmation box should not contain the 'payment request sent' part, as that part of the process hasn't been completed; and It could be confused for the user having sent the payment request to LAA, rather than LLA sending a payment request being sent to the user.

(Honestly, the wording in the section below also confuses me as to which way around this is. The first sentence sounds like the user was who sent it, but then the user is prompted to complete it, so are they actually the recipient?)

You may not want to use the panel component here at all, as the user appears to not be at the end of the user journey. A success notification might be more fitting here.

[adyhoran-ops]

If the 'What did you think of this service?' link goes to a different website domain, should that domain be mentioned in the visually hidden text of the link?

My team is building a service on a publishing.service.gov.uk domain - but the feedback page links to a page on gov.uk. We don't mention GOV.UK anywhere in the feedback link text, and I'm worried this is a WCAG 2.2 non-compliance.

[joelanman]

@adyhoran-ops are you concerned about any wcag guideline in particular? I'm not aware that this is an issue myself, linking to another domain without mentioning it. We do mention if the link opens in a new tab as that can be disorienting

[adyhoran-ops]

Thanks @joelanman - it's been a while since I looked at wcag, but I was worried that by not saying we're taking users to another domain - that this was a non-compliance.

From your answer and @selfthinker's in Slack, it's a usability point rather than an accessibility compliance one 🙂