The Interface Demands Too Much Memory

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.

An interface demands too much memory when it requires users to hold information that the interface should communicate directly. The user may need to remember where information is located, interpret what a state means, or carry a conceptual model of how the system organises its data.

This failure is structural. It is not caused only by user inattention or by the inherent complexity of the domain. It occurs when the interface transfers cognitive work from the screen to the person.

In capable users, the added memory demand may remain tolerable in calm conditions. In operational conditions such as time pressure, divided attention, high transaction rate, clinical procedure, or physical constraint, the same demand can become a failure mode.

Failure pattern: the interface holds too little and the user must hold too much

The interface demands too much memory when it withholds structure that users need during the task. The same mechanism appears in three forms: layout instability, recognition failure, and conceptual overload.

Layout instability occurs when elements shift position across view transitions, screen states, overlays, or mode changes. The spatial map a user builds in one context no longer applies in another context, so the user must actively search for information.

Recognition failure occurs when critical states are presented in forms that require reading and interpretation. Device activation, system readiness, alarm priority, and similar conditions need to be immediately readable under brief attention. If the interface requires sequential reading, the state is not available in the mode of attention the task permits.

Conceptual overload occurs when the interface exposes the system's internal model. Technical constructs, empty-by-default states, and engineering hierarchies require users to learn how the system thinks before they can use it in operational terms.

Layout instability makes spatial memory unreliable

Users of complex software build spatial memory while working. They learn where information lives on screen, often without intending to. In operational environments, spatial memory is not only a shortcut; it may be the only practical navigation method available during divided attention.

When layout changes across view transitions, the user's remembered location and the screen's actual location no longer match. The user must reconcile that mismatch before acting. Under calm conditions, this may cost only a fraction of a second. Under clinical or high-throughput conditions, it can interrupt the task.

The Kardion MCS Controller example shows this form of memory demand in a regulated cardiac-device interface. The controller manages blood flow delivered by an implanted pump to patients during high-risk cardiac interventions and cardiogenic shock support. Primary users include scrub nurses, perfusionists, and ICU nurses working with primary attention on the patient and procedure and secondary attention on the controller.

In the Kardion engagement, Creative Navy's design work established a governing design standard: no element may shift position across any view transition. The standard applied across the standard running view, flow adjustment overlay, alarm states, trend screens, case management views, and setup screens. The intent was that spatial memory built in the primary running view would transfer directly to other view states.

The Kardion standard running view required 34 iterations. The iteration count is described as Creative Navy-recorded evidence of the difficulty of satisfying visual distinctiveness, clinical prioritisation, and spatial stability at the same time. The Kardion MCS Controller received FDA approval, passing the regulatory evaluation as submitted, with no design changes required. The regulatory result is documented as FDA approval; the page does not specify a pathway.

Recognition failure makes users read when the task requires a glance

Recognition failure occurs when critical state information cannot be confirmed through brief-glance pattern recognition. Reading requires focused, sequential attention. In an operating theatre, supervisor workstation, workshop environment, or high-throughput transaction context, that attention may already be allocated to the primary task.

The deSoutter Medical / Zethon surgical-device interface shows this form of memory demand in an operating-theatre context. The bone cutter operates at rotational speeds from approximately 200 rpm to approximately 85,000 rpm during orthopaedic and trauma surgery. The surgeon interacts with an embedded GUI during live procedures, with primary attention on the surgical field, often using the non-dominant hand, in a constrained sterile-field position, and through surgical gloves.

The legacy interface required reading to confirm activation states and device readiness. It used text labels for state conditions, colour coding without redundant spatial or iconographic reinforcement, and intermediate confirmation steps that required sequential attention to parse.

During Sandbox Experiments, six competitor devices were benchmarked. The most common failure pattern across the competitive set was reliance on colour as the primary state indicator. The surviving design did not rely on colour alone for any critical state.

Creative Navy's design standard for the deSoutter Medical / Zethon engagement was that every critical state must be interpretable through recognition in a brief glance, without reading. Fixed positions for critical indicators supported spatial stability. Redundant non-colour cues meant that spatial position, icon form, and reserved colour each independently communicated every critical state. Intermediate confirmation steps that added cognitive burden without contributing to safety were removed.

Eight orthopaedic and trauma surgeons participated in structured review sessions during the engagement. They reported that device state could be verified through brief glances without reading, and that parameter adjustments no longer interrupted surgical workflow. These were reports from participants in the design engagement, not post-deployment operational measurement.

Conceptual overload exposes the system model instead of translating it

Conceptual overload occurs when an interface presents the system's internal model as the user's operating model. This can include technical terminology, empty-by-default entry points, abstract hierarchies, or features that are visible but not explained in operational terms.

