The Form That Validates Too Late
A 40-field intake form is built as a single interface with a flat layout. Users complain about three things: (a) they only learn a required field is missing when they hit Submit, and the error appears at the top while the offending field is far down the page; (b) a section of 12 fields is only relevant when "Request type = Exception," but it is always visible and always validated, so users fill in nonsense to get past it; (c) on mobile, the form is unusable - fields are tiny and the submit button is unreachable without extensive scrolling. The business also wants to save partial progress so users can return later.
1. How would you restructure validation and conditional visibility?
Read the worked answer
The complaints are three faces of one problem: the form does not model its own dependencies.
Conditional section (b). Visibility and validation must be driven by the same condition. Put the 12 exception fields in a section whose showWhen is ri!request.requestType = "EXCEPTION", and - critically - ensure the fields are not required and not validated when hidden. A hidden field that still validates is the single most common cause of "users type garbage to proceed." Also decide what happens to values already entered if the user switches type back to non-exception: either clear them or preserve-but-ignore, and be explicit. Silently submitting stale hidden values is a data-quality bug.
Validation timing (a). Move validation to the field level where possible: validate on blur for format (email, phone) and mark required fields visibly (asterisk plus a legend) so the requirement is known before submission. Keep a submit-time validation pass as a backstop, but on failure scroll/focus to the first invalid field and show the message inline at the field, not only in a summary at the top. A top summary is fine as an addition for screen-reader users; it is not a substitute for inline errors.
Why: late validation forces a round trip of user attention. Inline, condition-aware validation prevents the error instead of reporting it.
2. Address the mobile layout and partial-save requirement.
Read the worked answer
Mobile (c). A 40-field flat form is wrong on any device; on mobile it is fatal. Restructure into logical sections/steps (e.g. Requester, Details, Exception details, Attachments) using a wizard or collapsible sections, so the page is short and the primary action is always reachable. Use a responsive layout: single column on narrow widths, side-by-side on wide. Do not shrink fields to fit - that is the current failure. The submit/next action should be persistently visible (sticky footer) rather than at the end of a long scroll.
Partial save. Model this as data, not as a UI trick:
- Persist a draft record (with a status of Draft) on each step completion, or on an explicit "Save and exit."
- On return, reload the draft and resume at the right step.
- Decide the retention/cleanup policy for abandoned drafts (e.g. purge after 30 days) - otherwise the table fills with orphans.
- Security: drafts contain the same sensitive data as submitted records, so they need the same row-level security. A common mistake is to leave drafts world-readable because "they're not real records yet."
The through-line: both fixes replace a single monolithic screen with a stateful, sectioned flow backed by persisted data - the interface reflects the process, rather than pretending the process is one page.