Use drag-and-drop upload when desktop users benefit from dropping one or more files into a visible target; use ordinary file upload for the reliable baseline, multi-step form for journey structure, and text input when a typed value is enough.
Use drag-and-drop upload when desktop users benefit from dropping one or more files into a visible target; use ordinary file upload for the reliable baseline, multi-step form for journey structure, and text input when a typed value is enough.
Practice the judgment: Imagine this situation: Dropping a file outside the target opens the file in the browser and destroys unsaved form progress. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Drag-and-drop upload | File upload | Multi-step form | Text input |
|---|---|---|---|---|
| UI or UX | UI + UX - Drop-zone file upload enhancement with file input fallback | UI + UX - File selection and attachment control | UI + UX - Multi-page transaction with saved step state | UI + UX - Single-line freeform data-entry control |
| UI guidance | Render a large labelled drop zone with clear copy that says users can drag files there or activate a normal file picker, plus visible format, size, and count requirements. | Render a visible label, persistent hint, native file chooser or equivalent button, accepted file formats, maximum file size, selected filename, uploaded status, remove control, and field-specific error message. | Render each step as a focused page with a clear heading, progress context when useful, Back and Continue controls, local validation, and a final review page before submission. | Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. |
| UX guidance | Use drag-and-drop upload as an enhancement for users who can drag files from a file manager, while preserving an equivalent click, keyboard, and mobile path. | Use file upload only when the service needs the original file and make expectations clear before the user opens the file picker. | Use a multi-step form when a transaction is too long, conditional, high-stakes, or hard to recover from as one page, and users need manageable saved progress. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. |
| Good UI | A drop zone says Drag bank statements here or choose files, shows PDF/PNG/JPG up to 10 MB, highlights when files hover over it, lists two dropped filenames, and keeps a Choose files button visible. | An evidence upload field says Upload bank statement, hints PDF, PNG, or JPG up to 10 MB, shows statement.pdf selected, displays upload progress, and offers Remove. | A benefit application has Eligibility, Contact details, Documents, Review, and Submit pages, with the current step named in the heading and completed steps shown from saved data. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. |
| Bad UI | The whole page becomes a hidden drop target that opens the dropped file in the browser when users miss the box. | A failed upload clears other form answers or returns users to the start of the journey. | A five-screen flow shows all steps as complete after users only viewed them. | The only instruction is placeholder text that disappears when the user starts typing. |
| Good UX | A user drags two PDFs over the zone, sees the target activate, drops them, reviews both filenames, removes the wrong one, uploads the remaining file, and then continues. | A user selects bank-statement.pdf, sees it queued, watches progress reach uploaded, removes it to choose another file, then submits after reviewing the rest of the form. | A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. |
| Bad UX | A user drags a file over the page, misses the small target, and the browser navigates to the file, wiping unsaved answers. | A user selects a 28 MB scan, clicks Continue, and the page reloads with File failed but the selected filename and other answers are gone. | A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. |
| Best fit | Users often upload files from a desktop file manager and benefit from dropping one or more files into a visible target. | The service needs a document, image, scan, spreadsheet, media file, or other original file. | A transaction spans several ordered pages or sections. | The answer is short and user-authored. |
| Avoid when | A normal file input is sufficient and the extra drop-zone states would add confusion. | A typed answer, reference number, checkbox, or declaration would satisfy the task. | The fields are short, related, and easier to scan together on one page. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. |
| Required state | Idle drop zone with visible label, requirements, and choose-file fallback. | Empty labelled state with requirements hint and choose-file action. | Current step state with heading, saved context, local answer controls, Back, and Continue. | Empty untouched state with persistent label and optional hint. |
| Accessibility burden | Keep a visible label and instructions that name both drag-and-drop and choose-file paths. | Keep requirements in persistent hint text and associate them with the file input or upload button. | Use a clear page heading on every step and keep it synchronized with route and progress context. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. |
| Common misuse | Replacing the normal file chooser with a drop zone that only pointer users can operate. | Asking for a file when a typed reference number or simple answer would be enough. | Using a multi-step form to hide a short related form that users should review on one page. | Using placeholder text as the only label or instruction. |