Prevent errors

What it is

"Prevent errors," one of Shneiderman's golden rules, ranks above writing an elegant error message: first eliminate illegal choices, conflicting states, and ambiguous actions, then handle whatever risk remains with immediate cues, confirmation, delay, and recovery. It is judged by whether errors occur less often, not by how polished the message looks.

Why it happens

Errors typically arise from execution slips, misunderstood rules, look-alike interfaces, defaults, and irreversible commitments made too easily. Prevention's value is that it shifts the problem from "detect and recover" to "constrain at input time" — and detect-and-recover cost keeps rising the later an error is caught. An illegal value blocked right at the input field costs almost nothing; the same value discovered only after it has flowed downstream, triggered a notification, or affected someone else requires rollback, compensation, and explanation, at orders of magnitude more cost. Design can change the choice set at the source: allow only legal values, auto-format, disable conflicting options, isolate dangerous zones, show scope of impact, save drafts. Errors of understanding need explained rules and consequences; slips of execution need spacing, sequencing, and undo — these two failure types have different causes, and one prevention technique usually only helps one of them.

Where it stops holding

Prevention can tip into over-constraint, and the constraint itself then manufactures new errors. If a reconciliation tool rigidly enforces "invoice before payment" as the only valid order, users who genuinely work with advance payments will fabricate a placeholder invoice just to get past the constraint. The constraint has not eliminated an error — it has swapped "wrong payment order" for "falsified invoice data," which is usually harder to detect. Legitimate exceptions, expert efficiency, and assistive input all need an escape hatch; too many prompts also train users to click through mechanically rather than actually read them. Errors caused by upstream data or organisational rules still need a process fix — the interface can only reduce exposure, it cannot solve an organisation's structural problem.

Applying it

• Work backward from high-frequency errors to design conditions, preferring legal options, defaults, templates, and constraints over adding one more warning message.
• Distinguish slips of execution from errors of understanding, and use layout, read-back, preview, and dry-run for the former and explanation for the latter — they are different remedies.
• Show the affected count, consequence, irreversibility, and alternatives for high-risk actions.
• Track error rate, fix time, workaround behaviour, and new error types after launch — workaround behaviour usually means some constraint is blocking a legitimate case, which calls for revisiting the constraint itself rather than tightening it further.

Related

• Same group: B3.11.1 Strive for consistency · B3.11.2 Provide universal usability · B3.11.3 Offer informative feedback · B3.11.4 Design dialogs to yield closure · B3.11.6 Permit easy reversal of actions · B3.11.7 Keep users in control · B3.11.8 Reduce short-term memory load
• Nearby: B3.05 Error Prevention · Y3 Error Prevention and Recovery
• Search terms: error prevention · golden rules · poka-yoke