Confirmation pages #40
Comments
|
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. |
|
@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 auditOn 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:
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 outcomesUpdates to the Design SystemThe 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.
Research and examplesThe following anecdotal examples have been moved here from the original Dropbox Paper file. Example 1: 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. |
|
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:
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. |
|
Exactly. And also, in many cases 'you don't even need this thing' (which was @f-marry's specific use case) definitely is 'success' from the user's point of view - so that's exactly why I think a confirmation page could be appropriate. |
|
sorry yes I'd missed the nuance of 'you don't need X' vs 'You're not eligible for X'. Interesting one |
|
I thought we agreed really :) |
|
Whilst we’re talking confirmation pages... does anyone have any experience on thoughts on including a reference number? The current example includes one, and the guidance says:
However I’m not sure this is always helpful. Displaying a reference number might help to communicate the "complete" status, but it could also introduce some anxiety, with users feeling like they need to save this somehow (eg a scrap of paper or by screenshotting or printing it out). And then later if they do need to query their application, they may remember that there was a number and spend ages trying to remember where they put it. Ideally I think we can avoid all this by not exposing users to reference numbers at all, and instead making sure that support staff can look up applications using the user’s name or email or phone number or other personal information they're unlikely to forget. In the service I’m working on, Apply for teacher training, we were using the confirmation page with a reference number on it (also sent by email), but found that very few users (if any) quoted this when contacting support, who most often relied on email address. I have removed all references to the application number, and we have not found any negative consequences so far. |
|
That's an interesting point. I was doing a bit of discovery work with caseworkers. We had mocked up a confirmation page with something like "We will use this reference number if we contact you" but when we checked we found it was not true. That number isn't sent to the caseworker system. It could be sent but there appeared to be no reason to do so. |
|
Hi all, on the HEC project for taxi drivers to require a tax code check to renew their license we have used the gov design system confirmation page on our licensing body journey and have adapted it. The reason for adapting the pattern came from a user need and accessibility, as many licensing officers fed back that they wanted something that was unambiguous and that a big cross or tick would make it very clear what to do next and don't have to contact HMRC, Also from an accessibility perspective it was clear that using the Red (#B10D1E) in GDS would be the logical choice because of its strong AAA pass, as long as it wasn't combined with green, this can create create problems with colour blind users because of a similar hue. Additionally because the text is a H1 it is very noticeable to screen readers and the use of the tick/cross icons results in colour blind users are not having to make a decision on colour alone. They both tested very well. For the valid tax code page users thought the green box and tick icon were very clear and provided no confusion. They also thought the time stamp was very useful as a reference and they could easily save the data to there system via through a pdf. Through some cross government sessions we found that the home office and DVLA pattern already uses the green tick and that the code format should be as short as possible which we integrated. For the the expired code page, users thought the red and cross used was very clear in indicating there was a problem and they needed to ask the applicant for a new valid code. Dan |
|
The DVLA have done something similar on their tax check service for a number of years now. |
|
hi @MalcolmVonMoJ thankyou, sorry I've edited to include that we did use the DVLA pattern as reference |
|
We're developing a GDS-compliant site and have an application form (or more specifically a change request to their original application) that's created as a draft due to it's length so they can come back to it later. They can continue through to submission where they get a confirmation as laid out here, or there's a "Cancel all changes" option which discards the form. At the moment we have no warning, as I believe GDS states "Are you sure?" confirmations should be avoided, however users will inevitably accidentally delete their form by accident. Does anyone have any suggestions as to how we can ensure this doesn't happen while following GDS practices? |
|
@XChrispy Take them through to a Check your answers page first? “Here’s what you’ll be deleting…” kinda thing. |
|
I don't think GDS has ever advised against adding a warning message for a potentially destructive action - it seems very sensible to me. You might want to consider showing the message as a modal: #30 BTW - there's the Service Standard (previously looked after by GDS, now CDDO) and the GOV.UK Design System. But there's no mandatory requirements setting out how web interfaces should work in all circumstances (legal privacy, accessibility and security requirements aside). If your users need a warning message, there's nothing to stop you adding one. |
|
@philsherry We have a check your answers page for submitting the form, but my instinct says I'm not sure it would be expected behaviour for when you're discarding the form for our particular service, as it's a change request to the original application you're discarding and it might look like you're deleting the original application. @StephenGill I've just seen this warning button which states "When letting users carry out an action like this, it’s a good idea to include an additional step which asks them to confirm it." I think this would work better than a modal, which going by the comments isn't recommended in most cases. I will feed this back to my colleagues, thank you. |
|
@XChrispy on my service for destructive actions we have a confirmation page to check. GDS would generally advise you avoid modals where you can, but you can still have a page confirming actions. Screenshot of our delete confirm page: |
|
@edwardhorsford Thanks for sharing, I think that's just what we're looking for. I'll share that with our UX team. |
|
The HMRC add-to-list pattern has the equivalent of 'Are you sure?' as a page. It's functionally the same as Ed's example but implemented with 'Yes' and 'No' radios. See: https://design.tax.service.gov.uk/hmrc-design-patterns/add-to-a-list/ |
|
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 [email protected]" (note absence of trailing full stop to avoid confusion with the email text). We do this routinely. |
|
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.
|
christopherthomasdesign
moved this to Published
in GOV.UK Design System: Discuss styles, components and patterns
|
The MVP 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 An alternative We also strengthened the 'What you need to do next' and brought that as high up the screen as possible.
Testing Any thoughts? 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. |
|
@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. |
|
@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? |
|
@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. |
|
@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. |
|
@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. |
Interesting notes from a post shared about the confirmation pages pattern on LinkedinThe user suggested the following improvements to confirmation patterns:
|
|
@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. |
and others
Use this issue to discuss this pattern in the GOV.UK Design System.
The text was updated successfully, but these errors were encountered: