How to Make Document Uploads Work for the People Using Your Service

A person reaches the final stage of an online application, selects a document and presses submit. The page waits, then returns a generic error. They cannot tell whether the file was too large, the connection failed or the application has already been received. Trying again might help, but it might also create a second submission.

For the organisation, the consequences appear elsewhere: incomplete cases, calls asking whether evidence arrived, documents sent to shared inboxes and staff trying to match attachments to the right record. A small upload control can create a substantial amount of avoidable work.

A dependable document upload needs clear instructions, useful feedback, appropriate protection and a defined route into the service behind the form. Those decisions deserve attention before the page is treated as finished.

Decide which evidence the service actually needs

Begin with the decision the document supports. Does a member of staff need the whole report, a particular page or a reference number that could be checked another way? Is the evidence required at submission, or only after an initial eligibility check?

The GOV.UK Design System's file upload guidance recommends asking for uploads only when they are critical to delivering the service. That is a useful starting point for commercial services as well: every requested document creates preparation work for the user and handling work for the organisation.

Write down the minimum acceptable evidence and who can approve an alternative. A photograph may be sufficient for one process, while another needs a complete document with readable dates and reference numbers. Make those distinctions explicit rather than expecting users or support staff to infer them.

Explain the requirements before the file is selected

People may be using a phone, a shared computer or a document someone else prepared. Tell them which file formats are accepted, the maximum size of each file, how many files they can provide and whether several pages should be combined or uploaded separately. Explain any restriction on password-protected documents before they attempt the upload.

Choose those rules around the task. A size limit that suits a short text document may reject an ordinary phone photograph. Requiring a PDF can add a conversion step that users cannot easily complete. Test representative files from the devices people actually use, then agree limits that the service can support.

Keep requirements consistent across the page, application and hosting configuration. If the page promises a larger file than the server will accept, the user receives a technical failure for following the instructions correctly. Include a practical help route for people who cannot provide evidence in the requested format.

Make selection, transfer and submission distinct

Selecting a file does not necessarily send it to the server. Sending it does not necessarily complete the application. The interface should make each stage clear, especially when there is a separate final submit button.

Show the selected filename and provide a straightforward way to remove or replace it. During transfer, explain that work is in progress. After receipt, show a meaningful status for each file. If security checks take time, say that the file is awaiting checks rather than implying that it is ready for staff to use.

Keep an accessible file-selection control available even when drag and drop is offered. Test the journey using a keyboard, screen reader, mobile device and browser zoom. Users need to discover the requirements, choose the file, understand any status change and recover from a problem without relying on colour or a visual progress animation alone.

Where several files are required, a failure in one should not force the user to start the entire task again. Preserve successfully received files and other form answers within the agreed session and privacy rules. Explain clearly when a file must be selected again.

Give each failure a useful next step

A generic upload error leaves people guessing. The GOV.UK guidance distinguishes problems such as an empty file, an unsupported format, an excessive file size and a failed transfer. Use that distinction to tell the user what happened and what they can do next, with the message connected to the affected control.

Keep service faults separate from problems the user can correct. If storage or a scanning service is unavailable, asking someone to change their document will not resolve it. Explain whether retrying is appropriate, whether their other answers remain saved and how to get help if the problem continues.

Plan for an uncertain response as well as a definite failure. A connection can drop after the server receives the document but before the browser receives confirmation. The system should check the existing submission and handle repeat attempts safely, so that pressing submit again does not create duplicate cases or attachments.

Protect the document throughout its journey

The upload control is only the entry point. Decide who may upload, who may retrieve a document and how access will be checked when a download link is used. A hard-to-guess address should not be the only protection for private evidence.

OWASP's file upload guidance recommends layered controls, including limiting permitted formats and file sizes, validating file types, generating storage filenames, separating uploads from the public web root and applying malware checks where available. It also warns against trusting the file type reported by the browser. These are useful requirements to discuss with the technical team, rather than assuming a file extension check makes an upload safe.

Define what happens while checks are pending and when checks cannot run. Keep unverified documents away from ordinary downloads and downstream processing until the required checks pass. Support staff need a controlled route for investigating a stalled upload without bypassing those protections.

Set a retention rule for abandoned uploads, replaced evidence and completed cases. Include temporary storage and exported copies in that plan. Notifications and monitoring should use a submission reference where possible, keeping document contents and sensitive filenames out of routine emails and logs.

Prove that staff can use what arrived

A successful transfer is not the end of the journey. Confirm that the document is attached to the correct case, that the responsible team can open it and that its status matches what the user was told. A confirmation email should follow a recorded receipt, rather than merely the browser starting a request.

Agree how unreadable, incomplete or incorrect evidence will be returned for replacement. Keep a clear record of which version staff reviewed and whether a new upload changes the case's readiness for processing. Otherwise, a technically working upload can still leave staff making decisions from an old attachment.

Test with synthetic documents in a controlled environment. Include a large phone photograph, several pages, an unsupported format, a password-protected file, an interrupted connection and an unavailable scanning service. Follow each attempt through to the staff view and the final confirmation. Check that another user's document cannot be retrieved by changing a reference or reusing an old link.

Improve one complete upload journey first

Choose a form that regularly creates support requests. Observe representative users, review failure counts without collecting document contents and ask staff where evidence becomes difficult to process. Then improve the instructions, status messages and handling rules together.

Measure whether more people complete the task without help, whether repeat submissions fall and whether staff receive usable evidence attached to the right record. Those outcomes provide stronger evidence of improvement than the number of files transferred.

Gemstone's website development services cover responsive websites and manageable content systems. If document collection is creating friction for users or extra administration for your team, reviewing the full journey can identify a focused set of changes with a clear, testable result.