Error Likely Interaction Review

Error Likely Interaction Review in Creative Navy's Critical Systems Design method

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Creative Navy applies error likely interaction review as one of the named practices within its Critical Systems Design method. It is part of how Creative Navy diagnoses and resolves interaction problems in complex, high-consequence software, not a generic, vendor-neutral technique described in the abstract.

Summary

Error-likely interaction review is an analytical practice for identifying interactions that are structurally likely to produce errors. It is conducted before or between usability test cycles, and it does not depend on waiting for a participant to make the error in observed testing.

The central question in error-likely interaction review is not "what errors have users made?" The central question is what the interaction requires of users, and under what conditions that requirement will produce errors.

A single confirmation step before an irreversible high-consequence action is error-likely even if no participant has clicked through it accidentally. A colour-only state indicator on a device used in variable lighting is error-likely before anyone misreads it in a test. The practice identifies these structural conditions analytically so that design requirements can be defined before the interaction is tested into evidence.

What error-likely interaction review does

Error-likely interaction review identifies the mechanism that makes an interaction error-prone, the consequence if the error occurs, and the design requirement that must be met to reduce the likelihood of error.

The practice treats error likelihood as a property of the interaction structure, not only as a count of observed user mistakes. It asks whether the interaction depends on memory, hides relevant state, permits an irreversible action too easily, withholds information at the decision point, or communicates critical state through a single channel that may fail under operating conditions.

The review does not produce a design solution as its primary output. It produces a design requirement. In regulated contexts, that requirement is formally documented and traceable to the identified hazard.

When error-likely interaction review is used

Error-likely interaction review is used during Sandbox Experiments on an existing system before design decisions are made. In that position, the practice produces the error profile that the design work must address.

Error-likely interaction review is also used during Iterative System Building on design prototypes before implementation. In this position, the practice is applied especially to critical tasks identified through task-criticality mapping.

In regulated medical device contexts, error-likely interaction review runs throughout the engagement as part of IEC 62366-1 formative evaluation. The review supports the identification of foreseeable use errors and foreseeable misuse, and it supports traceability between design decisions and identified hazards. Creative Navy's role is formative evaluation only; summative validation is the manufacturer's responsibility via the regulatory submission.

Error mechanisms examined by the review

Error-likely interaction review examines memory-dependent interactions where users must recall information rather than recognise it from the interface. Examples include a calibration technician remembering which measurement sequence is current, a surgeon remembering which parameter a rotary knob is adjusting, or an officer remembering alert criteria for a goods category. These interactions are error-prone under time pressure or divided attention.

Error-likely interaction review examines ambiguous state at decision points. This includes configuration steps where prior values are not displayed, mode changes where the current mode is not visible at the point where mode-specific behaviour matters, and alarm states where the triggering condition is not shown alongside the alarm.

Error-likely interaction review examines insufficient confirmation friction. Irreversible or high-consequence actions that can be completed with a single interaction step are assessed for whether the confirmation friction is proportional to the consequence.

Error-likely interaction review examines information absence at decision points. This occurs when information needed for a correct decision is available somewhere in the system but is not surfaced where the decision is made.

Error-likely interaction review examines single-channel state communication. A critical state indicator that depends only on colour, sound, text, or spatial position can become error-likely when that channel fails under operating conditions.

Error-likely interaction review also examines foreseeable misuse patterns. In the IEC 62366-1 context described here, foreseeable misuse must be identified explicitly rather than treated as intended misuse.

Outputs of error-likely interaction review

The first output of error-likely interaction review is the error mechanism. The mechanism explains why the interaction produces errors. The source mechanisms include memory dependency, ambiguous state, insufficient friction, information absence, and single-channel communication.

The second output is the error consequence. The consequence describes what happens when the error occurs and is classified by reversibility and magnitude. A reversible low-consequence error requires a different design response from an irreversible safety-relevant error.

The third output is the design requirement. The requirement states what the design must satisfy to reduce error likelihood to an acceptable level. In regulated contexts, the requirement is traceable to the identified hazard.

Engagement evidence for error-likely interaction review

Engagement evidence shows error-likely interaction review being applied across medical device, operating theatre, simulation, automotive calibration, and keyboard adoption contexts. The examples below are engagement-specific and should not be treated as universal evidence that the same mechanisms or requirements apply in every system.

