INTRODUCTION
“Upload your document” sounds like a small request. To the person completing it, it can mean finding an email attachment, checking a format, renaming a file, reducing its size and wondering whether the right version reached the right place. A large drop zone does not answer those questions.
Good upload design starts before the file picker opens. It gives the person enough information to choose correctly, then keeps responsibility clear until the document has actually reached the state the service requires. The useful unit of design is the whole exchange.
Give the request a reason
Before specifying a control, write the sentence that explains why this file is needed. If the team cannot explain what the document enables, the request deserves scrutiny. A document that might be useful someday creates work for every person asked to provide it.
The GOV.UK Design System advises asking for an upload only when it is critical to the service. It also recommends reuse within a journey where security and privacy permit. That is a useful starting constraint, rather than an invitation to collect every document in advance.
For a hypothetical project briefing form, a logo file may be necessary before production begins but unnecessary before an introductory conversation. Moving the request to the right stage can improve the experience more than redesigning the picker. Make that sequencing decision before measuring whether the button is sufficiently visible.
Put the rules where the choice happens
A person should learn the accepted formats and size limit before opening their files. State whether one document or several are required and what the document should contain. If multiple versions exist, explain the distinction that matters: for example, a final signed document rather than an editable working copy.
Use the actual service rules. An example such as “PDF, up to 10 MB” is useful only if that is genuinely the limit. Do not borrow familiar numbers from a design-system demo. Ask the team what happens to a scan, an empty file, a long filename and a document protected by a password.
Avoid making the instructions depend on the surrounding desktop layout. On a phone, the picker may take over the screen. The short description beside the control needs to stand on its own when the person returns and tries to remember what they were asked to select.
Distinguish selected, transferred and accepted
A filename appearing beneath a button can mean several things. The file may merely be selected on the device. It may be travelling to the service. It may have arrived and still be undergoing checks. The interface should name the state it actually knows.
Consider an application with a final review page. If the user sees “Uploaded” and immediately closes the tab, does the service have the document? If another submission step remains, show it plainly. A reassuring checkmark is a poor substitute for a precise account of what has happened.
The W3C explanation of status messages describes making updates available to assistive technology without moving focus. For an upload, that means the progress and result need an accessible announcement as well as a visible presentation. Test what the person hears, not just what the designer sees.
Give each failure a useful next action
An error should help the person change something relevant. A file that exceeds the limit calls for a different action from an interrupted transfer. Repeating the same upload cannot fix a document the service will never accept.
Keep the chosen filename visible where possible, so the person knows which item failed. If several documents are involved, identify the affected item rather than painting the whole area red. Preserve completed work while explaining what still needs attention.
There is a tradeoff between simplicity and control. A single automatic upload can be convenient for a small attachment; a set of important documents may need an explicit review before submission. Choose the interaction around the consequence of a mistake, then make replacing or removing an item understandable.
Rehearse an ordinary interruption
Use a fictional customer who starts on a phone, picks the wrong file, corrects it and loses connectivity halfway through. Follow the journey without supplying verbal hints. Note every moment when the interface leaves them guessing whether to wait, retry or begin again.
After a successful transfer, ask a final question: can the customer tell where the document went and what happens next? The answer might be a saved draft, a completed application or a pending review. Those outcomes deserve different language even when they share the same technical upload control.
A practical review can fit on one page: purpose, accepted input, visible states, recovery actions and completion evidence. Resolve those five decisions before treating the upload as finished. The Blanche journal explores more of the small product interactions that determine whether a service feels coherent.
Sources checked on 9 November 2026. The GOV.UK component guidance includes a March 2025 improvement; this article uses it as established guidance, not breaking news.