| UI or UX | UI + UX - Anti-pattern where required form data is hidden or unreachable because conditional state and validation disagree | UI + UX - Trigger-owned follow-up form field | UI + UX - Controlling and dependent form fields | UI + UX - Form recovery summary | UI + UX - Short related multi-field submission page | UI + UX - Final editable answer summary before committing a transaction |
| UI guidance | When a trigger makes a follow-up required, keep the trigger, the revealed required field, the requirement text, and the error summary recovery path visible and connected. | Place the revealed field directly under the radio, checkbox, or select option that triggers it, visually nested enough to show ownership while keeping the label and error text fully visible. | Place the controlling field before the dependent field, label both clearly, and explain the dependency in helper text such as Choose a category first to see valid subcategories. | Render a top-of-form summary block with heading, linked error list, and matching field-level error messages. | Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. |
| UX guidance | Users should be able to tell which answers are currently required before submit, why they are required, and how to reveal or remove the requirement. | Use conditional reveal fields when a short follow-up answer is only relevant for users who choose a specific option and should remain in the same decision context. | Help the person reach a clear task outcome. | Move users from the summary to the exact field, group, or first invalid control that needs correction. | Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. |
| Good UI | A benefits form asks whether the user needs an accommodation; selecting Yes reveals a required Accommodation details field directly below the trigger with helper text and validation. | A Contact me by email checkbox reveals an Email address field immediately below that checkbox and hides it when Email is unchecked. | An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed. | Top-of-form summary with a clear heading, linked error list, and matching inline field messages. | A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. |
| Bad UI | Submit fails with Enter accommodation details, but the accommodation field is hidden because the branch is collapsed and the trigger is off-screen. | Selecting Other reveals a long nested form with its own Save button and unrelated questions. | A stale dependent value is submitted with a new controlling value. | Summary and field messages visually disconnected or contradictory. | A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page. | Change links lack context, so assistive technology users hear a list of identical Change links. |
| Good UX | A user returns from review after changing an upstream answer and is asked the newly required question before final submit. | A user selects Phone, sees the Phone number field appear under Phone, enters the number, then unchecks Phone and sees the number excluded from submission. | A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting. | After failed submit, focus or reading order makes the summary discoverable before users scan the form. | A user reviews all contact details before submitting because the fields are short, related, and visible in one scan. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. |
| Bad UX | Submit fails because a required field is hidden. | Hidden required fields block submission. | A stale dependent value is submitted with a new controlling value. | Only showing errors below the fold. | A validation failure clears completed fields, forcing the user to re-enter unrelated information. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. |
| Best fit | Use it during design and QA reviews of eligibility, account, checkout, consent, benefits, healthcare, enterprise configuration, and onboarding forms with conditional branches. | A selected radio, checkbox, or select option needs one short related follow-up field. | A downstream field's valid values or requirement depend on a previous answer. | Form submission can produce one or more errors. | A compact set of related fields should be reviewed together before one submit. | A user has provided multiple answers and should verify them before a consequential submit action. |
| Avoid when | Choose another interaction when the task calls for a different route. | The revealed content is a complete form, separate workflow, or separate submit action. | The choices are independent and users need to compare them together. | The message is a system failure, permission problem, or outage rather than a validation issue. | The form is long, high-stakes, branched, or too hard to recover from on one page. | The task is a single low-risk field with clear inline validation and an obvious submit action. |
| Required state | Initial state with all currently required fields identified before users submit. | Trigger selected state with the related follow-up field revealed directly under the trigger. | Controlling answer selected, with dependent options filtered to the valid subset. | Failed-submit state with summary visible near the form heading. | Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. |
| Accessibility burden | Newly required conditional fields must be placed after the trigger in DOM order or announced through tested status behavior. | Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally. | Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship. | Use a heading and alert behavior that makes the summary discoverable. | Keep field order in the DOM the same as the visible order. | Use headings that make the review task explicit, such as Check your answers before sending your application. |
| Common misuse | Keeping a visually hidden input required because the backend schema says the field is required in some cases. | Hiding a required field and still validating it after its trigger is unselected. | Leaving a stale dependent value selected after the controlling field changes. | Replacing field-level messages with only a top-level summary. | Using one page for a long complex application just to avoid designing steps. | Labelling the final commit button Continue. |