Warnings Are Visible But Not Actionable

Warning visibility is not the same as actionable warning design

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.

A visible warning is not necessarily an actionable warning. A warning must be evaluated by whether the operator can process it and act on it correctly in the conditions that produced it, not only by whether the warning appears on screen.

In high-consequence operational contexts, warning design cannot be reduced to information hierarchy. A warning that requires reading is not functional when only a glance is available. A warning that relies on colour as its primary signal is not functional under lighting conditions where colour distinction is unreliable. A warning that appears at a point where the operator cannot interrupt the primary task creates a choice between acting on the warning and completing the task safely.

Under IEC 62366-1, the international standard for usability engineering of medical devices, a warning that cannot be acted on under use conditions is classified as a use-related hazard. The presence of a warning is not evidence that the risk has been addressed; the warning must be perceived, interpreted, and acted on under the identified use scenarios and environments.

Format failure occurs when warnings require reading but only recognition is available

Format failure occurs when a warning depends on text reading, code interpretation, or labelled state interpretation in conditions where the operator has only divided attention and a fraction of a second. The warning may be legible at a desk under controlled conditions and still fail in the field.

In a surgical procedure, vessel manoeuvre, or high-throughput operational task, reading may not be available. The operator may need to maintain sterile position, monitor a patient, coordinate with other people, or continue a primary manoeuvre while briefly checking system state. In those conditions, a sentence or code is slower and less reliable than a recognisable state pattern.

The design response is pattern-based recognition. Warning states need to communicate through visual form, spatial arrangement, redundant cues, and high-contrast differentiation rather than through verbal content alone. The source material connects this principle to standardised symbols in medical device standards, aviation alerting design, and industrial control systems.

Timing failure occurs when warnings appear at points where response is unsafe

Timing failure occurs when a warning appears during a sequenced operational workflow at a point where the operator cannot safely respond. The interface then imposes a double-bind: ignore the warning and continue, or respond to the warning and interrupt the workflow.

A warning is actionable only if it appears at a point where the operator can evaluate it and respond without creating a second hazard. The design response is contextual warning placement: the workflow must be understood well enough to position warning communication at moments where correction, acknowledgement, or escalation is possible.

Creative Navy's Critical Systems Design method treats this as a domain learning problem. The relevant workflow must be understood from inside the task rather than only from a functional specification, because warning actionability depends on what the operator is doing when the warning appears.

Gradient failure occurs when all warnings signal with equal weight

Gradient failure occurs when warnings proliferate without being prioritised. Systems that evolve by accumulation often assign warning treatment to every possible risk condition, while the visual grammar remains flat.

When all warnings have the same visual weight, operators develop a single response: check, assess, proceed. A genuinely urgent warning then receives the same initial treatment as an advisory state. In a clinical or safety-critical context, the time needed to distinguish urgency can become the difference between a managed risk and an unmanaged one.

The design response is a warning hierarchy with consequence-differentiated visual grammar. The interface must communicate not only that something requires attention, but also what class of attention it requires, so that genuine urgency is distinguishable without a separate assessment step.

Architecture failure occurs when warnings are added after the layout is fixed

Architecture failure occurs when warning design is treated as an additive visual step instead of a structural design decision. If screen architecture, interaction logic, and layout rules are fixed first, warnings have no native relationship to the surface they inhabit.

In this failure mode, warnings can cover content they should not cover, appear at moments the interaction model cannot accommodate, or interfere with active tasks because no space or timing was reserved for their appearance. The warning is present, but the interface was not built to receive it.

Architecture failure is often invisible when individual warnings are evaluated in isolation. The failure becomes visible only when warnings interact with the full screen architecture under real operating conditions, such as a battery warning covering a speed readout or a status alert interrupting an input sequence without a designed recovery path.

The design response is architectural. Rules for how warnings, overlays, and interruptive states relate to the screen structure must be established before components are built. Warning behaviour is a structural decision, not only a visual one.

deSoutter Medical / Zethon showed format failure in surgical device warnings

The deSoutter Medical / Zethon engagement concerned an embedded GUI for a powered ultrasonic bone cutter used in orthopaedic and trauma surgery. The device operates at high rotational speeds and is subject to IEC 62366-1 usability engineering requirements.

Surgeons needed to confirm device state, readiness conditions, and warnings through brief glances while maintaining sterile position, managing the patient, and coordinating with surgical assistants. The interface was typically used with the non-dominant hand, through gloves, and under variable theatre lighting.

The legacy interface presented warnings as text. Under controlled viewing conditions, this was legible. Under actual surgical conditions, it required the surgeon to shift primary attention from the patient to the interface long enough to read, parse, and interpret a statement. In this operating theatre context, format failure is a use-related hazard under IEC 62366-1.

Creative Navy's Sandbox Experiments included benchmarking six comparable surgical devices and identified a widespread category pattern: reliance on colour as the primary warning signal. Colour-based warnings functioned adequately under ideal theatre lighting, but colour distinction was unreliable under the range of lighting conditions present in real operating theatres.

