Single-page form

Problem Context

• The form collects a compact set of related details, such as profile, contact, shipping, sign-in, or preferences.
• Users need to compare or revise multiple answers together before committing them.
• The task has limited branching and can preserve all entered values on one route.

Selection Rules

• Choose a single-page form when the task has a short related set of fields that users should review together.
• Prefer single-question pages when each answer needs focused reading, mobile-first recovery, branching, or per-page autosave.
• Prefer multi-step forms when fields are numerous, high-stakes, logically separated into sections, or too long for reliable one-page recovery.
• Use a wizard only when the sequence is guided, stateful, and dependent on previous answers.
• Group related controls with fieldsets, legends, headings, or section labels rather than presenting one undifferentiated list.
• Explain required and optional conventions before the first field and use native required attributes where appropriate.
• Use an error summary plus field-level messages when failed submit can produce more than one error.
• Preserve all field values after client or server validation and keep the submit action at the end of the reviewed form.

Required States

• Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
• Partially completed state where users can compare values across related fields before saving.
• Submitting state that prevents duplicate submit without hiding entered values.
• Failed-submit state with linked error summary and matching field-level messages.
• Corrected state where fixed fields clear their errors while other values remain intact.
• Successful submit state that confirms the whole form was saved or sent.
• Disabled or unavailable-field state with explanation and recovery path when a field cannot be edited.

Interaction Contract

• Tab order follows the same top-to-bottom order users see on screen.
• Submit validates the whole form once and reports every actionable error without clearing valid fields.
• Error summary links move users to the affected field, fieldset, or first invalid control in a group.
• Inline messages sit next to the fields they describe and match summary wording.
• Editing one field after submit does not reset unrelated fields or hide their entered values.
• A secondary cancel, reset, or back action is visually and behaviorally distinct from the primary submit.

Implementation Checklist

• Inventory the fields and remove questions that are not needed to complete the service.
• Confirm the remaining fields are related enough to scan and submit together on one page.
• Use a single-column layout unless research proves a different layout does not harm reading or keyboard order.
• Wrap related radio, checkbox, date, or grouped controls in fieldsets with legends.
• Label required and optional fields consistently before users start the form.
• Place one primary submit action after the last field and avoid disabled submit unless the disabled reason is explained.
• Implement an error summary for failed submit and preserve every entered value across client and server validation.
• Test keyboard order, screen reader group labels, zoom, mobile scrolling, validation, browser autofill, reload, and server-error recovery.

Common Generated-UI Mistakes

• Using one page for a long complex application just to avoid designing steps.
• Splitting a compact related edit task into many pages so users cannot compare values.
• Mixing unrelated tasks, such as contact details, payment, uploads, and legal acceptance, under one submit button.
• Using placeholder text instead of persistent labels inside a multi-field form.
• Showing only a generic error banner after submit.
• Clearing all values after one field fails validation.
• Reordering fields visually with CSS so keyboard and screen-reader users encounter a different sequence.
• Disabling submit or required fields without an explanation or recovery path.

Critique Questions

• Are all fields on this page related to one small task outcome?
• Do users need to compare or edit these answers together before submitting?
• Would splitting this into pages reduce error recovery, branching, or mobile effort?
• Are required and optional conventions clear before the first field?
• Does failed submit preserve all values and link each error to the exact field or group?
• Does keyboard and screen-reader order match the visual field order?