A form can look polished until somebody leaves one field blank, enters a date in the wrong format or loses their connection while pressing Submit. The quality of the error message then decides whether they recover quickly or give up.
Useful error messages explain what happened in language the person recognises. They point to the right place, say what can be done next and avoid blaming the user. This matters on a simple enquiry form, but it matters even more in a booking route, customer portal or internal business tool where somebody may already have entered a lot of information.
Write for the next action
Messages such as “Invalid input”, “Submission failed” and “Something went wrong” describe the system’s mood rather than the person’s problem. They leave the reader to work out which field caused the error and what a valid answer looks like.
Start with the correction. “Enter your postcode” is useful when the field is empty. “Postcode must include the space” explains a formatting problem. “Choose an end date after the start date” gives the person a boundary they can act on.
The GOV.UK Design System guidance on error messages recommends explaining what went wrong and how to fix it. It also advises using language from the question or field label, which helps people connect the message to the right part of the form.
Make each message specific to the problem
A required field, an answer that is too long and an unsupported file type are different problems. Giving all three the same message saves writing time during development, but passes the effort to every person who uses the form.
Prepare messages for the cases the form can detect. For a document upload, that might include an empty field, a file that is too large and a format the system cannot accept. State the actual limit or accepted formats where that information helps somebody correct the problem.
Keep the wording steady across the product. If one screen asks people to “Choose a file”, another should not switch to “Attach documentation” without a reason. Repeated labels and phrases reduce the amount of interpretation needed.
Put the explanation where people will find it
Place a field-level message close to the field it describes. Colour can draw attention, but the words and their connection to the field still need to work without colour. For a longer form, add a summary near the top so the person knows how many problems need attention and can move to each one.
The W3C Web Accessibility Initiative tutorial on form notifications advises making errors concise, easy to understand and clear about how to resolve them. It also describes linking items in an error list to the corresponding controls. That saves people from hunting through the whole page.
After a dynamic change, such as validation that happens without loading a new page, the interface also needs to announce the update to people using assistive technology. That is an implementation job for the build, rather than something the wording can solve by itself.
Keep the information that was already correct
Do not empty the whole form because one answer failed validation. Keep the entries that passed and leave the incorrect answer visible where it is safe to do so. The person can then compare their answer with the message and make a small correction instead of starting again.
This needs extra care around passwords, payment details and other sensitive information. The design and development team should decide which values can be retained, which must be cleared and how that behaviour will be explained.
Separate input errors from service problems
An error message beside a field makes sense when the person can correct the answer. It is the wrong treatment when the booking service is unavailable, a payment provider times out or the user does not have permission to continue.
For a service problem, explain the current state and provide a realistic next step. That might mean trying again later, saving progress or contacting support. Only offer a route that the business can actually maintain. A phone number that nobody answers creates a second failure rather than fixing the first.
Test the awkward cases before launch
Error states often receive less attention than the successful route. Include them in the content and testing plan from the start. Try the form with missing answers, unexpected formats, large uploads, repeated submissions and a lost connection. Check what happens to the information already entered.
Read every message aloud. Ask somebody who did not write the form to follow it without extra explanation. If they cannot tell what to change, the message is not finished.
Mighty Digital Studio plans clear enquiry routes as part of its WordPress website work, and can take portals and internal tools through planning, development and support as part of a custom app project. Bringing error states into those early conversations gives the finished tool a better chance of helping people complete the job.