Helping users spot their own mistakes matters more than validation catching everything afterward

What it is

The responsibility for detecting an error can sit in one of two places: the user noticing something is wrong during the action itself, or the system catching it afterward with a validation rule and flagging it. This principle holds that the former should be designed for first, with system validation acting only as a backstop — not the other way around, where the design assumes from the start that users won't notice problems themselves and pushes all the gatekeeping onto system validation, leaving the user to passively wait for a prompt. This isn't because system validation is unreliable; it's because validation has an inherent blind spot: any rule can only catch the kind of deviation its designer thought to anticipate, while what a user perceives as "wrong" during an operation isn't bound by that same list.

Why it happens

System validation is pattern-matching against a predefined ruleset — as long as a deviation falls within a form the rule covers (a format error, a missing required field, a value out of range), it gets caught reliably. But the moment a deviation takes a shape the rule's designer never anticipated — a value that's legal in range but doesn't make logical sense, a format that's correct but semantically wrong — the validation rule is useless, and those are exactly the kinds of errors a user's grasp of the task's meaning is best placed to catch. Self-detection draws on a holistic understanding of what the task means, so its coverage is naturally broader than any predefined rule set could be. But its reliability depends on whether the action itself gives the user enough information to make that comparison — if the operation lacks perceptible feedback, self-detection's broad-coverage advantage has nothing to work with, and that's when system validation should step in to cover what it can. The two are complementary, not substitutes: system validation fills in the rule-based deviations self-detection can't reach, and self-detection fills in the semantic deviations no rule designer thought to write a check for.

Where it stops holding

Handing detection entirely to self-detection has its own limits: for consequences that are irreversible, or where users lack the expertise to judge "is this correct" on their own — a value range tied to safety or compliance, say — it's not safe to assume intuition alone will reliably catch a deviation. In these cases system validation needs to act as a mandatory final gate, not just a backstop. The self-detection-first principle applies where users have enough task knowledge and the action's feedback can genuinely be designed to be clear and perceptible; once either of those two conditions fails, the priority should shift toward system validation.

Applying it

When designing a new feature, first ask whether the action itself can, through direct feedback, let the user judge on their own whether the result is right; only after that path is solidly in place, and some rule-based, enumerable class of deviation still remains, should system validation be added to cover that residual risk. Avoid defaulting to "validation will catch it anyway" from the outset, which lets the design skip the work of providing clear feedback at the point of action. Verification: over some period, tally how many errors were caught by users themselves versus by system validation. If the overwhelming majority were caught by validation and the self-detected share is low, the action itself lacks the feedback design needed to support self-detection — the problem is being masked by validation, not actually reduced.

Related

• Same group: A10.15.1 self-detected errors cost less to correct than system-flagged ones · A10.15.2 error detection depends on a clear expected outcome · A10.15.3 the longer the gap between action and feedback, the lower the odds a user detects their own error
• Nearby: A10.06 error-proofing design · A10.08 error tolerance and graceful degradation
• Search terms: self-detection · system validation · error checking