Field errors in forms: what the research recommends

The research on form errors starts from one idea: the person who hits an error is trying to finish a task, and every extra step costs attention. The NN/g archive spent years testing how a form reports a problem, and the findings are more concrete than what the average signup screen follows. The interaction design topic index collects the pieces behind this post.

When to validate while typing and when to wait

Validate inside the field whenever the tool can, and keep the message next to that field. The guideline asks for instant feedback on complex input, such as a password with rules, because the person needs to know the rule before moving on.

The same guideline tells designers not to fire validation before the person finishes the field. Marking a field wrong while the cursor is still there interrupts the flow and reports a half-typed value as a failure.

The type of field decides, not a fixed rule. Simple input waits for the person to move on, and constrained input with visible rules can answer as the person types. The archive lives with both readings and offers no tiebreaker.

Showing that an entry is correct matters too. When a field is complex, a quiet confirmation tells the person the value passed.

Label, placeholder, and white space

A placeholder inside the field isn’t a label. It disappears on the first keystroke, so the person loses the question while answering it. It also leans on short-term memory, because after typing there is no text left to check against before submitting.

The same pattern blocks people who navigate by keyboard. It also makes an empty field look less important than a filled one, because text inside the box pulls the eye. A placeholder can also read as autofill, and sometimes it forces the person to delete it by hand. A floating label keeps the label visible and fixes part of the problem, but it doesn’t fix attention or the autofill confusion. The recommended answer is a label and a hint outside the field, both always visible. The declared exception is a form with one or two very common fields, such as search or login.

White space carries a rule of its own. A label belongs closer to its own field than to the next one, which follows the law of proximity that product microcopy also respects. Grouping related fields makes a long form look shorter, because the eye reads blocks instead of a column of boxes. A label above the field scans easiest, a label to the left is a fallback when width is tight, and a label to the right fights the scan.

How to write the error message

The message has to be explicit, readable, polite, and accurate, with practical advice. Telling the person the field is empty isn’t an error message; telling the person what to type is. A correct entry also deserves an answer, so a complex field should confirm that it passed.

Color separates error from normal state, and red carries the failure in most systems. Yellow suits a warning and green or blue suits success. Color alone isn’t enough, so an icon or a small animation helps the eye find the problem in a long form.

Don’t hide the message in a tooltip. The icon goes unnoticed and the text only appears on hover or focus, which costs a step the error didn’t need. A validation summary at the top of the page can’t carry the burden alone either, since the person has to match each line back to a field.

Keep the modal for rare cases. A dialog interrupts the task and adds load, which suits a system event that demands a decision and not a single field that needs a fix.

Required markers and notification noise

An article on indicators, validations, and notifications separates three ways a screen speaks. An indicator is contextual, conditional, and passive. A validation is the error text bound to a field, and it stays until the person acts on it. A notification comes from a system event rather than the current action, and it splits into an urgent form that should interrupt and a passive form that can pass unnoticed.

The distinction matters because the same component gets opposite advice in each role. A modal is noise on a field error and the right tool for a system event that needs a decision.

A banner that appears and fades is a passive notice, and it fails as an error because the person may look away for the second it shows. If an error disappears before anyone reads it, it may as well never have shown up. That is why a loading and empty state needs a design that holds the information, not a blink.

Date fields and format

The archive lists four ways to ask for a date: a calendar, a scrolling picker on a phone, three separate menus for day, month, and year, and plain typing. The calendar suits a short range and a span between two dates. The scrolling picker struggles once the list grows. The three menus cost steps the person doesn’t need. Typing is usually the fastest path, above all for a distant date, and it should always stay available.

A good date field takes any separator and doesn’t demand a fixed format or a special character. It flags a date that can’t exist instead of guessing, and it drops options that make no sense. It keeps what the person already entered and holds the range together when one end moves.

For an international audience, the month written out or a split set of fields avoids the day and month order problem that varies by country.

Long form or stepped flow

Length alone doesn’t decide whether a form should become an application. The test is the kind of information, the number of steps, how much of the form is conditional, and whether the path is linear. A form that runs past a couple of screens often points to a task that wants an application, with its own feedback, context help, and flexible flow.

A long page can be the right answer when every field is genuinely needed. Grouping those fields into visible blocks keeps the page readable without turning it into a multistep flow. That quieter fix suits most sites.

Cut the question before styling the field

The EAS framework runs in three moves: eliminate, automate, simplify. Eliminate means dropping a question that is neither necessary nor urgent, delaying what can be asked later, and refusing to force an account before a purchase.

Automate means reusing data the system already holds and inferring an answer instead of asking for it, such as deriving a city from a postal code. It also means offering to save a value for the next visit.

Simplify means a useful default, free format that the system cleans up afterward, and the phone sensor for a photo or a spoken answer. A form that fits one field, like the single-field signup pattern, shows how far the first move can go.

The framework closes with a caution. Simplifying isn’t the same as deleting fields, because a long form is sometimes the necessary one. That point is where it meets the disagreement below.

The common mistake

The usual problem isn’t a missing rule. It is a rule used in the wrong place. Most forms borrow the strictest pattern from another context. A modal answers a field error, and a tooltip carries a hint. A placeholder sits where a label belongs, and a summary page pushes the person back to the top to hunt for the broken box.

The case of the false missile alert makes the same point from the other side. An operator chose the wrong option and confirmed it, which the article calls a “slip”, the gap between intending one action and running a similar one on autopilot. The design carried the blame, not the person: a misleading cue, an option too close to its neighbor, a poor presentation, and no confirmation before a destructive action.

That case sums up the whole topic. A form that blames the person for a design fault will keep collecting the same error, and redesign is the fix where training isn’t. Error prevention is one of the ten heuristics behind this work, and it weighs most in a system where a mistake is costly.

Where the sources disagree

When to validate: one guideline asks for feedback inside the field once the person finishes, and asks for instant feedback on a complex field like a password, while another rule forbids validating a field that is still being typed. The type of field is the practical line, and the archive doesn’t state one.
The modal: it is noise for a field error and the correct interruption for a system event that demands a decision. The same component earns opposite verdicts because the context changes.
A split date field: the date article advises against three separate menus and, on the same page, suggests separate fields for an international audience. The tension stays open.
Free format against a mask: the date article asks for any format, and the simplification framework suggests a mask that inserts the separator as the person types. Same goal, opposite mechanics.
The long form: one article treats a form past two screens as a sign that the task became an application, and another solves a long form with visual grouping alone. Break into a flow, or group on one page, and the choice depends on the task.