Forms that don't fail: designing multi-stage data capture

Consider a hypothetical supplier-onboarding application. Someone enters company details, adds a second operating location and uploads a supporting document. Then they change an earlier answer: the second location is no longer needed. The delivery specification must settle which answers survive, which need checking and which reach the receiving system. A sequence of screens leaves those decisions unresolved.

Start multi-stage form design with recoverable work: explicit rules for changing, saving, validating and submitting answers. Government and W3C guidance supports the question and validation practices below. The recovery and submission patterns are design recommendations to specify and test, not measured findings or promises of failure-proof software.

Define states before screens

Before approving screens, agree a state model across product, design, engineering and operations. Separate the application's lifecycle from the condition of individual answers. In this onboarding journey, a draft could contain valid company details, a missing address and a document awaiting verification. Do not compress those conditions into a single “complete” flag.

• Draft: work has started but has not been submitted.
• Incomplete: information required for the current path is missing.
• Invalid: an answer fails an applicable validation rule.
• Valid: an answer passes the applicable checks in its current context.
• Pending verification: an answer or document awaits a separate check, with no result yet.
• Ready for review: the current path meets the agreed conditions for review.
• Submitted: the receiving system has recorded acceptance of the submission, not necessarily approved the application.

For each transition, name the responsible system, the condition that permits it and the message the person sees. Decide whether pending verification blocks submission or continues afterwards. Where operations must resolve a check, specify the handoff and owner. These decisions belong in the delivery contract, including when different vendors own the form and the receiving service.

Start with a question protocol

Create a question protocol: a record of why each answer is requested and how it will be used. Document the consuming team or system, when the answer becomes necessary, its dependencies, validation rules and what happens when it changes. Remove questions without a justified use. Explain the purpose where it is not obvious, rather than collecting information simply because a legacy record has space for it.

GOV.UK's Service Manual recommends branching so people answer only relevant questions. Its starting point is one thing per page, with user research determining when pages can be merged. This is guidance, not evidence that every field needs its own screen.

For the hypothetical onboarding journey, ask whether another location is involved before requesting its address. Put path-setting questions before their dependents, then group inputs around a coherent task. Keep the dependency rules explicit enough to implement and test independently of the page layout.

The UK Home Office's accessibility guidance recommends a label for each field, hints about expected entries, autocomplete for fields requesting information about the user, and fieldset/legend grouping for related controls. Use those HTML elements to give related controls a shared group label. Keep field labels visible rather than using placeholder text as the question, and choose input controls suited to the information requested.

Make branching preserve the work

Specify answer handling separately from question visibility. When a controlling answer changes, decide which dependent answers become irrelevant and which remain relevant but need revalidation. Hiding a question must not leave its eligibility for submission undefined.

Changing a location, rather than removing it, may leave related answers in need of checking. Mark the affected sections, explain what needs attention and preserve unaffected work. Set a separate policy for retaining inactive answers, balancing recovery needs against unnecessary data storage. Preservation should not mean keeping every answer indefinitely.

Back navigation should restore current answers and relevant context without submitting the application. When the remaining path is unknown, use section names and statuses such as “Company details saved” or “Locations need attention”. Reserve fixed step totals for paths whose length is known, and use “saved” only when persistence has been confirmed.

Validate for correction, then with authority

GOV.UK's 2018 guidance on designing questions recommends tolerant validation and field-specific errors that explain how to fix the problem. Accept harmless formatting differences where the underlying value remains unambiguous. State necessary format constraints before entry, and distinguish a missing answer from one supplied in an unacceptable form.

W3C guidance states that client-side validation alone does not ensure security and that data also needs server-side validation. For this workflow, make the server authoritative for accepting answers and submission. Use browser checks for timely guidance, and define how server responses map back to fields and sections, including earlier pages. Agree this application-specific contract across the systems involved; the guidance does not prescribe the architecture.

For submitted data containing errors, W3C recommends concise, clear feedback with simple resolution instructions. It describes moving focus to the first erroneous input as convenient, not a universal requirement. Specify the focus destination for a rejected submission and test it, rather than leaving it to incidental page rendering.

Provide field-level corrections and an error summary linking to affected inputs. Preserve entered values and associate messages with their controls. Test that keyboard users can reach each correction and screen-reader users can identify the field, its error and the required action. During ordinary editing, keep focus stable rather than moving it whenever validation runs.

Design interruption and upload recovery

Make saving a contract between the interface and the system that stores the draft. Specify what is saved, how persistence is acknowledged and how someone resumes. If saving fails, distinguish unsaved changes from the last saved version and explain the available recovery action. Do not display success while the outcome remains unknown.

Specify session expiry separately from draft retention. Define the expiry warning, any supported extension route, what happens to unsaved entries and where reauthentication returns the person. Agree storage and retention decisions with privacy and security owners, then describe the actual behavior without promising indefinite recovery or unsupported security guarantees.

For uploads, distinguish transfer progress from file acceptance and later verification. Explain supported files and applicable limits before selection. On failure, preserve the rest of the application and offer a targeted retry. If the response is lost after transfer, check whether the file was received before creating another attachment. Specify replacement and removal too.

Test these recovery requirements at each system boundary, checking both the interface and the stored record. Where a legacy service cannot support the intended behavior, assign an owner to resolve the limitation or define an honest fallback before release. The interface should promise only the recovery the service can deliver.

Put a clear boundary around submission

Provide a review of the active application, with routes to edit each section and return without losing unrelated work. Show unresolved checks explicitly. Before accepting submission, revalidate against the current path and applicable rules. If saved data has become stale, identify what needs reconfirmation rather than silently submitting or overwriting it.

Specify duplicate handling on the server as well as button behavior. A retry of the same logical submission should return its recorded outcome rather than create another application. Where the outcome is uncertain, show that uncertainty and offer a status check or controlled retry. Confirmation must distinguish submission from any later approval.

Use these acceptance checks as release criteria. Agree the expected interface state, stored result and responsible owner for each one.

• Interruption: leave and resume partway through, including after session expiry. Verify persistence, reauthentication and accurate saved-status messages.
• Network failure: lose the response during saving, upload and submission. Resolve uncertain outcomes without blind repetition or duplicate records.
• Stale data: resume an older draft after a relevant rule or record changes. Require the necessary recheck while retaining unaffected answers.
• Mistaken input: return multiple field errors. Verify retained values, keyboard access, focus behavior and understandable screen-reader feedback.
• Conditional paths: change a controlling answer, go back and restore it. Check dependent validity, inactive data, progress wording and final submission contents.
• Review and edit: edit from review. Return to updated answers with any new dependencies exposed.
• Duplicate submit: repeat the action and retry after a lost response. Verify one accepted application and consistent confirmation.

Before approving the redesign, can your team demonstrate recovery from interruption through to one confirmed submission?