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

Use file upload when the user must attach a document or media file; use text input for typed values, a single-question page to decide whether evidence is needed, and a multi-step form when upload is one guarded step in a longer journey.

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

Learn the decision

Match the interaction to the person's task

File upload

Use it when: The service needs a document, image, scan, spreadsheet, media file, or other original file.

Make this state clear: Empty labelled state with requirements hint and choose-file action.

Observe the result: 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.

Study the full pattern →

Text input

Use it when: The answer is short and user-authored.

Make this state clear: Empty untouched state with persistent label and optional hint.

Observe the result: 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.

Study the full pattern →

Single-question page

Use it when: A sequential service flow needs reliable answers before deciding the next page.

Make this state clear: Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action.

Observe the result: A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected.

Study the full pattern →

Multi-step form

Use it when: A transaction spans several ordered pages or sections.

Make this state clear: Current step state with heading, saved context, local answer controls, Back, and Continue.

Observe the result: A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.

Study the full pattern →

Practice the judgment: Imagine this situation: A service asks for a file when a typed reference number would satisfy the decision and be easier for mobile users. 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 →

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.	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.	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 date question uses three related fields on the same page because day, month, and year answer one question.	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 failed upload clears other form answers or returns users to the start of the journey.	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 leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.	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 goes Back to check the previous step and the question page clears the answer they already gave.	A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.
Best fit	The service needs a document, image, scan, spreadsheet, media file, or other original file.	The answer is short and user-authored.	A sequential service flow needs reliable answers before deciding the next page.	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.	Current step state with heading, saved context, local answer controls, Back, and Continue.
Accessibility burden	Keep requirements in persistent hint text and associate them with the file input or upload button.	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 failed upload clears other form answers or returns users to the start of the journey.
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: Keep requirements in persistent hint text and associate them with the file input or upload button.
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: 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 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 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: 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 date question uses three related fields on the same page because day, month, and year answer one question.
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 goes Back to check the previous step and the question page clears the answer they already gave.
Best fit: A sequential service flow needs reliable answers before deciding the next page.
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 browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.
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: Current step state with heading, saved context, local answer controls, Back, and Continue.
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.

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

Match the interaction to the person's task

File upload

Text input

Single-question page

Multi-step form

Workbench Context

Decision dimensions

File upload

Text input

Single-question page

Multi-step form

Saved items