Skip to main content

Error-Proneness

Adapted from the Cognitive Dimensions of Notations framework (Green & Petre, 1996; Blackwell & Green, 2003). See About the Dimensions for framework references.

Error-Proneness is the extent to which a system invites mistakes and how much protection it provides against them. In complex professional software, errors can range from trivial slip-ups to catastrophic cascading failures that corrupt an entire project. What makes this dimension particularly important in non-linear workflows is that the consequences of an error may not become apparent until much later, long after the user has moved on to other tasks.

There is a useful distinction between slips (the right intention, wrong action — clicking the wrong button, selecting the wrong item) and mistakes (wrong intention altogether — misunderstanding what an operation does). Complex software is vulnerable to both, but mistakes are especially dangerous because they are harder to detect. A user who applies a filter to the wrong layer in a compositing application has made a slip; a user who doesn't understand that "baking" a simulation makes it non-editable has made a mistake born of insufficient system communication.

Error-Proneness interacts strongly with Invisible Links and Visibility. When dependencies between elements are hidden, users cannot foresee the consequences of their actions. When feedback is unclear or delayed, errors go undetected.1 The most dangerous errors are silent ones — operations that appear to succeed but produce subtly wrong results. In data analysis tools, a misconfigured filter may silently exclude critical records. In 3D animation, a keyframe set on the wrong property produces incorrect motion that may only be noticed during a final render.

Prevention Patterns​

Good error-prone design acknowledges that errors will happen and focuses on three strategies:

  1. Prevention: Constraint systems that make invalid states impossible (e.g., snapping guides that activate based on geometric relationships, type systems that prevent incompatible connections in node graphs).
  2. Detection: Visual guards and indicators that surface errors early (e.g., red highlighting on invalid values, warning icons in the scene hierarchy, real-time validation feedback).
  3. Recovery: Granular undo, non-destructive workflows, and checkpointing that allow users to reverse errors without losing unrelated work.

The "Ghost Geometry" Pattern​

Some 3D and design tools show a preview of the result before committing — "ghost geometry" that displays where an object will land before the user releases the mouse. This transforms a potentially error-prone operation into a visually verified one. Any operation with significant consequences should offer some form of consequence preview, especially when the action is difficult to reverse.

Consequence Severity​

Not all errors are equal. A useful way to evaluate error-proneness is to consider both the likelihood of an error and its severity:

  • Low severity, easy recovery: Misspelling a layer name — rename it
  • Medium severity, moderate recovery: Applying an effect to the wrong layer — undo and reapply
  • High severity, difficult recovery: Baking a simulation that overwrites the original — may require restarting from a saved checkpoint
  • Catastrophic, no recovery: Saving over a file with no backup — permanent data loss

Software should make the severity of an action proportional to the effort required to initiate it. Destructive operations should be visually distinct and require explicit confirmation.

Testing​

  1. Walk through common workflows and note where mistakes are most likely — look for operations where the wrong target or wrong parameter is easy to select accidentally.
  2. Test what happens when errors occur: Does the system detect them? How clearly does it communicate the problem? How easy is it to recover?
  3. Check whether destructive operations are clearly distinguished from non-destructive ones — both visually and in the interaction required to trigger them.
  4. Look for silent errors — operations that appear to succeed but produce incorrect results. These are often the most damaging.
  5. Evaluate undo granularity: Can users undo individual operations, or does undo revert large batches of work? Can they undo across different parts of the application?

Conclusion​

Some degree of error-proneness is unavoidable in powerful professional software. The goal is not to eliminate all possibility of error (which would make the software too restrictive) but to ensure that errors are easy to detect, clearly communicated, and straightforward to recover from. The most dangerous error-prone conditions are those where the user cannot tell something has gone wrong.

Check After Improvement​

  • Visibility
  • Invisible Links
  • Rigidity

Footnotes​

  1. Hutchins, E. L., Hollan, J. D., & Norman, D. A. (1985). Direct manipulation interfaces. Human–Computer Interaction, 1(4), 311–338. ↩