Live Validation
Watch someone type their email address into a form with live validation. They get as far as `o` and the field turns red. `ol` and it's still red. `olesia@` and now there's a message under the field telling them this is not a valid email address, which they know, because they haven't finished writing it.
Catch form errors at the right moment: listen now, fix your forms tomorrow.
Listen to the full Live Validation course on DesignPath
By the time they reach the end, the form has marked them wrong eleven times for typing at normal speed. They tab away, everything turns green, and nothing was ever actually wrong.
Live validation gets shipped as a best practice, and it's one of the few patterns where the well-intentioned version reliably tests worse than doing nothing. It judges work that isn't finished, it misfires on hyphenated surnames and international phone numbers, and it hands out a green tick that the server can still overrule at submit.
So the default this module argues for is late validation: check after someone has left a field and committed to an answer, not while they're still forming it.
Flipping to "never validate live" would be its own mistake, though. A password strength meter, a username availability check and a one-shot code all get better with instant feedback. There the live signal is information nobody can get any other way. Telling those apart from the rest is the actual skill.
Anatomy of a Validation Rule
Every complaint about inline validation is a complaint about one of four parts, and teams usually specify one of them.
The Four Parts
A rule is more than the condition it tests.
The condition, meaning what counts as a valid answer. The trigger, meaning what makes the check run. The verdict it returns. And the message shown when the verdict is negative. Design files carry the condition and sometimes the message. The trigger is left to whoever builds the form, which is why a field starts arguing at the fourth character of an email address.
Four Moments a Check Can Run
The trigger is a choice between four, and they are not interchangeable.
On each keystroke, while the answer is still being formed. On blur, when somebody leaves the field. On submit, when the form is sent. And after a pause, meaning a short wait once typing stops, which is the compromise most people mean when they say live validation. Choosing between them is article 4, and the point here is that a rule with no stated trigger has still chosen one.
Three Verdicts, Not Two
A check that can only say yes or no cannot describe the most awkward state.
Valid and invalid are the obvious two. The third is pending, which exists whenever the answer has to leave the browser: username availability, a discount code, an address lookup. A pending state that is not designed shows as nothing at all, and the person assumes the field is satisfied. Article 7 covers what to draw there.
Local and Remote
The last distinction decides how much can go wrong.
A local check is answerable in the browser, which makes it instant and certain. A remote check needs a server, which makes it slow, occasionally unavailable, and capable of contradicting a tick the person has already seen. Any rule that cannot be settled locally inherits the pending state, the waiting design, and the possibility of a no arriving after a yes.
Pro tip: Take one form and write the trigger next to every rule on it, in four words or fewer. The fields where nobody can say what the trigger is are the fields people complain about.