| 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 | Do not let a required answer be hidden, visually collapsed, disabled, off-screen, or absent from the current branch while validation still blocks submission. | 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. | Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules. | Help users recover from one or more submitted-form errors without scanning the entire page. | 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. | A hidden required email field blocks submit after Email was unchecked, but no visible field explains the error. | A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it. | Red banner saying fix errors with no links. | A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links. |
| Good UX | A user changes Yes to No and the required follow-up is cleared, excluded from validation, and removed from the review page. | 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 edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once. | 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 | A user repeatedly presses Submit because the only missing required field lives in a hidden branch with no link or visible trigger state. | A user changes from Email to No contact and the hidden email address still gets sent. | A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared. | Only showing errors below the fold. | A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. |
| Best fit | Use this anti-pattern entry to audit forms where conditional logic, validation, saved drafts, or server schemas might require fields that are not visible or reachable. | 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 | Do not use this entry to reject simple conditional reveal fields that visibly reveal and validate a related follow-up only while its trigger is active. | The revealed content is a complete form, separate workflow, or separate submit action. | The choices are independent and users need to compare them together. | A single local field issue can be corrected before submit without page-level orientation. | 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. | Initial state with trigger options visible and no conditional field shown. | No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text. | Neutral form before submit with no summary. | 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. | Showing a red banner or toast with no links to the invalid answers. | Using one page for a long complex application just to avoid designing steps. | Using a review page that contains no captured answers. |