File Upload
Somebody attaches a 40 megabyte scan to a support request. A bar creeps across for three minutes on a hotel connection, reaches the end, and the screen says the upload did not work.
A stuck upload sends users away in silence. Learn the patterns that keep them, in one short listen.
Listen to the full File Upload course on DesignPathIt does not say why. The size limit was on the page, under the button, in gray, at eleven pixels, and they were looking at the file picker when they passed it. So they try again with the same file, because nothing told them the second attempt would end the same way.
An upload is the one control that takes something from the person's own machine and holds them while it travels. It can also refuse the file for half a dozen reasons they cannot see in advance. Almost every other input in a form is instant and local.
That combination is why it goes wrong so reliably, and why the fix is mostly about saying things earlier rather than about the control itself.
Anatomy of an Upload
An upload looks like a button. It is seven parts, and the ones that decide whether it works are the ones that only appear after somebody has already committed.
The Parts
Seven, and a design file usually shows the first two.
The trigger, meaning the button and the drop zone together. The constraints, saying what is accepted before anything is chosen. The file list, once something is picked. The per-file row, with its name, size and state. The progress for each file and often for the batch. A remove control per row. And the submit, where the upload is part of a larger form rather than the whole of it.
Four States, per File
The state belongs to a file, not to the upload, and that is the distinction most implementations get backwards.
Queued, chosen but not yet sent. Uploading, with progress. Done, accepted and stored. And rejected, with a reason. A batch of eight can hold all four at once, which is why a single banner reading upload complete or upload unsuccessful cannot describe what happened. Article 6 covers refusing one file without discarding the other seven.
Where the Upload Sits
Two arrangements, and they behave differently.
Standalone, where choosing the file is the action and it uploads at once, as an avatar or a document library does. Or inside a form, where the file is one field among several and the submit belongs to the form. The second needs a decision nobody usually makes. Uploading while the person fills in the rest is faster and leaves orphaned files when they abandon. Waiting for submit is simpler and makes the last click take three minutes.
What It Takes From the Person
The property that makes this different from every other input.
An upload reaches into their own machine, holds them while bytes travel, and can be refused for reasons that live on your server. No other form control does all three. Everything that follows comes from that. Say the rules before they choose, show honest progress while they wait, and explain a refusal in terms of the file they picked.
Pro tip: Upload eight files at once to your own product, with one of them too large. Whatever the screen says about the other seven tells you whether the state was built per file or per upload.
