Insights · Getting forms right · 5 minutes
Error Messages That Actually Help
A form's error messages are the only conversation it ever has. What a useful error says, where it belongs on the page, when it should speak up, and who has to be able to perceive it.
'Invalid input' is a shrug, not a message
Somewhere in your form's code, a check just ran. It knows which field failed, which rule it broke, and usually what the visitor probably meant. Then the form turns to the visitor and summarizes all of that knowledge as 'Invalid input.' Or a red border with no words at all. Or — the classic — 'An error occurred.'
The visitor is left running the diagnosis themselves: rereading each field, guessing at unstated rules, maybe discovering by trial and error that the phone field secretly rejects parentheses. Every round of that guessing game costs you a percentage of the people playing it. And the people who give up don't file a complaint about your validation — they just leave, and the form's analytics record another abandoned submission with no explanation attached.
The frustrating part is that error copy is close to free. It's not an engineering project; it's a writing task the engineering already made possible. The form knows the answer. Someone just has to decide it's worth saying.
A useful error answers three questions
Which field. What's wrong. What right looks like. 'Phone number: this needs an area code — like 555-012-3456.' Anything that answers all three lets the visitor fix the mistake in one move, which is the entire job. Anything that answers fewer than three is delegating the missing part to the visitor's patience.
Tone does real work here too. The visitor made a mistake on your form, which is different from having done something wrong. 'Please enter a valid email address' reads like a citation; 'We need an email like [email protected] to reply to you' explains itself and gives a reason to comply. The best error messages barely register as errors — they read like a colleague pointing at the line that needs another look.
There's also a category of error that isn't the visitor's fault at all: the server failed, the connection dropped, something on your side broke. Those messages need the opposite emphasis — 'Something went wrong on our end; your message is still here, please try again' — because the worst thing a form can do is phrase its own failure as the visitor's.
Put the error where the eyes already are
An error message displayed far from its field is a scavenger hunt. The natural home for each message is directly beside the input it's about — the visitor's eyes are already there, and the fix is a hand's width from the explanation. A red banner at the top of the page that says 'there were 3 errors' while the errors themselves hide below the fold manages to be alarming and unhelpful at the same time.
Long forms earn a second layer: a summary at the top listing each problem, with each item linking straight to its field. That's not a contradiction of the beside-the-field rule — it's in addition to it, and it exists mostly for the situation where a visitor submits from the bottom of a long page and the failures are scattered above. Focus should land on that summary when it appears, so the visitor's next action is reading it, not hunting for it.
And under all of it, the rule from earlier in this series still governs: an error must never cost the visitor their work. A form that answers a typo in the phone field by clearing the message field has punished the wrong crime.
When to speak up
Timing is its own decision. A form that validates on every keystroke is scolding people for sentences they haven't finished — the email address is 'invalid' for the entire time it's being typed, which is both technically true and completely useless. The visitor's half-formed answer isn't wrong yet; it's in progress.
The calm pattern checks when the visitor leaves a field — the moment their answer is supposed to be complete — and again at submit, which catches anything skipped. And once a field has been marked wrong, the courtesy inverts: now revalidate as they type, so the error evaporates the instant the fix lands rather than lingering until the next submit. Slow to accuse, quick to forgive.
Errors everyone can perceive
A meaningful share of visitors will never see your red. Color-blind visitors may see the error border as just another border; screen reader users don't see it at all. Color can emphasize an error, but it can't be the error — every failure needs words, attached to the field in the markup, so assistive technology announces the problem when the field is focused. An error that only exists as a hue is, for part of your audience, an error that doesn't exist.
This lands hardest on the audience this series keeps in view: public institutions, whose forms are often the legally mandated way to reach a service and whose accessibility obligations are not aspirational. But the compliance framing undersells it. The visitor who most needs the error message to be explicit — older, less confident online, using borrowed technology, second language — is disproportionately the visitor public-sector forms exist to serve.
Next in this series, the same care moves to smaller screens: tap targets and mobile keyboards, and why the phone in your visitor's hand is the strictest reviewer your form will ever face.