Download, save, print or share a confirmation, receipt, certificate, or letter at the end of a service

[samuelholyhead]

What

A consistent pattern to fulfil the need for a user to download, save or print either a confirmation of a transaction, receipt or a certificate of completion (most commonly at the end of a service).

Why

After working for HMRC in live services and at the Home Office in build services, I have seen multiple services that have a user need to download, save or print a confirmation or receipt or certificate of completion, usually in the form of a generated PDF.

Nearly every one of these services takes a different approach and when faced with a similar problem previously as a designer on a build team, we ended up developing yet another approach due to the lack of guidance of a suggested pattern. In addition, technically lots of these services take a lot of different approaches to generating the receipt or certificate with a range of libraries used.

There could be an argument that these are somewhat different use cases so we shouldn’t conflate the pattern for them but generally it feels like all of the existing designs have a combination of letting users save/download, print or open an A4 document, usually a generated PDF. A pattern to provide guidance could help align build teams rather than letting them re-invent the wheel every time.

Related patterns and components:

• Check answers #36
• Confirmation pages #40
• Panel #55
• Share links on social media #119

Examples in existing services

[HMRC] Employment Related Securities (ERS) returns – Confirmation receipt (Live)

When the user follows the link on the page a PDF is generated PDF and opened in the browser. In older browsers that don’t support showing PDFs such as IE it just downloads.

Apparently during research, users were requesting a receipt that they could download for their records. The use case being accountants who have to keep records on their internal company systems. Print was considered but not so relevant for companies with digital record keeping where they would have to save a PDF through the print dialogue.

Unsure who the build designer was. Now being looked after by HMRC Edinburgh Live Services. Contacts are: abdirahman.mohammed@digital.hmrc.gov.uk, helen.sell@digital.hmrc.gov.uk, samuel.holyhead@digital.hmrc.gov.uk

[HMRC] Advanced Tariff Rulings (ATaR) – Save or print confirmation and other letters (Live)

Embedded in the page. Custom CSS removes the UI when printed. PDF generated when user clicks on the save button. Screenshot from the prototype for ease.

Unsure who the build designer was. Now being looked after by HMRC Edinburgh Live Services. Contacts are: abdirahman.mohammed@digital.hmrc.gov.uk, helen.sell@digital.hmrc.gov.uk, samuel.holyhead@digital.hmrc.gov.uk

[HMRC] Trusts – Confirmation receipt (Going from Live Beta into Live)

This service is just going out of beta into live and has had several sprints of research and development on the pattern. It contains a generated PDF that is downloaded to the users machine if they select they want to download. The user goes through a set of two questions pages and the file is downloaded if they choose the correct radio options.

During the handover we found out that previous designs included opening the receipt in the browser but research showed that users then closed the window which lost the token for their session as this occurs mid-flow. Apparently there is a 4 second wait when the user clicks continue to avoid overloading the PDF generator with requests. This hasn’t been an issue during testing according to the build team.

UX designer on the project build: benjamin.ingignieri@digital.hmrc.gov.uk

[Home Office] Prevent eLearning service – Certificate of completion (Closed Beta)

This service features a certificate of completion at the end of the lesson. This is to prove to managers and employers that they have completed the training.

A generated PDF that is opened in the browser via link which follows the Publishing download attachment pattern. Previous research included trying a HTML version but users struggled to save that version. PDF is opened in the browser due to security concerns about putting the users details into the front-end. User research suggests that users would expect to save this to their computer as the default behaviour. Additionally, it was found that if a green confirmation panel was used in the in the flow before this page then users would tend to close the window before reading that they can download the certificate.

UX designer on the project build: samuel.holyhead@digital.hmrc.gov.uk

[Home Office] Check someone’s immigration status (Live)

Save or print an application. This example was shared with us by Frank Ramsey and Chris O’leary at the Home Office.

Contact: frank.ramsay@digital.homeoffice.gov.uk, Chris.O'Leary@digital.homeoffice.gov.uk

Does this already exist in the design system?

In regards to existing elements in the GOV.UK design system (or other department’s design systems), while there are components suggested for saving, downloading or printing an item, I feel like this is a different problem that usually takes the form of a flow or combination of existing components.

Other thoughts on a potential pattern

Some initial thoughts about what format a pattern could take:

• there seems to be a common theme that out of the actions, most users want to download a copy
• seems like HTML consistently isn’t a good file format to download as most users want to store a file locally or share a file via email, etc. From research, users struggle to save a PDF via print dialogs, etc.
• from research, linguistically most users refer to this as action as wanting to save the file
• related – print buttons usually require javascript. It would be good to explore alternatives that fit with progressive enhancement. Embedding the content in the page and using custom CSS to remove the UI seems like a nice approach that supports the use of the print function in the browser rather than a javascript button.
• sometimes download implementations open up a new blank windows in order to download the file. It would be good to explore how to avoid this.
• just personal preference but the outline of the document in the ATaR example help signify which parts of the page will be printed or saved while also previewing the document. consideration would need to be given on how to signify this to users of screen readers and other assistive technology though.
• in regards to generation libraries:
  • HMRC have a PDF generation service that they are deprecating.
  • some other services use pdfbox: https://pdfbox.apache.org
  • this is an example of how to generate an accessible PDF using pdfBox: https://github.com/martinlovell/accessible-pdfbox-example

[terrysimpson99]

I agree it would be good to debate this issue. I was persuaded by https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should-be-published-in-html-and-not-pdf/ to migrate services away from pdf to html. We found it was worth thinking about why people want to print/download to ensure it's not the only way of meeting the user need.

