Error Prevention
The same preventable errors keep appearing. Wrong data submitted. Actions triggered by accident. Settings changed without warning. The system allows what it could prevent. It accepts invalid inputs and lets irreversible actions happen without confirmation. Nothing in the system intervenes before the damage is done.
Definition
Inputs reach the system without passing through constraints. Actions complete without surfacing their consequences. The system accepts whatever it receives — valid or invalid, reversible or permanent, safe or risky.
Nothing in the flow distinguishes a routine action from a costly one. A settings change and a mass deletion require the same effort. The system does not slow down where damage is more likely.
Problems surface only after actions complete. The cost — corrupted data, lost records, broken states — is created before anyone has a chance to notice. Recovery happens outside the moment where prevention was possible.
Business Impact
Risk
Increases risk because the system allows high-impact actions to execute without distinguishing them from routine ones.
Team scalability
Limits team scalability because the system does not enforce constraints, leaving error prevention dependent on individual judgment.
Operational cost
Raises operational cost because the system creates preventable errors that must be resolved afterward through recovery and manual correction.
Example
Email type validation
Deel
System decision: The system distinguishes valid and invalid email input before submission, instead of allowing the action to complete and surfacing errors later.
What was chosen: An inline validation message — "Please use a company email address" — appears directly under the input as soon as the format is invalid.
What was avoided: Accepting any email format and surfacing the problem only after the referral is already sent.
Complexity removed: Errors are corrected at the moment of entry, before they propagate into downstream actions or require recovery later.
Irreversible action confirmation
Contractbook
System decision: The system requires deliberate confirmation of intent before executing an irreversible action, instead of treating it the same as a routine one.
What was chosen: A confirmation dialog with "This action cannot be undone" and a required text input — typing "MERGE" — before the action can be executed.
What was avoided: A single confirmation click that treats an irreversible action the same as a reversible one.
Complexity removed: Users cannot trigger an irreversible action by accident, because the system requires deliberate input before proceeding.
Bringing System Clarity
Audit
Most preventable errors pass as normal actions with costly outcomes — wrong data submitted, irreversible deletions, misconfigured settings.
The system functions without signaling the difference between safe and risky paths.
This shows up when:
the same preventable error appears repeatedly in different contexts
support tickets describe outcomes that could have been stopped at input
recovery processes compensate for errors the system still allows
users develop workarounds to protect themselves from the interface
consequences are discovered only after actions complete
risk depends on user caution, not system behavior
A useful boundary: If avoiding mistakes depends on user caution rather than system constraints, prevention is not enforced by the system.
System Rules
Some actions carry more weight than others. The system either reflects that difference — or allows all actions to proceed under the same conditions.
What typically breaks:
which actions are treated as routine despite carrying irreversible consequences
where invalid inputs are accepted without constraint
where confirmation is missing before costly actions
where consequences are not surfaced before execution
where permanent cost is created without distinction
A useful boundary: If the system treats safe and risky actions the same, prevention is not part of the system.
Decision ownership
When actions differ in impact but are treated the same, decisions about safeguards stop being local. The system does not carry risk, so the team must interpret it case by case.
When risk is consistently constrained by the system, decisions stay local. The team applies existing safeguards instead of deciding whether protection is needed.
Questions that help maintain clarity:
Does this action introduce impact that is not yet constrained?
Would the system prevent this if triggered unintentionally?
Is the cost of a mistake absorbed by the system or passed to recovery?
Escalation is needed when a new type of risk appears — one that existing constraints do not define or prevent.
A useful boundary: If the team has to decide whether something is “safe enough,” prevention is no longer owned by the system.
Common Decision Patterns
Decisions about safeguards often appear as small requests to reduce friction:
"Should we skip the confirmation here?"
“Should we allow this without validation?”
“Should we remove this warning?”
“Should we make this faster by removing the extra step?”
Each of these removes a point where the system prevents damage.
In practice, protection erodes:
confirmation is removed because “users click through anyway”
validation is loosened to reduce complaints
warnings are hidden because they “feel excessive”
irreversible actions are simplified for speed
The question to ask:
“What happens if this is triggered by mistake?”
If the answer depends on recovery, cleanup, or explanation, the system is allowing damage instead of preventing it.
Conclusion
Prevention failures rarely announce themselves. Actions complete as expected. The cost shows up in repetition — and in effort spent on recovery instead of progress.
When the system doesn't stop what it could prevent, caution becomes a requirement. Every consequential action carries risk that lives with the person, not the interface. Work slows down not because tasks are hard, but because nothing protects against getting them wrong.
Those costs show up where the system allows damage it could have stopped — across trust, time, and escalation.
Recognize this in your product?
Let's talk about what's behind it.