File upload vs Text input vs Single-question page vs Multi-step form

Prefer file upload when the service needs the original document, image, scan, certificate, spreadsheet, or media file rather than a typed summary of its contents.

File upload live example Text input live example Single-question page live example Multi-step form live example

Decision dimensions

Dimension	File upload	Text input	Single-question page	Multi-step form
UI or UX	UI + UX - File selection and attachment control	UI + UX - Single-line freeform data-entry control	UI + UX - Focused form page for one answer or decision	UI + UX - Multi-page transaction with saved step state
UI guidance	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 a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.	Render one clear question as the page heading, optional explanatory text before the answer, one answer area, a primary Continue action, and a Back link or equivalent return path.	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.
UX guidance	Use file upload only when the service needs the original file and make expectations clear before the user opens the file picker.	Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.	Use a single-question page when users need to focus on one decision, understand one piece of information, or answer one conceptual question before moving on.	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.
Good UI	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 reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.	A page heading asks Do you have evidence to upload?, explanatory text sits above a yes/no radio group, Continue follows the answer, and Back returns to the previous service step.	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.
Bad UI	A button labelled Browse sits under Documents with no hint about accepted formats, size limit, or whether the selected file was uploaded.	The only instruction is placeholder text that disappears when the user starts typing.	One page asks for name, address, evidence status, and payment method under a vague Details heading.	A five-screen flow shows all steps as complete after users only viewed them.
Good UX	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 types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.	A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected.	A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.
Bad UX	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.	Validation fires on the first focus event and blocks typing before the user has had a chance to answer.	A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.	A user changes an early answer and the form silently submits later answers that no longer apply.
Best fit	The service needs a document, image, scan, spreadsheet, media file, or other original file.	The answer is short and user-authored.	One answer or decision should be read and completed without competing form questions.	A transaction spans several ordered pages or sections.
Avoid when	A typed answer, reference number, checkbox, or declaration would satisfy the task.	The answer is a paragraph, comment, address block, or explanation requiring multiple lines.	Users need to compare or edit several fields together before submitting.	The fields are short, related, and easier to scan together on one page.
Required state	Empty labelled state with requirements hint and choose-file action.	Empty untouched state with persistent label and optional hint.	Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action.	Not-started state with clear start point and expectation of the steps or sections ahead.
Accessibility burden	Use a visible label that names the file purpose, not only Browse or Choose file.	Associate every text input with a visible label or equivalent accessible name that matches the visible question.	Use a single visible h1 that states the question users are answering.	Use a clear page heading on every step and keep it synchronized with route and progress context.
Common misuse	Asking for a file when a typed reference number or simple answer would be enough.	Using placeholder text as the only label or instruction.	Putting several unrelated questions on one page and still calling it one thing per page.	Using a multi-step form to hide a short related form that users should review on one page.

File upload

UI or UX: UI + UX - File selection and attachment control
UI guidance: 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.
UX guidance: Use file upload only when the service needs the original file and make expectations clear before the user opens the file picker.
Good UI: 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.
Bad UI: A button labelled Browse sits under Documents with no hint about accepted formats, size limit, or whether the selected file was uploaded.
Good UX: 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.
Bad UX: 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.
Best fit: The service needs a document, image, scan, spreadsheet, media file, or other original file.
Avoid when: A typed answer, reference number, checkbox, or declaration would satisfy the task.
Required state: Empty labelled state with requirements hint and choose-file action.
Accessibility burden: Use a visible label that names the file purpose, not only Browse or Choose file.
Common misuse: Asking for a file when a typed reference number or simple answer would be enough.

Text input

UI or UX: UI + UX - Single-line freeform data-entry control
UI guidance: 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 text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI: 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 only instruction is placeholder text that disappears when the user starts typing.
Good UX: A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX: Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit: The answer is short and user-authored.
Avoid when: The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state: Empty untouched state with persistent label and optional hint.
Accessibility burden: Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse: Using placeholder text as the only label or instruction.

Single-question page

UI or UX: UI + UX - Focused form page for one answer or decision
UI guidance: Render one clear question as the page heading, optional explanatory text before the answer, one answer area, a primary Continue action, and a Back link or equivalent return path.
UX guidance: Use a single-question page when users need to focus on one decision, understand one piece of information, or answer one conceptual question before moving on.
Good UI: A page heading asks Do you have evidence to upload?, explanatory text sits above a yes/no radio group, Continue follows the answer, and Back returns to the previous service step.
Bad UI: One page asks for name, address, evidence status, and payment method under a vague Details heading.
Good UX: A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected.
Bad UX: A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.
Best fit: One answer or decision should be read and completed without competing form questions.
Avoid when: Users need to compare or edit several fields together before submitting.
Required state: Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action.
Accessibility burden: Use a single visible h1 that states the question users are answering.
Common misuse: Putting several unrelated questions on one page and still calling it one thing per page.

Multi-step form

UI or UX: UI + UX - Multi-page transaction with saved step state
UI guidance: 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.
UX guidance: 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.
Good UI: 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.
Bad UI: A five-screen flow shows all steps as complete after users only viewed them.
Good UX: A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.
Bad UX: A user changes an early answer and the form silently submits later answers that no longer apply.
Best fit: A transaction spans several ordered pages or sections.
Avoid when: The fields are short, related, and easier to scan together on one page.
Required state: Not-started state with clear start point and expectation of the steps or sections ahead.
Accessibility burden: Use a clear page heading on every step and keep it synchronized with route and progress context.
Common misuse: Using a multi-step form to hide a short related form that users should review on one page.

Decision rules

Prefer file upload when the service needs the original document, image, scan, certificate, spreadsheet, or media file rather than a typed summary of its contents.
Prefer text input when the user can provide the needed value directly, such as a reference number from the document, without forcing them to find and attach a file.
Prefer a single-question page before upload when the first decision is whether the user has evidence, what kind it is, or whether the upload route should appear at all.
Prefer a multi-step form when file upload depends on earlier eligibility, identity, case type, or review answers and must preserve progress across pages.
Use a standard file upload before a drag-and-drop uploader when the main requirement is reliable file selection, clear labels, selected filename display, and accessible keyboard operation.
Reserve drag-and-drop upload for workflows where users commonly move files from a desktop folder and the same area still provides a button or link that opens the file chooser.
Reserve bulk import for structured records that need parsing, row validation, mapping, partial success handling, and import reports rather than a normal evidence attachment.
State accepted file types, maximum size, file count, and whether upload happens immediately or only after the surrounding form is submitted.
Show selected filename, upload progress, uploaded state, remove control, file-specific errors, and retry path before users continue.
Validate selected files on the server as well as the client because accept filters and filename extensions do not prove safe or valid content.

Inspect live examples

File upload Text input Single-question page Multi-step form

Failure modes

A service asks for a file when a typed reference number would satisfy the decision and be easier for mobile users.
The upload label says Attach evidence but the hint never states accepted formats, maximum size, or whether photos are allowed.
A selected file disappears after an error, forcing the user to browse for the same document again.
The page says uploaded when the file is only selected locally and the final form submission has not happened.
Drag-and-drop is the only path, so keyboard, mobile, and assistive technology users cannot add a file.
A spreadsheet import is treated like a simple file attachment, so row errors and partial imports have no recovery path.