Form validation UX: help people recover without starting over

Introduce one known problem

Start with safe data that would otherwise complete the form. Change one field to a clearly invalid value under the documented rules. This isolates the recovery experience and makes the result easier to reproduce.

An illustrative event form might reject an end date that precedes its start date. Record whether the interface identifies the affected fields and makes the required relationship understandable. “Invalid input” leaves the person to infer both the cause and the correction.

W3C's forms guidance recommends understandable feedback and instructions for correcting errors. It also describes linking an error summary to the relevant control. Those are specific design aids, not proof that the entire form meets accessibility requirements. W3C user-notification guidance.

Inspect what happens to the rest of the work

After the failed submission, check the other fields and attachments. Preserve appropriate entries rather than making the person repeat unrelated work. Sensitive values may need different handling, so define that behavior explicitly instead of applying a universal persistence rule.

Pay attention to formatting changes. A form that rewrites a date or number should not leave the person unsure which value will be saved. Verify the resulting value in the saved record, not only in the field before submission.

Test the correction path

Use the feedback to locate and repair the invalid value. Then submit again. Does an obsolete error remain? Does the page move unexpectedly? Can the person reach the final action using the intended input method?

Keep the checks small and observable:

• The message identifies the actual problem.
• The suggested correction fits the accepted format or rule.
• Unrelated valid work behaves as documented.
• The corrected form can complete.
• The saved result matches the intended input.

Include a server-side failure separately

A validation error and an unavailable service are different experiences. If the server cannot complete the operation, avoid implying that the user entered something incorrectly.

Use a controlled test environment to inspect that failure. Check whether retry is understandable and whether the interface can distinguish a rejected submission from an uncertain result. Do not keep submitting real transactions to investigate the behavior.

The most useful validation report shows the whole recovery sequence. It tells the team whether the person can finish the task after a mistake, not merely whether the software can detect one.

Next step: Record the error, correction and saved result using the evidence structure in UxerProof's fictional sample report.