Blocking the illegal state beats explaining it later
Aliases: error prevention · poka-yoke · forcing function · constrained input
What it is
Preventing the illegal state means the flow never lets a forbidden combination be chosen, submitted, or assembled: a date picker instead of free text, exclusive options as a radio, an out-of-stock variant that cannot be tapped. That comes before a later alert that the format was wrong. This entry is about the set of legal states on the path. It is not about how to write the alert, and not about shrinking damage after the fact.
Why it happens
Skill-based action barely reads a message that arrives after the fact. People compile “fill, then submit” into one motor sequence; illegal input is translated into red text only after the sequence ends, when working memory no longer holds why that value was typed. Constraints remove the illegal combination from the choice set, so the error has nowhere to occur and the message has no job. A forcing function spends its cost before the act: the value cannot be selected, the combination cannot be built, submit stays closed. That saves a whole diagnosis round compared with “do it wrong, then learn the rule.” Messages still cover what constraints cannot reach, but treating messaging as the main strategy is an admission that the flow allows a dead end.
Studying it
Compare a free-text-plus-post-submit-error path with a control that only exposes legal values, holding the task goal constant.
Independent variables: free text versus enumeration, whether illegal combinations are clickable, whether submit activates on an illegal state. Dependent variables: first-submit success, visits to an error surface, correction rounds, time to complete, repeat violations of the same rule.
Lab participants know the rule will be tested and over-read the message; product logs where the same format error recurs are closer to life. A clearer error string raising success is not prevention success—diagnosis improved, the illegal state was still produced.
Where it stops holding
When the legal set cannot be enumerated in advance (search, notes, open questions), the possibility cannot be designed out and the work shifts to shrinking consequences. Exception paths that experts need, if permanently closed, get bypassed or stuffed into the wrong field. Over-constraint creates new failures: a date picker that forbids “yesterday” breaks backfill. For assistive technology, a disabled control must say why it is unavailable, or a screen-reader user only hears a row of silent grey buttons.
Applying it
- List high-frequency errors by field and ask, for each, whether a choice, range, template, or conversion can replace the message.
- Keep mutually exclusive, expired, out-of-stock, and unauthorized options from advancing a step; close them here, rather than letting people walk into a wall.
- Leave submit inert on the current illegal combination, with one task-language sentence naming what is missing—do not wait for a full-page error after the click.
- Verify from a week of error logs: the share of codes a control could have eliminated. After the control change, that code should nearly vanish, not merely sound nicer.