• "User wants to share exact details of what is on government database". For example, at https://www.gov.uk/check-register-rents the 'why' revealed that users wanted to refer other people to property details. We enhanced a legacy design to allow users to share the URL of property details held on the database. Thus print/download is no longer the only way of sharing details. We kept the print/download feature but changed it from pdf to html. This worked for this service because the data is public domain.
• "User wants evidence that they have interacted with the service". We send an email acknowledgement in many of our services and users consistently say that they like to have it. They expect it to include all the details of their submission but even when told it doesn't, they report it's still worth having as evidence that they have interacted with the service at a particular time.
• "User wants another party to authorise the submission". We have one service, where the non-digital journey involves hmrc staff interacting with the service on behalf of a user on the phone. The staff member then prints the details and posts it to the user for a wet signature and returns it. There are several points of failure which make it inefficient and in many cases, a wet signature isn't necessary.

Some users report taking a screenshot using the same device or another device (such as by using their phone to take a photo).

Some services provide print/download on the 'Check answers' page and also on the confirmation page. Some users use both but say they discard or ignore the one they've downloaded from on 'Check answers'. Their explanation is that they can't be certain it will be available on the confirmation page. For that group of users, print/download on 'Check answers' can be eliminated.

Some users fail to get past a 'Check answers' that has a print/download function and later claim that they've completed the service. I've worked on more than one service where a working hypothesis is that the print/download journey is directly responsible for users failing to submit yet believing they have submitted. Designers often say it's best not to take users away from the pathway that leads directly towards submit.

[cjforms]

Colleagues working on one of the farming grants services reported that they removed a 'print before submit' option for exactly the same reason as @terrysimpson99 mentioned: it was creating what I call a 'false end' where users would believe they had finished the process when they were offered a chance to print, but had not yet in fact pressed 'submit'.

There is definitely a user need to be able to print a record of the transaction after submit. I have seen this repeatedly in user research across a wide range of services.

In particular, it's definitely distressing that the 'tell us once' service (notify government after a bereavement) does not currently offer this option - or appears not to do so.

[connorthompsoncode]

I just wanted to add to this discussion one of the examples we have of this pattern alongside some user research we've received on it.

I work in Interactive Guidance within CS&TD - TAD. We have a product where users are asked a series of questions, some where they enter information, some they choose an option etc. Based on their answers they are given an outcome screen that gives them all the necessary details they need to send to an employer before they start a new job.

As part of this outcome screen, users need to send these details to an employer.
We offer a couple of solutions to accommodate this:
• Email option - using a :mailto link this opens an email in their default email client already containing the form information
• Printing, signing and posting - this opens a browser dialog to let them print the page
• The content they've filled out is shown on the page if they wish to copy it or download/screenshot the page

This was the design we had for presenting the email and download options (this is just the top of the page, there form content is also shown further down):

We wanted the links to be inline with the rest of the content. This way we could add extra instructions/information to each option. We did test using buttons but those didn't fit in well inline with the other content.

This design was part of a usability test done on the product as a whole, here are some comments from users regarding this specific section:
• Email preferred by all users over print option - one user thought this meant a ‘Docusign’ type process, one user might struggle to set up ‘the app’, clear what to do when email was opened
• Email link in this version did not explain process however user would have been tempted to use ‘Print’ option to create a PDF version of print file and then email this to their employer
• Would have to set-up email app ‘but is inconvenient’, better if just added employer email address and sent automatically
• One user would take a picture of this screen [outcome screen] using their phone ‘to keep as a reference’

This was a sample size of 5 users all were classed as having high digital confidence.

After this feedback we created the design below:

Our reasons behind design changes:
• Removed the email option - during testing this didn't work for some users, for multiple reasons. There is also no feedback to the user if it's working/isn't working. Due to the difficulty this caused we decided to remove it
• Added a download option - this became the main option users had to send the information as an email. All users preferred emailing so we need to keep this option, and most users knew either how to or wanted to download the form and send it that way.
• I saw earlier in this thread that the word 'save' was preferred for downloading a PDF/file, so could change 'download' to 'save' in the first bullet point

We haven't had any more user research carried out on this but we will likely use this design pattern again in the future and will include questions regarding this component.

Happy to get your thoughts on this approach and hopefully this adds some more information to the discussion.

[connorthompsoncode]

We had some further user comments from a live product where we used the design pattern I mentioned above. Once the tool went live, users were sending in comments through the 'Is this page not working properly?" link we have an all pages for users to submit problems.

Main user comments:

• When clicking the save/print link, some users did not know how to navigate the print dialog to be able to save as PDF
• On some browsers/devices (mainly mobile devices with the main ones being Safari on iOS and iPad and Samsung Internet on Samsung devices, not all user on these devices/browsers experienced this problem however) nothing happened when clicking the link. We found this was due to JavaScript being disabled, this doesn't seem to be a default setting and we were unable to find out why some users had this setting disabled.
• Some users, mainly ones using Samsung Internet on a Samsung browser, after saving the PDF only received blank pages.

From this feedback we updated the pattern to the below:

Changes we made:

• We included the first three bullet point instructions to guide them through the print dialog box to be able to save or print
• We added the content within the progressive disclosure/details component to offer another set of instructions for the users where the link didn't work.
• We're still looking into the issue with blank pages in the PDF and have not found the cause for this yet.

We're still working on this pattern as a team and will run it through another round of user research in the future. This pattern is also live on a couple of our tools so we'll continue to gather feedback that way.

[gazjoy]

Hey @connorthompsoncode thanks for sharing your approach. We're also considering how we might do this on Apply for a Blue Badge. Do you have any insights into how this tested and where you ended up with it since your last comment?