Give hints before input, not after errors

What it is

Decision-timed pre-input guidance presents format, constraint, source, and condition information that changes how a person fills a field before they choose or compose the value, rather than disclosing it for the first time after validation fails. Pre-input does not mean permanently crowding every rule beside the field. Show only what is needed to enter a correct value in the current state, with further detail available in layers. Error messages still explain the rule actually violated, preserve input, and support recovery.

Why it happens

When a knowable rule appears only after submission, people generate a value from convention or guesswork and then pay for rejection, reinterpretation, and re-entry. Expanding every rule in advance creates the opposite problem: noise hides decisive conditions. Useful guidance responds to field state, selected country or account type, permission, and earlier answers, appearing before the corresponding condition matters; a change should itself be communicated. During-input feedback may show satisfied and unsatisfied items but cannot use color, transient animation, or a validation icon as its only carrier. Availability, limits, and eligibility known only by the server cannot truly be front-loaded and need a specific recovery path when they fail.

Studying it

Classify rules as knowable before input, knowable during input, or knowable only after submission, then test state transitions and recovery for each class. Compare persistent summaries, focus-triggered expansion, conditional disclosure, and during-input feedback on first-pass success, rule comprehension, re-entry, time, omission, and help seeking; also record whether the guidance was discovered when needed. Include keyboard, touch, zoom, screen reader, autofill, return editing, and client–server rule mismatch. An apparent timing benefit may come from clearer wording, so experiments should hold either content or timing constant.

Where it stops holding

A self-evident format that requires no decision does not need another hint, and a control that reliably constrains choice can reduce copy, although the constraint must remain perceivable. Password and security-answer fields should not reveal exploitable internal rules; show only safely disclosable constraints required for completion. When a rule depends on live external state, do not promise that valid format guarantees acceptance; separate format satisfaction from pending server validation. Guidance cannot replace errors because it may be missed, state may change, or submission may reveal a new conflict.

Applying it

• Inventory each rule with knowability time, trigger, risk, source, rule/guidance version, and recovery. Where possible, generate client guidance and validation from authoritative server rules, and use contract tests to detect drift. Show decision-changing, pre-knowable constraints before first entry; maintain during-input feedback; explain server-only conditions immediately after failure.
• Display only rules active under the current choices. When conditions change, update guidance and revalidate affected values, announcing the change programmatically to assistive technology. Preserve the original input by default rather than silently clearing it after a rule change.
• Keep guidance retrievable and programmatically associated with the field. Do not rely solely on placeholder, hover, color, or a transient toast. For many rules, use a summary plus an expandable list while keeping decisive items visible.
• After an error, preserve valid input, identify the unmet condition, and move focus to a repairable location. The server remains authoritative; when versions are unknown or disagree, retain the input, mark it pending revalidation, and explain recovery without promising acceptance. Drill conditional switches, offline state, timeout, rule-version change, and repeat submission through entry and recovery.

Related

• Same group: T2.03.1 Labels say what to fill in, hints say how · T2.03.3 Fields of unclear purpose need explanation
• Adjacent: E2.04.3 Placeholders are unsuitable for format requirements · T2.04.1 Say what happened, why, and what to do
• Search terms: proactive form hint · conditional validation · error prevention