File upload

Problem Context

• The product needs the original file for evidence, identity, compliance, media review, document processing, or support investigation.
• Users may be on mobile devices, public computers, locked-down desktops, or assistive technology where drag-and-drop may not be available.
• The file may fail because of type, size, malware scanning, password protection, interrupted network, duplicate attachment, or expired session.
• The upload may happen immediately after selection or later with the form submit, and users need to understand which model is active.
• The service must validate selected files server-side even when the client limits accepted extensions or MIME types.

Selection Rules

• Choose file upload when the original file itself is needed, not just information from the file.
• Use text input when a typed value, reference number, or explanation can replace the file.
• Use a single-question page before upload when users first need to answer whether they have evidence or which evidence type applies.
• Use a multi-step form when upload depends on earlier answers or is one saved step in a longer journey.
• Use drag-and-drop upload only as an enhancement when button-based file selection remains available.
• Use bulk import when the file contains structured rows that need parsing, mapping, validation, and an import report.
• Avoid asking for an upload unless the file is critical to completing the service.
• State accepted formats, maximum size, count limit, password-protected file policy, and whether photos or scans are acceptable.
• Preserve selected filenames and unrelated answers after recoverable validation or network errors.
• Make the upload-versus-submit boundary explicit when the surrounding form still needs final review.

Required States

• Empty labelled state with requirements hint and choose-file action.
• File chooser invoked state with focus returning to the upload control.
• Selected but not uploaded state showing filename, size, type, and remove action.
• Uploading state with progress or pending indicator tied to the file.
• Uploaded state showing successful attachment and replace or remove controls.
• Wrong file type error state with accepted formats repeated.
• File too large error state with maximum size and current file size.
• Upload failed state with retry and keep-file guidance.
• Removed file state confirming no attachment is queued.
• Submitted state clarifying that the upload is included with the completed form.

Interaction Contract

• Activating the choose-file button opens the platform file picker and returns focus to the invoking control or selected file summary afterward.
• Selecting a file records filename, size, type, and local selected state before upload validation starts.
• Client validation can warn about accepted types and size, but server validation remains authoritative.
• Removing a file clears only that attachment and does not erase other form values.
• Retrying a failed upload keeps the selected filename visible while the retry is pending.
• Submitting the surrounding task is blocked until required uploads are valid or the user chooses an allowed no-file path.
• Status changes are announced without repeatedly reading long filenames or progress updates on every small percentage change.

Implementation Checklist

• Define accepted extensions, MIME types, maximum size, count limit, scanning policy, duplicate handling, password-protected file handling, upload timing, and storage outcome before designing the control.
• Use a visible label and persistent hint; connect hint, selected-file summary, status, and error text to the input or upload button.
• Show selected filename, file size, upload state, uploaded result, remove action, retry action, and final included-in-submission state.
• Validate type, size, count, empty required state, duplicate file, interrupted upload, virus scan, and server rejection with specific recoverable messages.
• Keep other answers and selected filenames visible after validation errors and network retries.
• Test keyboard selection, focus return, screen reader announcements, mobile camera/file sources, public-device privacy, browser Back, slow networks, timeout, and unsupported file formats.
• Do not make drag-and-drop the only upload path; keep a normal file chooser available.

Common Generated-UI Mistakes

• Asking for a file when a typed reference number or simple answer would be enough.
• Showing selected filename as if the final service submission has already happened.
• Hiding accepted formats and maximum file size until after the user fails.
• Clearing the selected file and unrelated form answers after a recoverable error.
• Using drag-and-drop as the only interaction path.
• Relying on the accept attribute or filename extension as proof that the file is safe or valid.
• Treating structured spreadsheet imports as ordinary attachments with no row-level feedback.

Critique Questions

• Why does the service need the original file rather than a typed value?
• What file types, sizes, count limits, password policies, and scanning delays will users encounter?
• Can users tell whether the file is selected locally, uploading, uploaded, failed, removed, or included in final submit?
• What happens if upload fails after the user has filled the rest of the form?
• Can keyboard, screen reader, mobile, and public-computer users complete the upload path without drag-and-drop?
• Does the backend validate the same type, size, count, scan, and required-file rules as the UI?