Designing complex forms with conditional fields, drafts and useful validation

Map dependencies before drawing pages

For every field, identify who supplies it, when it is required, where its value comes from and which other fields it affects. Selecting external purchasing might reveal supplier information; choosing an existing supplier might reuse an approved record. Those relationships determine the presentation order and what remains valid after the user changes an earlier answer. A hidden field must not silently continue to influence submission.

In a hypothetical equipment request, a user selects “new equipment,” enters details and then changes the request to “replace existing equipment.” The specification must state whether previous values are cleared, retained temporarily or presented for confirmation. The server must validate the current branch. Invisible input must not overwrite a live asset record simply because it remains in the form state.

Choose steps according to the work

A multi-step form is useful when information falls into distinct stages, takes substantial time to collect or must be completed across interruptions. A grouped single page can be more efficient when users repeatedly compare fields or transcribe one document. The number of steps is not a measure of simplicity. Each step needs a stable name and a predictable way to go back.

Before moving forward, validate what is necessary for that transition. Do not report errors in questions the user has not reached. Before final submission, provide a reviewable summary. Its change links should lead to the relevant field and return to the review position afterwards, rather than forcing the user to restart the complete journey.

Define drafts as a real business state

• Draft: explain what was saved, when, who can continue and whether attachments were included.
• Information required: identify missing material without suggesting that approval has already begun.
• Submitted: show a business identifier and the next state; another click must not be treated as a fresh application.
• Outcome unknown: after a timeout, offer a way to check the result before encouraging another submission.

Local browser storage is different from a server-side draft. Specify whether users can continue on another device, recover after session expiry or edit collaboratively. These are implementation decisions that need verification. Drawing a saved indicator does not establish that any of them work.

Make an error point to the next useful action

The GOV.UK error-message guidance distinguishes input problems users can correct from problems with the service itself. A business form can apply that distinction without adopting government visual styling. A missing date should identify the date to supply. An unavailable service should preserve input and explain the recovery route rather than marking an otherwise valid field as wrong.

For a long form, an error list near the start can link to each affected field, while a local explanation remains beside the field. “Invalid format” rarely provides enough direction. State the permitted format, range or source that needs checking. Correct entries should not disappear because a different field failed validation.

Test conditions and recovery together

1. Complete each branch, then change to another branch before submission. Confirm that hidden values do not participate incorrectly.
2. Save an incomplete draft, leave and return through an allowed device. Compare both text and attachments.
3. Trigger an input error and a service failure separately. Their explanations should differ, and completed input should remain available.
4. Use the keyboard to move from the error list to a field and back to the review summary.
5. Simulate session expiry and a submission timeout. Check the actual result-query or sign-in path, not just the appearance of a message.

The server remains responsible for final rules concerning amounts, permissions and required information. Design defines the journey and feedback; integration testing establishes whether the record was saved, an unauthorized action was blocked or a duplicate was prevented. If business rules are still disputed, resolve a branch-rule table before commissioning every screen. This avoids turning a business-policy disagreement into repeated visual revisions.

The next useful input is a requirements document describing required fields, allowed draft states and what survives a failed save. Turn those decisions into a developable prototype covering entry, correction and submission. When briefing UI design services (Chinese), include representative errors and incomplete records, rather than supplying only a screenshot of an empty form.