Failure Modes

This failure describes interfaces that require users to remember where information is, interpret states by reading, or learn the system's internal model before they can operate safely. The page distinguishes layout instability, recognition failure, and conceptual overload, with examples from Kardion, deSoutter Medical / Zethon, and Polymatica.

The interface gets harder when pressure rises when design and evaluation conditions under-represent the physical environment, attentional division, and time compression that determine operational performance. The failure is not that the interface stops working; it is that the cognitive cost of using it increases at the same moment when the user's task also becomes harder.

This failure describes complex interfaces that contain the necessary information but do not organise it into the conditions required for fast, accurate judgment. The failure appears when users must synthesize distributed data, establish priority through scanning, or infer contextual significance under operational demand.

Routine tasks can impose a disproportionate attention cost even when the software is functional and tasks can be completed. The failure appears as accumulated friction, training burden, workarounds, adoption gaps, or extended glance duration in embedded displays used during physical activity.

Users cannot reorient quickly after interruption when the interface does not make task position recoverable at the moment of return. The failure appears in module-based operational tools, multi-device workflows, and sequential physical processes where the user needs visible position recovery or active re-entry guidance.

Edge case breakage is a failure pattern in which a system encounters inputs or conditions outside its designed envelope and enters states that were never designed. The failure concerns undefined or incoherent behaviour, not merely poor support for unusual scenarios.

Errors are easy to make when technically complete software does not provide enough scaffolding for users to avoid predictable mistakes during normal, intentional operation. The pattern appears when valid and invalid actions are not distinguishable before action, when feedback does not make the result of an action readable, or when interface complexity hides the operative element.

Error correction can fail at several points: finding where the error occurred, knowing the intended state, taking the corrective action, and confirming that the system is now correct. This failure applies when recovery structures nominally exist but do not support the user well enough during correction.

Errors are hard to notice when the interface shows no clear, timely, or operationally perceptible signal that an error has occurred. The failure is consequential because users continue acting within a false-normal frame until the error appears later in outputs, reviews, or downstream use.

This failure describes the interaction quality gap between the main workflow and the scenarios outside it. It appears when development assumptions define what is rare, when operationally common conditions are absent from design research, or when non-standard states are handled through generic error mechanisms.

Recovery paths are interface structures that return users from error and fault states to valid operational conditions. They are weak when they are absent, generic, incomplete, ambiguous, or dependent on external knowledge that the interface does not provide.

Good behaviour is not defined explicitly when experienced team members can describe what good outputs or decisions look like, but the product does not embody that knowledge in its interaction architecture, evaluation criteria, or user-facing behaviour.

This failure occurs when a review workflow includes approval, sign-off, or audit documentation but does not support independent assessment at the review step. Reviewers may approve nominally, escalate for missing information, or block the workflow, with nominal approval often becoming the path of least resistance.

Product behaviour cannot be explained or reviewed cleanly when the interface does not record, represent, and expose the reasoning behind configurations, decisions, or outputs. The product may function operationally, but reviewers cannot trace how behaviour was produced or verify that it matches approved specifications.

This failure describes systems whose behaviour is operational but not explicitly specified. The product produces outputs and users interact with it, but the team cannot answer governance, support, or model-comparison questions against a defined behavioural standard.

The system nudges acceptance too easily when the interaction design makes acceptance the natural continuation and makes scrutiny require extra effort. The failure does not remove user judgement; it biases the path of least resistance toward accepting, approving, or continuing.

This page defines an interpretation failure in which data is present but not represented in a form that supports reliable understanding. It covers failures of conceptual language, absent reasoning, missing contextual scaffolding, and two documented examples from Polymatica and Akrivia.

This failure describes AI interfaces that present outputs as uniformly reliable results rather than as estimates with varying confidence and evidence quality. It focuses on confidence, reasoning, and evidence being visible at the point where users accept, override, or verify an AI output.

Users see information but cannot judge what matters when an interface provides data without the contextual scaffolding needed to determine significance, relevance, or priority. The documented examples include Triopsis workforce management, Owkin / K, and eToro multi-asset social trading.

Warnings can fail even when they are visible. The failure is interpretive: the interface interrupts the user but does not make the warning's meaning, urgency, or implied response immediately accessible.

Important status information is buried when an interface assigns insufficient visual prominence to information with operational significance. The failure commonly appears as missed alerts, missed calibration states, repeated checks, or status conditions that were visible in retrospect but not perceived at the moment of action.

Mode changes are unclear when the transition between system states is not communicated in a way users can reliably perceive under real operating conditions. This failure is distinct from general state invisibility and from cumulative spatial memory burden, although the mechanisms often co-occur.

This failure concerns the transition moment, not the resulting state. Users may understand the old state and the new state, but still miss the change between them when the transition signal is absent, too subtle, single-channel, spatially disorienting, or mistimed against the underlying system.

This failure occurs when current system state is absent, fragmented, or not legible at the surface of the interface. It is consequential in complex systems because users must reconstruct what is happening from indirect evidence before they can act, verify, or review decisions.

This failure describes workflows where the system surfaces an action when internal system conditions are met rather than when the user's operational context makes the action most useful. It appears as reactive problem surfacing after commitment, or as action timing that conflicts with the user's cognitive readiness.

Handoffs lose context when work passes between parties but the receiving party cannot access the prior party's relevant information in the form and moment required for correct continuation. The common signals are escalation, reconstruction, or proceeding with an incomplete picture.

This workflow failure describes tasks that become structurally elongated because users must navigate across too many screens, sections, windows, or steps to complete work that is operationally simpler than the interface makes it.

This failure describes software that imposes its own task sequence, action order, or behavioural assumptions on users rather than matching the logic of the work users are trying to perform. The result is not always an error or a blocked path; it is often a workflow that is almost correct but persistently misaligned.

This failure occurs in multi-role software when each role's interface is specified separately but the workflow crossing between roles is not. It appears as lost handoff context, single-interface mismatch across role groups, or incompatible mental models about what a submitted artefact must satisfy.