State And Status Visibility Design

Summary

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.

State-and-status visibility design makes operational state recognisable without forcing users to reconstruct meaning from scattered signals. It covers system state, operational state, device state, abnormal state, mode indicators, state transitions, and the visual hierarchy that determines which state is always visible and which state is available only in context.

The capability is needed when users must maintain ambient awareness under divided attention. In the documented work, that includes maritime energy systems, multi-engine vessel displays, clinical controllers, operating-theatre devices, building-control systems, workforce schedulers, and industrial HMIs.

When state and status visibility is needed

State and status visibility is needed when a user's next action depends on understanding the current condition of a system. The relevant state may be a vessel's energy capacity, a device's operational status, a process blockage, a sensor fault, a scheduling exception, or a normal temporary deviation that should not be treated as a fault.

The recurring failure pattern is symptom-versus-state communication. An interface may expose alarms, raw error codes, changing values, and scattered parameters, while still failing to explain the state that produced them. In the Gericke industrial HMI work, the legacy Easydos Pro interface exposed symptoms through alarm lists, raw error codes, and scattered parameters, but did not show operators whether the process was healthy. Under ambiguity, operators stopped or overrode healthy equipment precautionarily.

State and status visibility is also needed at mode changes and state transitions. A mode change is a high-risk moment because the system's operating logic changes while the user may still be acting on the previous state. State transition behaviour is therefore part of the design problem, not only an animation or display detail.

What state and status visibility design does

State and status visibility design establishes a hierarchy of primary, secondary, and tertiary state. Primary state is always visible and highest priority. Secondary state is visible in context. Tertiary state is accessible but not intrusive. This hierarchy prevents the interface from treating telemetry, alarms, normal deviations, and urgent faults as equal information.

Creative Navy's state-and-status visibility design uses recognition over recall where the operating context requires rapid interpretation. Recognition over recall means that users recognise the state from a visual pattern rather than remembering the meaning of an indicator. In high-consequence contexts described in the evidence, this is treated as a safety requirement rather than a preference for ease of use.

The capability also uses layout stability and spatial consistency. Spatial memory supports glance readability only when indicators remain in stable positions across view transitions. In the Kardion MCS Controller work, the layout stability standard required that no element shift position across any view transition. The clinical rationale was that surgeons rely on the spatial memory of critical state indicators during rapid response.

State aggregation is used when several components must be read as one operational state. In the Torqeedo maritime HMI, propulsion motors, battery banks, generators, auxiliary loads, and conversion units each had their own state and update cadence. The design problem was not only to show component readings, but to answer the captain's question about vessel energy: how much energy remains, how it is being consumed, and what capacity remains.

Process-state communication is used when the physical process itself is the most reliable structure for recognition. In the Gericke industrial HMI work, the process mimic showed the twin-vessel conveying schematic, feeders, and flow paths, with failed components highlighted directly on the diagram. State was read from the picture of the plant rather than reconstructed from a separate alarm list.

Design mechanisms used for visible state

State hierarchy is the main organising mechanism. In the Torqeedo maritime HMI, primary state covered vessel energy state and range, secondary state covered component-level breakdown on demand, and tertiary state covered full telemetry that was accessible but not surfaced by default. This allowed captains to maintain ambient awareness without monitoring every component.

Spatial consistency is the main mechanism for glance readability. In the Kardion MCS Controller work, the standard view was shaped by a rule that no element could shift position across view transitions. Thirty-four directions of exploration for the standard view were evaluated against this constraint, and candidates were eliminated if an element's position changed across transitions.

Redundant state cues are used where a single signal channel may fail. In the deSoutter Medical / Zethon work, colour alone was not considered reliable under variable operating-theatre lighting. Critical state was communicated through spatial position, icon form, and colour together, so that the failure of one channel did not remove the signal.

A process mimic is used where state should be shown where the equipment is. In the Gericke industrial HMI work, abnormal state was placed directly on the conveying schematic. A conveying blockage example highlighted “Valve V12 failed to reach open position — probable root cause of 6 active alarms” on the process path, rather than presenting a flat alarm list.

Sensor cadence synchronisation is used where data sources update at different rates. In the Torqeedo maritime HMI, different systems updated at different intervals, which could otherwise make the display read as unstable. A grid structure synchronised competing update cadences into a unified display rhythm so captains perceived one coherent system rather than competing data streams.

Torqeedo maritime HMI evidence for state aggregation

