Form validation that helps people finish the task
Plan field rules, useful error messages, retained answers, and honest success states for enquiry and operational forms.
A form is a conversation about what someone needs to provide and what will happen next. Validation should help them complete that conversation. Define the information the business actually needs, explain unfamiliar requirements before an error occurs, and preserve the person’s effort when a save or submission fails.
Ask for the smallest useful set of answers
Connect every required field to a decision or follow-up action. A preliminary enquiry may need a project description but not a full postal address. Label optional questions openly. If a field has an unusual format, show an example near the field rather than relying on an unexplained rejection after submission.
Use appropriate HTML input types and constraints for straightforward checks. Browser validation can guide users, while the receiving system still needs its own validation because requests can bypass the interface. Keep the rules aligned so a value accepted on the screen is not predictably rejected at the next step.
Write errors that explain a repair
Tell the person which answer needs attention and how to correct it. “Choose a preferred date from the available options” is more useful than “Invalid input.” Distinguish a missing answer from an unavailable service. The customer cannot fix a disconnected email provider by repeatedly changing a valid address.
Keep labels visible, associate instructions with their fields, and make errors discoverable without relying on colour alone. When several answers need attention, provide a clear starting point and retain all valid entries. Review the experience with keyboard navigation and with someone who has not seen the form before.
Treat submitting, saved, and delivered as different states
Prevent accidental duplicate submission while a request is pending, but provide recovery if it fails. Preserve the values and explain whether the person can retry safely. Avoid clearing the form before the receiving service has accepted the request. A spinner with no explanation creates uncertainty about whether anything happened.
Choose success wording that matches the actual operation. A saved draft is not an enquiry sent to a business; an accepted consultation request is not a reserved appointment. Test the state after rejection, interruption, and retry as carefully as the successful path. The final message should tell the person what to do next.
Practical checklist
- Explain required and optional fields before submission.
- Preserve names, punctuation, and valid email address variants.
- Retain answers after a rejected request.
- Make errors identifiable beyond colour changes.
- Match success text to the operation that actually completed.
Example: a project enquiry failure
A hypothetical design enquiry contains a name, business, and project description. If the delivery service rejects it, the form keeps those answers, restores its submit control, and offers a clear retry or contact alternative. It does not show a thank-you message that implies the business received the enquiry.
Common questions
Should errors appear while someone is still typing?
Use judgement. Guidance can help during entry, but interrupting an unfinished answer with repeated errors is distracting. Review timing with realistic typing and correction tasks.
Can one generic error message handle every failure?
It can be a safe fallback, but distinguish recoverable field problems from service failures wherever possible. Each situation asks the person to take a different next step.
Further reading
Start with your actual workflow.
Turn the useful parts of this guide into a focused project brief.
Shape your project