govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Confirmation pages
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:
@timpaul I like the darker colour in both examples. It is AAA compliant for all text sizes, not just larger text which is awesome.
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.
@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.
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."
@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.
@timpaul I really love the dark border, white background version. A massive improvement on the old style and as @stevenaproctor mentioned AAA compliance :).
@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.
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.
@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.
@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.
@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.
@jennifer-hodgson It's a great point, I'll make sure the rest of the Design System team see your comment
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.)
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
@jbuller Thanks for sharing your findings.
I think dependent on a service these links could be the same or different. The example in the Design System itself only contains one link because it doesn't have a visible phase banner.
I've seen a few services where the feedback link goes to a survey, where as the link in the phase banner goes to an email form or links to support channels.
Dropbox Paper audit
On 12 February 2019 the Design System team reviewed a Dropbox Paper document discussing Confirmation pages.
The aim was to reduce the number of places containing guidance and code by:
- migrating relevant, useful content into the Design System itself
- recording important research findings in the community backlog
- removing the original Dropbox Paper page
Below is a record of the outcomes of that review.
If you need to, you can see the original Dropbox Paper content in the internet archive.
Review outcomes
Updates to the Design System
The Design System team will carry out the following updates to ensure that relevant, useful content from the Dropbox Paper file is added to the Design System.
- add a research question about Confirmation page best practice for transactions within a wider service / user task where the emphasis may need to be more on the next steps than completion of the task in question.
Research and examples
The following anecdotal examples have been moved here from the original Dropbox Paper file.
Example 1: MoJ services such as Civil Claims have a digital part followed by paper or payment part (Employment Tribunal) so there's no clear transaction end page. In that case there's probably more a 'digital application completed, here is what you should do next' page.
Example 2:
There was a discussion about when to use confirmation pages on the HMRC Developer Hub (https://developer.service.hmrc.gov.uk/api-documentation).
This service is not a single end-to-end transactional service. Rather, it includes a number of transactions of varying magnitudes like register an account; register a software application (one user can have many); submit that application for checking; add/remove/amend various properties of an application; reset password; request to delete application; request to delete account.
Some of these transactions are “micro transactions” like amending the application name, and the confirmation page seems out of place. Some are bigger transactions like create an application or submit it for checking, in which case the confirmation page seems appropriate.
The team applied the following rule: if there’s no other visual confirmation that the change has happened, use a confirmation page.
For example, for “change application name”, on completion, re-display the “View application details” page and the user can see the updated name.
Whereas for “change password” there’s no visual confirmation of the change, so use a completion page.
Hello all, The guidance on this page says "Your confirmation page must include:" ... "a link to your feedback page".
We have services that don't have a link to feedback. The feedback functions are on the confirmation page in order to raise feedback rates. It's possible the guidance was written without considering that. If so, can the guidance be updated to allow for that?
I came here looking for notes about reference numbers, so thanks for the page on Dropbox Paper above. I didn't want to dive in and edit it but thought I'd flag the insights I got and I put in my first blog post a while ago on essentially the same topic, beta codes https://hodigital.blog.gov.uk/2016/07/08/make-invitations-to-beta-services-better/ for you to integrate if you feel they are worthy.
Should we include a date in the confirmation? It could be useful for users who have completed the service, printed the page and need evidence of when, for example, an application was sent.
Should we include a date in the confirmation? It could be useful for users who have completed the service, printed the page and need evidence of when, for example, an application was sent.
I think that's up to you - if you think it's helpful and doesn't impact negatively otherwise, go for it.
Separately you may want to consider:
- Sending a confirmation email with relevant details
- and telling the user you've done this on the confirmation page
- Setting up specific print styles for this page
- Offering them a pdf confirmation that they can save as a more 'formal' record.
We did this on passports and users seemed happy. We did still see users of mobile devices screenshot the confirmation page as their 'proof'. I don't think we had the date, but the confirmation banner did give their reference number.
On one service we eliminated the feedback link and put the feedback questions directly on the feedback page. The feedback rate jumped from 2.5% (average over 6 months) to 45% (average over 1 month).
Can anyone think of a significant disadvantage to putting feedback questions directly on the confirmation page?
Another nugget: The feedback score was averaging 40% (over 12 months using the link) and jumped to 67% (in the last month when the link was replaced with in-page feedback). The conclusion being drawn is that the link is a barrier to giving a score and dissatisfied users are more likely to apply extra effort to select the link than satisfied users.
Can anyone think of a significant disadvantage to putting feedback questions directly on the confirmation page?
If a service has important information to give on the confirmation page, I think you'd want to avoid anything else. My example would be the passport renewal confirmation page, which I worked on. In that case, we needed to tell the user about their next steps - as they'd done the online portion of the journey, but still had more to do.
Terry, the improved response rate is really impressive, many thanks for sharing!
If a service has important information to give on the confirmation page, I think you'd want to avoid anything else.
That is a good point, especially as some user groups as we know don't read text. How about if in this scenario, rather than providing the feedback survey as a link under a sub-heading 'give feedback', the next green button (which by that stage users are used to clicking and looking out for) said something along the lines of 'Give Feedback' and when the user clicks on it takes the user to the next (feedback) page. I wonder how that would improve the response rate?
I agree with Ed, if the user has to do more the extra content may be a distraction from the user task. In our example, the journey has ended so the user task is simple and we tolerate a busier confirmation page. We'd be happy to hear more comments about this, I enclose an image for reference.
Can anyone think of a significant disadvantage to putting feedback questions directly on the confirmation page?
If a service has important information to give on the confirmation page, I think you'd want to avoid anything else. My example would be the passport renewal confirmation page, which I worked on. In that case, we needed to tell the user about their next steps - as they'd done the online portion of the journey, but still had more to do.
Do you have a screenshot of that page you could share?
Had a support request in person - the pattern mentions sending a confirmation email, but there's no guidance on what that email should contain.
Had a support request in person - the pattern mentions sending a confirmation email, but there's no guidance on what that email should contain.
There's guidance at:
https://www.gov.uk/service-manual/design/sending-emails-and-text-messages#how-to-write-emails-and-text-messages
It says:
