How We Rebuilt Our Upload UI After Watching Users Struggle

Twelve recordings, three failure patterns, and the change that moved completion 22 percent.

Our upload UI looked fine in every design review. Then we watched twelve people try to use it. In recording four, the cursor circles the page twice, passes directly over the drop zone without recognizing it as a target, drifts back to the top of the form, and the session ends. Nobody had ever done that in a design review.

“We watched 12 session recordings of users failing to upload files and found three patterns: nobody noticed the drop zone, errors appeared after submission instead of at selection, and mobile users could not find the camera. The rebuilt upload UI fixed all three and raised completion 22 percent.”

Analytics had already told us completion was falling. Analytics could not tell us where the hope drained out of a session. The recordings could, and they did it in an afternoon.

Key Takeaways

• Twelve session recordings surfaced three failure patterns that aggregate funnel analytics had hidden for months.
• Validating a file at selection rather than at submission was the single highest-impact change we made.
• A drop zone needs a visible affordance and a keyboard path, not only a rectangle that accepts a drop.
• Mobile users photograph documents, so the camera belongs beside browse rather than behind it.
• Completion rose 22 percent within two weeks of shipping the rebuilt flow.

What the Recordings Showed

The method was unglamorous. We pulled twelve unmoderated session recordings from people who had reached the upload step, six on desktop and six on mobile, and watched all of them in one sitting. Twelve is a small number, and it is also more than enough: the usability research on sample size has been saying for years that a handful of sessions surfaces most of what is wrong, and that running more small rounds beats running one large one.

Three patterns turned up, each repeating often enough that nobody argued about whether it was real. Nine of the twelve never recognized the drop zone. Seven of the twelve met their first error after submitting the form, at which point the file selection was gone and the whole thing had to be done again. And five of the six mobile users went hunting through their photo library for a document that was physically sitting on the desk next to them, because the flow offered Browse and said nothing about a camera.

None of it was in the funnel. A completion rate and a drop-off percentage are both true, and neither tells you a person is circling a page hunting for something we thought was obvious. Analytics count how many people fell. Recordings show where the floor gave way.

Principle 1, Make the Drop Zone Unmissable

Our old drop zone was a dashed rectangle with the words "Drag files here" inside it. In a mockup that reads as an interactive region. On a real page, surrounded by real content, it reads as a decorative box, which is precisely what the recordings showed people treating it as. A dashed border is a visual convention, not an affordance: it suggests nothing about what you can do to it.

The rebuilt version says what it is and offers more than one way in. A solid bordered region with an icon, a sentence of instruction, and a real Browse button inside it, because the button is what most people reach for even when dragging works. The whole region is the drop target; it changes state the moment a file is dragged anywhere over the window, and it is operable from the keyboard, which the old one was not.

Go looking for how to implement a drag-and-drop image upload, and most of what you find covers the drop event and stops. That is the easy half. The half that decides whether anyone uses it is whether the region announces itself as somewhere a file can go.

Principle 2, Validate at Selection, Not Submission

This was the highest-impact change of the three, and it is barely a design change at all. It is a change of timing.

The old flow took whatever you handed it, waited until the rest of the form was filled in, then rejected the file on the server with a message about supported types. Everything done in between was wasted, and the selection did not survive the round trip, so the file had to be found again too. Seven of twelve hit this.

Now the check runs the instant a file is chosen, before anything else is filled in. If a file is the wrong type or over the size limit, it is refused immediately and the message says which one and what would be accepted instead. The person is still holding the file. Fixing it costs one click rather than a re-run of the entire form.

Ask how to improve the user experience of a file upload UI and the answers arrive as a list of components. The more useful answer is a rule about ordering. Every fact the user needs should reach them the moment it is knowable, and nothing about a rejected file type becomes true at submission. It was true at selection. We were choosing to tell them later.

Principle 3, Camera as a First-Class Source

Nobody on the team predicted this one, because we had all tested the flow on phones and it worked. We were testing whether the mechanism worked. The recordings showed what people were trying to do.

They were photographing documents. A receipt, an ID, a signed page. The document is on the desk, the phone is in their hand, and the interface offers Browse, which opens a photo library holding no picture that has not been taken yet. Five of six went into the library, scrolled, came back out, and stalled.

The fix is small and slightly embarrassing in retrospect. Camera is now a labelled source sitting beside browse, not an option nested inside a system sheet two taps in. On mobile it is the first thing offered, because on mobile it is the most common intent.

The Rebuild

We rebuilt on a component-based upload UI rather than restyling what we already had. The three findings pointed at behavior we would otherwise have had to write from scratch and then own: a drop zone with proper affordance and keyboard support, a camera source that behaves correctly across mobile browsers, and validation that runs at selection with a usable message attached.

Worth being concrete here, because the research is the interesting half of this story and the implementation was not. Composing the picker and configuring our rules took a sprint. Writing the same behavior ourselves, mobile browser differences included, was the quarter we had been dreading and the reason the rebuild had already been deferred twice.

We composed the drop zone and its states, the source list including camera, the selection-time validation hooks, and the progress and thumbnail states. We kept which files we accept and why, the wording of every message, and where an uploaded file lands in our data model. That is roughly the split you find whenever you look at what popular file upload UI components cover, and it is the right one. What we kept is what is about our product.

Watch Before You Redesign

Three principles came out of it. Make the drop zone unmissable, with an affordance and a keyboard path. Validate at selection, while the file is still in the person’s hand. Treat the camera as a source in its own right, because on a phone it usually is the source. Completion rose 22 percent in the two weeks after all three shipped.

The part worth repeating is the cheap part. Twelve recordings cost an afternoon, and we had spent longer than that arguing in meetings about whether the drop zone should be taller. Every one of those meetings was people guessing at a question twelve strangers had already answered, in recordings nobody had opened.

Frequently Asked Questions

How many session recordings do you need to find upload UI problems?

Twelve was plenty, and the usability literature suggests five per round surfaces most of what is wrong. What mattered more than the count was watching desktop and mobile separately, since our third pattern appeared only on phones.

Why validate files at selection instead of at submission?

Because nothing about a rejected file becomes true later. Validating at selection means the person is still holding the file when they learn something is wrong, so the fix costs one click instead of a repeat of the whole form.

What makes a drop zone actually get used?

A solid bordered region with an icon and an instruction, a real browse button inside it, the whole area as the drop target, a visible state change while dragging, and keyboard operation. A dashed rectangle alone reads as decoration.

Do mobile users really need a camera option?

Five of our six mobile testers were trying to photograph a physical document. Offering only a browse button sends them into a photo library looking for an image that does not exist yet.