Uploads
File upload UX: the journey continues after the progress bar
UxerProof Editorial · · 3 min read
A progress bar reaching its end does not necessarily mean a file is ready to use. The application may still be processing it, attaching it to a record or waiting for a separate save action.
An upload review should continue until the intended role can find and use the resulting file. It should also establish what happens when the file is rejected or the operation is interrupted.
Prepare safe, recognizable test files
Use clearly marked synthetic files. Choose fixtures that match the product's supported types and documented limits, plus controlled examples that should be rejected. Avoid personal documents and customer attachments.
Name the intended destination: a draft record, a media collection or another specific object. If upload and attachment are separate operations, make both parts of the task explicit.
Follow the states the interface exposes
| Stage | Question to answer |
|---|---|
| Selection | Are supported formats and relevant limits explained before avoidable effort? |
| Transfer | Is progress or waiting understandable? |
| Processing | Can the person distinguish an uploaded file from a usable one? |
| Attachment | Is the file connected to the intended record? |
| Return visit | Can the authorized role find and open it later? |
Test with the input methods the product supports. A drag-and-drop zone should not be the only path considered when a file-selection control is also intended to exist.
Inspect rejection and interruption
Try one unsupported fixture and one file that exceeds the documented limit. Does the message explain which condition failed and how to proceed? Does a rejected item remain in the list as if it were complete?
In an authorized environment, inspect a controlled interruption. Determine whether retry restarts or resumes according to the product's design, and whether abandoned uploads need cleanup. Do not infer storage cleanup from the disappearance of a progress indicator.
If the same file is selected twice, inspect the intended duplicate behavior. A product may allow duplicates or prevent them; the important point is that the result is understandable and matches its rules.
Verify persistence and access separately
Save the parent record, reload and open the attachment through the normal interface. Confirm that the visible name and associated record are correct.
This journey check does not certify malware handling, content validation, storage authorization or cross-tenant isolation. Those controls require separate technical evidence. If a security boundary behaves unexpectedly, stop and escalate rather than expanding the test informally.
The report should identify the last completed stage. “Upload failed” is too vague if transfer succeeded but attachment to the record did not. Naming the stage helps the team repair the actual break in the journey.
Next step: Plan capture and cleanup using privacy-conscious journey testing.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.