Dr.-Ing. Marcus JenkeSenior Human Factors Engineer | Managing Partner
Last updated: October 2026
Short definition

Error tolerance (German: Fehlertoleranz) describes the property of a user interface to prevent use errors, catch them immediately, or limit their consequences. It is among the most effective risk reduction measures in usability engineering because it works independently of the user's care and attention, unlike warnings or training.

Placement in the safety hierarchy

In risk management, a fixed order of priority applies to risk control: First comes inherently safe design, which makes an error impossible from the outset. Second come protective measures, which allow an error but limit or intercept its effect. Error tolerance comprises measures of both levels: Error prevention through design is inherently safe design; error detection and error recovery are protective measures. Only third and last comes information for safety, such as warnings and training.

This order of priority is not an arbitrary ranking but reflects empirical effectiveness: Warnings and training presuppose that a user remembers and follows them at the decisive moment, an assumption that often does not hold under time pressure, routine, or high cognitive load. Error tolerance, by contrast, works regardless of whether the user is attentive at that moment.

Three levels of error tolerance

Error-tolerant design can be divided into three levels of effect over time, each requiring different design means:

  • Error prevention: the error is not even possible, for example through physical forcing functions or plausibility checks that prevent a nonsensical entry from the outset.
  • Error detection: an error that has already been made is reported back to the user immediately, before it takes effect, for example through a confirmation prompt before a critical action.
  • Error recovery: the consequences of an error are limited or reversed, for example through an undo function or an automatic safety shutdown.

These three levels do not exclude one another but ideally work in layers: Where error prevention is not fully possible technically, error detection should take effect; where that also fails, error recovery should at least limit the consequence.

Concrete design mechanisms

  • Physical coding: different connector shapes or port geometries that mechanically rule out a wrong connection.
  • Plausibility checks: the system rejects entries that lie outside a meaningful range of values instead of accepting them without comment.
  • Confirmation dialogs: an additional confirmation is required before irreversible or safety-relevant actions, used selectively and not excessively, since too many confirmations lead to reflexive click-through.
  • Reversible actions: settings can be corrected without consequence within a defined time window.
  • Safe default and idle states: after an interruption or malfunction, a device returns to a state that cannot cause harm.
  • Redundant confirmation of critical values: for example, separate entry and display of a therapy parameter before it is activated.

Trade-off: error tolerance versus operating effort

Error tolerance is not an end in itself to be increased at will. Too many confirmation dialogs, overly strict plausibility checks, or constant queries increase cognitive load and paradoxically lead to new errors: Users develop reflexive confirmation patterns that undermine exactly the protective effect the measure was meant to achieve.

The right calibration results from the use-related risk analysis: Error-tolerant measures should be concentrated where an error could actually lead to serious harm, in critical tasks, while routine actions without consequences should not be burdened with unnecessary safeguards.

Where error tolerance matters most

Error tolerance is most effective where the three least favorable conditions coincide: high severity of harm, a low probability that the user will detect the error in time, and a context of use with increased error susceptibility, such as emergency use under time pressure or operation by users with little practice.

For exactly these cases, the combination of error prevention and error detection delivers the greatest safety gain because it does not depend on the user's attention at the decisive moment. Error recovery alone after the fact is insufficient where the harm has already occurred before a correction becomes possible.

Regulatory reference

According to ISO 14971, inherently safe design and protective measures, which include error tolerance, are to be considered and implemented with priority over information for safety. This order of priority is a central principle of risk management and directly affects the assessment of risk control measures in the use-related risk analysis within the usability engineering process according to IEC 62366-1.

As a design principle, error tolerance is also anchored in ergonomics standardization: ISO 9241-110 introduced it in the 2006 edition as a principle of dialogue design; in the 2020 edition, the interaction principle is called "user error robustness."

If a use error is addressed solely by a warning rather than by error-tolerant design, although the latter would be technically possible, this must be justified in the risk analysis. Notified bodies (the independent conformity assessment organizations under the EU MDR) and the FDA expect a traceable justification when risks are controlled predominantly through information rather than through design or protective measures. The MDR also requires a corresponding order of priority in Annex I: Risks are to be reduced first through safe design, then through protective measures, and only afterward through information for users.

In brief

Error tolerance prevents, detects, or limits use errors independently of the user's attention and is therefore more effective than warnings or training, which depend on exactly that. In the safety hierarchy of risk management, it belongs to the first two levels, inherently safe design and protective measures, and thus ranks ahead of information for safety.

It should be concentrated where it counts: in critical tasks with high severity of harm, not across the board for every operating action.

Frequently asked questions (FAQ)

Is error tolerance the same as fail-safe design?

No. Fail-safe design describes systems that automatically enter a safe state when an error occurs. Error tolerance is broader and additionally includes measures for error prevention, error detection, and error correction.

Is error tolerance the same as a warning?

No, quite the opposite. Error tolerance belongs to inherently safe design and protective measures and works independently of the user's attention. A warning belongs to information for safety and ranks last, and weakest, in the order of priority of risk control because it depends on care at the decisive moment.

Can too much error tolerance be harmful?

Yes. Too many confirmation dialogs or overly strict checks increase cognitive load and lead to reflexive click-through that undermines the actual protective effect. Error-tolerant measures should be used selectively for critical tasks, not across the board everywhere.

Which level of error tolerance is most important?

There is no general ranking among error prevention, detection, and recovery; ideally they work in layers. For critical tasks with high severity of harm, error prevention and detection are particularly important because recovery alone after the fact may come too late.

Does every error-tolerant measure have to be documented in the use-related risk analysis?

Yes, especially if it serves as a risk control measure for an identified use error. Its effectiveness is checked in formative evaluations and demonstrated with objective evidence in the summative evaluation. A measure that is planned but untested does not count as demonstrated from a regulatory perspective.

Do you want to prevent use errors through design instead of compensating for them with warnings? We identify where error-tolerant measures bring the greatest safety gain.

More about our usability engineering

Sources

Related terms

← Back to the wiki overview