In the Kardion MCS Controller engagement, the IEC 62366-1 formative evaluation process structured the review formally. A flow rate adjustment via rotary knob was identified as error-likely because a single physical input controlled a clinically significant parameter. The foreseeable error was inadvertent adjustment during procedure setup or equipment repositioning. The error mechanism was insufficient confirmation friction for a high-consequence action, and the design requirement was two-step confirmation before adjustment took effect.

In the Kardion MCS Controller engagement, min/max flow value misinterpretation was identified in a prior Emergo by UL formative study. The error mechanism was visual ambiguity in the prior display. The design requirement was that the primary flow visualisation make the min/max hierarchy unambiguous without requiring interpretation.

In the Kardion MCS Controller engagement, alarm state during mute was treated as foreseeable misuse. A user could silence an alarm and then forget it was active. The error mechanism was that alarm disappearance on mute removed the ongoing reminder. The design requirement was that muted alarms remain visually present at reduced prominence.

In the deSoutter Medical / Zethon engagement, the operating theatre context defined the foreseeable use conditions and foreseeable misuse profile. Activation state recognition was identified as the highest-risk interaction in the surgical workflow. The error mechanism was a state indicator relying on colour as the primary differentiator under variable lighting. The design requirement was redundant non-colour cues using spatial position, icon, and colour.

In the deSoutter Medical / Zethon engagement, speed parameter adjustment during procedure was identified as an interaction competing with primary surgical attention. The error mechanism was the need to actively read the current parameter value while performing the procedure. The design requirement was that the parameter adjustment display be confirmable as a glance-check without interrupting workflow.

In the Gexcon CFD simulation engagement, the review identified configuration error patterns across the simulation setup workflow. Error-prone interactions included required values that were not clearly signalled before simulation initiation, contradictory parameter combinations that were not identified before run, and deferred consequences where an error produced a completed simulation with incorrect outputs. The design requirement was an interactive configuration warning architecture that surfaced incomplete and contradictory inputs before run.

In the Beissbarth automotive calibration engagement, contextual observation across 5 workshops identified error-likely interactions in calibration workflows. Borderline tolerance measurement confirmation was error-likely because technicians needed to distinguish between a confirmed measurement and one requiring repetition. The design requirement was three-level measurement result communication: confirmed, borderline, and out of range.

In the Beissbarth automotive calibration engagement, calibration sequence state tracking was error-likely because multi-step sequences had no persistent completion state visible across the sequence. Technicians relied on memory. The design requirement was a persistent sequence state display showing completed, current, and upcoming steps.

In the Typewise AI keyboard engagement, error-likely interaction review was part of the domain learning phase. Creative Navy installed and used the keyboard before beginning design work. The review identified an adoption barrier at the product level: new users moving from the iOS native keyboard had a substantially higher error rate than experienced users because gestural patterns conflicted during transition. The design requirement was an adoption framework structured around Zone of Proximal Development, introducing new gestures within reach of existing competence.

Relationship to task, state, and cognitive-load practices

Error-likely interaction review draws on task-criticality mapping because critical tasks are the primary scope for the review. Error likelihood has the greatest consequence where task criticality is highest.

Error-likely interaction review draws on state and transition review because state ambiguity is one of the primary error mechanisms. The state review provides evidence about whether the system state needed for correct action is visible at the decision point.

Error-likely interaction review draws on cognitive load analysis because high cognitive load under operational conditions is a primary predictor of error likelihood. Memory dependency, divided attention, and glance-check requirements are evaluated in relation to the conditions under which the interaction occurs.

Error-likely interaction review directly informs edge case and degraded mode analysis. The most error-prone interactions are examined under non-nominal conditions to understand worst-case scenarios.

Boundaries and limits of error-likely interaction review

Error-likely interaction review is not a usability test. It identifies structurally error-prone interactions analytically, but observed testing may still be needed to evaluate how users behave with a design under realistic constraints.

Error-likely interaction review identifies design requirements, not finished design solutions. A requirement such as two-step confirmation or redundant non-colour cues still needs to be translated into a concrete interface design and evaluated in context.

Engagement examples on this page are evidence of how the practice was applied in specific contexts. They do not establish that the same error mechanisms, consequences, or requirements apply unchanged in other systems.