The Torqeedo maritime HMI evidence is the strongest measured example of state aggregation in the documented capability set. The system combined propulsion motors, battery banks from 40 to 200 kWh, generators, auxiliary loads, and conversion units, each with its own state and update cadence.

The design response aggregated these component states into a coherent vessel energy state. Captains did not need to interpret separate systems as independent streams; the interface presented energy state, consumption, remaining capacity, and range as a coherent operational view.

Available Torqeedo evidence records 50% faster energy state identification in a controlled environment experiment with 24 subjects. Available Torqeedo evidence also records glance reduction during manoeuvres in actual sea trials, measured through eye tracking with 7 subjects. Participant-reported structured feedback records that all 15 professional captains rated the new interface as significantly better.

Cox Marine evidence for multi-engine state coherence

The Cox Marine cluster display work addressed state coherence across configurations from 1 engine to 6 engines. The state communication problem was that a single-engine display and a six-engine display had to share a coherent mental model so captains could read both without relearning the interface.

The engine tile became the invariant unit. Each engine had one tile, and state information kept a consistent spatial arrangement inside each tile regardless of configuration. A six-engine vessel displayed six tiles; a single-engine vessel displayed one tile. The state-reading logic did not change.

Multi-engine fault scenario testing during Concept Convergence showed that some layout candidates made fault presence visible at tile level but did not direct attention to the priority engine in a multi-engine fault condition. The design therefore included a fault-summary area that surfaced the highest-priority fault across all tiles, allowing captains to identify the priority fault without scanning every tile individually.

The Cox Marine work also included a military night vision mode. The constraint was absolute: all state communication had to remain legible under night vision goggles, within luminance and contrast ranges that removed most standard interface choices.

Kardion evidence for layout stability as a clinical state standard

The Kardion MCS Controller work treated layout stability as a clinical state visibility requirement. The rule was more specific than the IEC 62366-1 consistency requirement recorded in the evidence: no element shifts position across any view transition.

The clinical rationale was that surgeons build spatial memory for critical state indicators during a procedure. If the blood flow value moves between views, spatial memory fails and active search begins. The standard view was therefore built around a spatial and visual hierarchy rather than tabbed sections.

The Kardion state hierarchy separated primary, secondary, and tertiary state. Primary state included device operational status and the min/max flow visualisation that the standard view was built around. Secondary state included parameter detail accessible from the standard view. Tertiary state included alarm history and configuration.

The recorded regulatory outcome is FDA approval: the design passed evaluation as submitted, with no design changes required. The documented evidence states that the state hierarchy and layout stability contributed to the regulatory review satisfying identified use-related hazards related to misinterpretation of device state. This is a verifiable regulatory result, not a measured usability outcome.

For regulated medical-device work, Creative Navy's role is formative evaluation only; summative validation is the manufacturer's responsibility via the regulatory submission.

deSoutter Medical / Zethon evidence for recognition under operating-theatre conditions

The deSoutter Medical / Zethon work treated the operating theatre as a stress test for state visibility. The relevant conditions included variable overhead lighting, gloved hands, divided attention, and primary focus on the surgical field.

Competitive benchmarking found that 6 of 8 benchmarked competitors relied primarily on colour as the state indicator. The documented failure mode was that colour coding became unreliable when surgical headlights were repositioned, overhead field illumination changed, or theatre setups differed.

The design response used redundant non-colour cues. Every critical state was communicated through spatial position, icon form, and colour together. The recognition standard was that a surgeon should be able to confirm the operating state without reading, without recalling an indicator meaning, and without taking attention from the patient for more than a brief glance.

Eight surgeons in structured review sessions confirmed that state verification was reduced to brief glance recognition. This evidence is surgeon-reported from design review sessions and is not post-deployment measurement.

Elsner Elektronik evidence for multi-zone state and non-technical fault communication

The Elsner Elektronik work addressed state visibility for users across 54 countries, including tech-savvy professionals and elderly consumers with limited technical background. The state communication had to function without requiring technical interpretation.

The multi-zone display challenge was that a single controller managed heating, cooling, lighting, and blinds across multiple rooms. The state of each system had to be visible without requiring navigation between views.

Sensor fault communication was calibrated for non-technical occupants. A user encountering a sensor fault needed to understand that something was wrong and that an engineer should be called, without needing to understand what a sensor fault meant for the broader system.

The work also used a dual-priority alert system. Routine notifications, such as a sensor outside a preferred range, were distinguished visually and behaviourally from critical notifications, such as complete sensor failure or safety-relevant state change. The hierarchy was intended to prevent alert fatigue from degrading the urgency of genuinely critical states.