Polymatica's analytics platform shows this form of memory demand in a technically capable OLAP system. The GPU-backed OLAP analytics engine ran full-volume queries 50–100x faster than competing solutions and handled data at a scale that Tableau and Domo could not match. Its interface had been designed for OLAP specialists.

Before redesign, Polymatica surfaced the cube metaphor for data structures, used technical terminology such as “dimensions” and “facts” rather than the industry-standard “measures,” exposed SQL queries directly during database connection, and presented many entry points as empty by default. Advanced analytical features such as clustering, forecasting, and association rules were visible but unlabelled.

Users trained by the founder could work productively in the system. Every new customer required founder-delivered training before the product could be used at all. Before the redesign, 2% of users could complete key operations independently without consulting help documentation or tutorial videos. 9% could complete them with documentation.

The point of first-use failure was not mainly OLAP operation. Users trained on clean, structurally ideal data arrived with real datasets containing inconsistencies such as cities appearing in columns alongside other categories, malformed values, and non-standard structures. The interface offered no data preparation or preview step and no guidance for diagnosing the mismatch.

After Creative Navy's Critical Systems Design engagement, independent task completion rose to 40% following release 1 and 56% following release 2. These figures are measured through product analytics from real users in the live system. Release 1 addressed orientation; release 2 addressed feature-level guidance.

Workarounds show where memory demand has moved off screen

A physical workaround can reveal where the interface has imposed too much memory demand. When users cannot hold the required information during the interaction, they may externalise it outside the system.

Examples include printed reference sheets taped beside a terminal and handwritten sample lists placed next to a laboratory instrument. The location of the workaround identifies the step where users have concluded that the designed process is not worth engaging with directly.

In this failure pattern, the interface may have provided the information somewhere in the system. The failure is that the information was not available in a form the user could hold during the task.

How Creative Navy's Critical Systems Design method addresses memory demand

Creative Navy's Critical Systems Design method designs software whose interfaces, workflows, and operating logic carry real operational consequences, working through five phases — Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership — to take each system from initial exploration to independent operation by the client's own team.

Creative Navy's Critical Systems Design method addresses excessive memory demand by identifying the actual operating conditions before design decisions are made, then holding design standards against those conditions during system building.

In the Kardion engagement, Sandbox Experiments included clinical choreography sessions with cardiologists and nurses. These sessions documented the divided-attention conditions of cath lab and ICU use before visual and interaction decisions were made.

In the deSoutter Medical / Zethon engagement, human factors literature on gloved-hand performance, attention switching in dual-task conditions, and medical-device usability in clinical environments was reviewed and applied to design decisions.

In the Polymatica engagement, two weeks of daily structured exercises made the Creative Navy team productive OLAP users. That domain learning supported translation from the system's technical model into the operational terms users needed.

During Iterative System Building, the design standards were treated as requirements rather than preferences. In Kardion, the layout-stability standard was held through 18 sprints. In deSoutter Medical / Zethon, the recognition standard governed state communication decisions. In Polymatica, Concept Convergence replaced the cube metaphor, restructured the entry hierarchy around operational logic, and introduced a data preparation step.

Boundary with pressure-related failures

This failure is the precondition for pressure-related degradation, not the same failure as pressure-related degradation. Memory demand can exist in the interface before pressure rises.

When pressure rises, the user has less capacity to absorb memory demand. The related failure described as the interface getting harder when pressure rises concerns what happens when memory-reliant interfaces meet operational pressure. The present failure concerns the structural memory demand that was already built into the interface.

This failure is also distinct from the broader organisational pattern in which operators rely on memory too much. That broader situation describes what the problem looks like from outside the product. This page describes the interface mechanisms that create the compensation requirement.

Evidence basis and limits

The evidence for this failure pattern is grounded in documented examples from Kardion, deSoutter Medical / Zethon, and Polymatica. The examples cover regulated medical-device control, surgical-device interaction, and analytics-platform conceptual translation.

The Kardion evidence includes a Creative Navy-recorded 34-iteration count for the standard running view, a design standard of fixed element position across view transitions, and FDA approval with no design changes required. FDA approval is a regulatory result, not a measured usability outcome, and the page does not specify a regulatory pathway.

The deSoutter Medical / Zethon evidence includes six competitor devices benchmarked during Sandbox Experiments and structured review sessions with eight orthopaedic and trauma surgeons. The surgeon feedback is engagement-session evidence and is not described as post-deployment operational measurement.

The Polymatica evidence includes product analytics from real users in the live system. Independent task completion increased from 2% before redesign to 40% after release 1 and 56% after release 2. These figures support the conceptual-overload example, but they should not be generalised as expected results for all analytics platforms.