Creative Navy's redesign applied pattern-based recognition throughout the warning system. Critical states were communicated through spatial arrangement, redundant non-colour cues, and high-contrast differentiation that did not rely on colour alone. Eight surgeons reported that device state could be verified through brief glances without reading and that warning presentation no longer required attention to be pulled from the surgical field for interpretation.

The evidence basis for the deSoutter Medical / Zethon example is surgeon-reported from 13 structured design review sessions; it is not post-deployment operational measurement. Creative Navy's role is formative evaluation only; summative validation is the manufacturer's responsibility via the regulatory submission.

Gexcon showed timing failure in safety-critical simulation configuration

The Gexcon engagement concerned CFD simulation software used by engineers performing gas dispersion modelling, explosion risk assessment, and facility safety validation for industrial installations. Before Creative Navy's engagement, the interface did not communicate clearly where in a simulation setup an error had occurred.

Engineers could complete a scenario configuration and receive output that appeared valid, while configuration errors remained embedded in it. The source material records an average of 5–8 configuration errors per simulation before the redesign. Error discovery was deferred until output review or until a simulation had to be re-run.

This was timing failure at workflow scale. Configuration warnings were not surfaced during the configuration step, where correction was straightforward. They became visible after the simulation, when reconstructing the source of an anomalous result required 4–6 hours of corrective work.

Creative Navy's Critical Systems Design method addressed the issue through an error-prevention interaction architecture. The requirements specified which values had to remain visible during scenario setup, where warnings were needed before the simulation ran, and how the system should respond to incomplete or contradictory input.

After the redesign, configuration errors reduced to 1–2 per simulation and corrective load reduced to approximately 20 minutes. The evidence basis is measured by Gexcon across real deployment locations.

Stromer showed warning architecture failure on an embedded e-bike display

The Stromer engagement concerned a warning architecture problem on a consumer e-bike embedded display. The interface spanned an embedded display on the bike, a mobile companion app, and a web account. The embedded display was used while riding, where the rider's eyes leave the road to recognise or read displayed state in a glance.

The bike carried safety warnings, status alerts, error states, and threshold notifications. EN 15194:2017, the European standard for electrically power-assisted cycles, specifies requirements for warning device behaviour and symbol conventions.

Before Creative Navy was engaged, a previous external agency had completed a year-long design engagement that produced a design system and visual redesign work. The unresolved structural problem was warning architecture. Warnings had been layered onto a screen architecture that had already been set.

The consequences were observable in use. Warnings covered parts of the screen they should not cover, interfered with active interactions, were difficult to dismiss in context, and frequently appeared without enough contextual information for the rider to understand what they were about.

Creative Navy's redesign addressed the layout and overlay system, the information architecture, and the rules governing how warnings and other interruptive elements relate to the screen structure across all states and warning types. The structural sequence was rules before components.

The outcome was tested using a structured methodology designed and run by Creative Navy. Ten participants rode the bike over three days each on real routes in Munich and surrounding countryside, logging every issue encountered with its severity on a four-level scale: interference, annoyance, issue needing user intervention, or critical issue. Before the redesign, warnings accounted for approximately 30% of all issues rated as requiring user intervention.

After the redesign, the same test was run with 10 users, including six from the original cohort and four replacements, using the same bikes, routes, and logging protocol. Warnings did not appear on the issues list. Creative Navy ran the same test again two years later, and warnings remained absent. The evidence basis is Creative Navy-designed and run across all three rounds.

Creative Navy's Critical Systems Design method addresses warnings through domain learning and performance in reality

Creative Navy's Critical Systems Design method addresses warning actionability by examining how operators encounter warnings under real conditions, not only how warnings appear in interface layouts. The shared root across format failure, timing failure, gradient failure, and architecture failure is that the warning was designed for a user with time, attention, and controlled conditions available, rather than for the operator who actually encounters it.

Domain learning is the prerequisite. In the deSoutter Medical / Zethon engagement, 13 structured sessions with eight surgeons documented when surgeons check device state and which moments in the surgical workflow are sensitive to attention being drawn away. In the Gexcon engagement, understanding the simulation workflow from inside the work made it possible to position warnings at points where they were actionable. In the Stromer engagement, Creative Navy studied the previous agency's work as an accelerated first iteration to understand what had been attempted and why it had not resolved the underlying tensions.

Performance in reality is the evaluation standard. A warning is not evaluated only on a screen at close range. It is evaluated under the lighting, time pressure, physical constraints, divided attention, and workflow interruptions of actual operation. Under IEC 62366-1 this is a regulatory requirement for medical devices; in the other documented examples it is the condition that determined whether the warning worked.

Boundaries of the documented evidence

The deSoutter Medical / Zethon evidence is formative and surgeon-reported from 13 structured design review sessions. It is not presented as post-deployment operational measurement, and summative validation remains the manufacturer's responsibility.

The Gexcon outcome evidence is measured by Gexcon across real deployment locations. The source material reports the before-and-after error and corrective-load figures, but does not describe an independent study.

The Stromer outcome evidence comes from a structured methodology designed and run by Creative Navy across three rounds. The source material describes repeated real-route testing with matched routes, bikes, and logging protocol, but does not describe the study as independent.

The documented examples support the failure patterns described on this page. They do not establish that every warning problem in every operational domain has the same cause or requires the same design response.