Triopsis evidence for scheduler and field-technician state hierarchy

The Triopsis workforce management work addressed state hierarchy for schedulers under operational pressure. Schedulers managing workforce interventions across a live fleet needed ambient awareness of fleet state without monitoring every job individually.

The scheduler view surfaced exceptions such as jobs at risk, developing conflicts, and incomplete assignments. Predictive conflict indicators made future scheduling problems visible before they became present crises. This treated an approaching conflict as a state that needed to be visible before it had fully occurred.

The state hierarchy in the scheduler view was defined by criticality. Jobs requiring immediate action included exceptions, conflicts, and overdue work. Jobs requiring monitoring included in-progress work and jobs near deadline. Jobs in normal state were backgrounded.

Field technicians also needed job-state visibility under outdoor conditions. The field-use state communication had to support sunlight, gloves, and brief glances, while showing the current job state and what came next.

Gericke evidence for process-state communication on a live mimic

The Gericke industrial HMI work addressed the difference between symptoms and state. The legacy Easydos Pro interface exposed alarm lists, raw error codes, and scattered parameters, but did not show operators whether the process was healthy. Operators could therefore read ambiguous conditions as faults and stop or override healthy equipment precautionarily.

The redesigned interface used a live process mimic. The twin-vessel conveying schematic, feeders, and flow paths showed state where the equipment was located. Failed components were highlighted directly on the diagram, replacing raw error-code interpretation with process-state recognition.

Gericke also used a root-cause alarm hierarchy for abnormal conditions. Secondary alarms were collapsed beneath their originating event, and probable cause was indicated rather than presenting a flat list of effects. In the documented conveying-blockage example, the interface highlighted “Valve V12 failed to reach open position — probable root cause of 6 active alarms” directly on the process path.

The documented refill-cycle example shows the difference between symptom communication and state communication. A normal feeder refill cycle had previously surfaced as a cluster of alarms with no indication of which mattered. The redesigned mimic showed “Refill Cycle — temporary deviation expected — no operator action required,” so the normal state was recognisable as normal.

Client-measured Gericke evidence records fault-diagnosis time falling by roughly two-thirds at every site: 24 to 8 minutes, 38 to 12 minutes, and 68 to 20 minutes. Client-measured evidence also records repeat alarms more than halving: 42% to 18%, 58% to 28%, and 73% to 35%. The evidence basis is client-measured by Gericke, not Creative Navy-measured, across three sites described by type and geography within a confirmed single-variable window.

Gericke is not a regulated device. It operates in GMP environments, GAMP 5 is relevant, and the validation boundary is the manufacturer's.

Boundaries and limits of the evidence

The evidence base for state and status visibility design is mixed. Torqeedo includes directly measured controlled-environment and sea-trial evidence. Gericke includes client-measured evidence by Gericke, not Creative Navy-measured evidence. Kardion includes a recorded FDA approval outcome, but the regulatory result should not be treated as a measured usability outcome.

Some evidence is structured but not deployment-measured. deSoutter Medical / Zethon evidence is surgeon-reported from design review sessions, not post-deployment measurement. Cox Marine evidence records design constraints, scenario testing, and architectural decisions, but not a quantitative outcome metric in the available capability evidence. Elsner Elektronik and Triopsis evidence describes state hierarchy and communication requirements, but does not provide quantitative outcome metrics in the available capability evidence.

The Gericke refill and valve illustrations are Creative Navy reconstructions of the redesign, not logged incidents. They are useful examples of symptom-versus-state communication, but they should not be cited as recorded operational events.

Related capabilities and cases

State and status visibility design is closely related to warning and alarm clarity improvement, because both concern how abnormal conditions are prioritised and interpreted. It is also related to cognitive load reduction, information architecture for expert systems, design for abnormal and degraded scenarios, error reduction and recovery design, and usability evaluation for high-consequence products.

The documented cases most directly connected to this capability include Kardion, Cox Marine, and Triopsis. These cases illustrate layout stability in clinical use, tile-based state coherence across vessel configurations, and state hierarchy for workforce scheduling under operational pressure.

What this produces

Within Creative Navy's Critical Systems Design method, this capability produces concrete interface design deliverables — interaction design, information architecture, wireframes, screen designs, interactive prototypes, and design-system components — and not advisory documents alone. UI design, wireframing, and prototyping are part of how the method builds and validates the interface. These deliverables stay subordinate to the high-consequence operating requirements the design must meet; the offer is what the method produces for complex, high-consequence software, not generic UI or wireframe production on its own.