The System Fights The User Task
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.
The failure concerns misalignment between the system's workflow logic and the user's task logic.
The issue is distinct from excessive navigation overhead: a workflow can contain few steps and still impose the wrong sequence.
The issue is related to conceptual mismatch, but this page concerns task sequence, action order, and operational workflow logic rather than terminology alone.
One mechanism is task modelling from system logic, such as database objects, backend modules, or API structure.
A second mechanism is assumed user behaviour that has not been observed under real working conditions.
In the Dancerace / Jacko case, Sandbox Experiments found that users first needed to answer what they owed, what it cost, and what they had to do immediately.
Dancerace reported a 36% demo-to-paying conversion rate against a 15–20% industry benchmark and against Dancerace's own expectations; the evidence is client-measured and not independently verified by Creative Navy.
In the MSolutions case, Creative Navy received AV diagnostic training and performed four test jobs to understand the task sequence.
MSolutions reported that a key diagnostic workflow reduced from 26 to approximately 13 interactions, based on internal task walkthroughs and not independent measurement.
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.
The system fights the user task when software encodes a task model that does not match the logic of the work users are trying to perform. The interface may not produce an explicit error or block the user. The workflow may remain technically navigable while still requiring the user to translate, reorder, or work around the system's structure.
This failure is a workflow-level mismatch. The problem is not only that the user must remember terminology or interpret unfamiliar categories. The problem is that the available actions, the order of actions, and the navigational structure express a different operational model from the one users bring to the task.
Failure pattern: the interface encodes the wrong task model
The system fights the user task when the structure of the interface reflects how the system was built rather than how users think and work. The available actions, their order, and their placement in the workflow express an internal model of the task. When that model is inaccurate, users encounter a workflow that is almost right and persistently wrong.
The failure often appears as small but repeated friction. Features that should be reached directly require indirect paths. Actions that belong together are separated. A task that users understand in operational terms must be performed through system terms, such as objects, modules, or formal process steps.
The diagnostic signal is the gap between a demonstration sequence and real use. A developer's demonstration may work because it follows the sequence the system was built to support. Real users may return to check a specific state, adjust a particular part of a deployment, or manage work across locations in an order that the system did not encode.
Mechanism: task modelling from system logic rather than user logic
One common mechanism is a task model built from system logic rather than user logic. The interface presents the task through backend entities, database objects, modules, or implementation categories, so users must map their work onto the structure of the software.
A content management interface that treats playlists as database objects can require users to manage screen content through playlist-object operations. The user's task may be simple: what plays on which screen and when. The system's task model may instead require the user to create, edit, and manage playlist objects through a wizard. Returning to modify a schedule can require re-entering the wizard and navigating back to the relevant step.
The cost is not one isolated usability issue. Every interaction carries the translation cost between the user's model of the task and the system's model of the task.
Mechanism: assumed behaviour replaces observed behaviour
A second mechanism is a system model of user behaviour that was assumed rather than observed. The team may have genuine domain knowledge and a clear product vision, but still encode the wrong priority order, action sequence, or interaction meaning because the specific behaviour of users was filled in from intuition.
This form of the failure becomes visible when real behaviour diverges from the behaviour the system was designed to serve. Debtors may acknowledge invoices informally rather than follow formal confirmation steps. Technicians may skip an organisational mode and work directly from their own diagnostic sequence. Users may rely on workarounds even though features are present, because the system's model of the task does not match how the task is actually performed.
The source of the mismatch is specific, not generic. Users operating under time pressure, limited attention, and informal workplace norms may behave differently from the behaviour assumed in a product model.
Dancerace / Jacko: invoice workflows misaligned with user priority order
Dancerace / Jacko is a B2B invoice management and accounts receivable portal for small businesses. The portal manages invoice distribution, confirmation, dispute, and settlement across financiers, suppliers, and debtors. At the start of Creative Navy's engagement, Jacko was a greenfield product built on Dancerace's existing C3 backend.
A prior Dancerace wireframe showed a feature-complete dashboard with every capability presented at equal visual weight. In retrospect, that direction would have made the system fight the user because it showed platform capability before establishing what users needed to see first.
Sandbox Experiments identified a strict user hierarchy of needs through user testing, interviews, and prototype observation. Users first needed to answer three questions: What do I owe? What is my cost? What must I do right now? Until those questions were satisfied, users could not be mobilised for profile setup, advanced features, or upsell prompts.
Creative Navy's design response also addressed debtor behaviour. Real debtors did not always behave according to formal business norms. A debtor who expected to pay late might go quiet rather than open a formal dispute. A system that provided only formal confirmation and dispute mechanisms would have encoded behaviour that did not match real use.
The design allowed a debtor to change the status of an invoice to "accepted". This status created a symbolic acknowledgement without a payment commitment and without resolving a formal obligation. Suppliers could see whether each debtor had seen, accepted, ignored, or disputed each invoice. Informal financial behaviour became visible inside the operational model of the system.
Dancerace reported a 36% demo-to-paying conversion rate against a 15–20% industry benchmark and against Dancerace's own expectations. The evidence basis is client-measured against Dancerace's own tracking, six months post-release, and was not independently verified by Creative Navy.
MSolutions: module-based structure conflicted with the AV diagnostic sequence
MSolutions produces a diagnostic device that measures signal integrity, EDID data, HDCP status, resolution, and other parameters across multi-monitor installations. The previous interface was organised around the device's backend modules, so functions were grouped by internal categories that made sense from a development perspective rather than by the sequence used by a technician performing an AV diagnostic.
An earlier visual redesign changed colours and icons without changing the structural mismatch. The interface looked different, but technicians still had to follow the system's module sequence rather than their own diagnostic sequence.
Creative Navy received AV diagnostic training from MSolutions and performed four test jobs before design work. That domain learning made the mismatch explicit: the technician's natural diagnostic sequence was link integrity, EDID and HDCP verification, resolution and colour space per display, and consolidated confirmation. That sequence did not correspond to a navigational path in the module-based structure.
Creative Navy's design response treated the device as a guide through a standard AV diagnostic narrative. Each screen state pointed to the next logical diagnostic action rather than the next module in the system architecture. Parameters appeared only when they were relevant to the current step. The technician's sequence became the system's sequence.
MSolutions reported that the key diagnostic workflow reduced from 26 to approximately 13 interactions. The evidence basis is client-reported internal task walkthroughs, not independent measurement. MSolutions also reported that new users who previously required repeated coaching sessions could operate the device after a short guided introduction, and that large integrator customers formally reported smoother rollouts after the redesign.
How Creative Navy's Critical Systems Design method addresses this failure
Creative Navy's Critical Systems Design method addresses this failure through domain learning before structural design decisions are made. The relevant question is not only what the system contains. The relevant question is how users actually think about and perform their tasks under real conditions.
The failure is often invisible to the team that built the system because the team knows the product's internal logic and may also have domain expertise. What may be missing is empirical knowledge of specific behaviours, priority orders, and informal norms. These details are not reliably visible through product inspection or through user interviews that ask people to describe tasks in the abstract.
Creative Navy's Critical Systems Design method uses observation, prototype testing, and direct domain learning to compare the user's task model with the system's encoded model. In the Dancerace engagement, the hierarchy of needs was inferred from what users did during prototype observation and user testing. In the MSolutions engagement, performing four test jobs made the cost of navigating between module structure and diagnostic sequence explicit.
Boundaries: adjacent failures with different mechanisms
The system-fights-the-user-task failure is distinct from a task that simply spans too many screens or steps. A task can require more screen crossings than necessary while still following the user's logic. In that case, the main issue is navigation overhead. A system can also fight the user with relatively few steps if those steps are in the wrong order or require a wrong turn before the right path.
The failure is also distinct from an interface that demands too much memory. Memory demand can arise when terminology, structural metaphors, or conceptual organisation do not match the user's operational model. The system-fights-the-user-task failure concerns the workflow expression of that mismatch: task sequence, action order, and operational logic.
Evidence basis and limits
The evidence for this failure pattern is case-based. The Dancerace / Jacko example includes user testing, interviews, prototype observation, and a client-measured commercial outcome reported six months post-release. The 36% demo-to-paying conversion rate was measured by Dancerace against Dancerace's own tracking and was not independently verified by Creative Navy.
The MSolutions example includes Creative Navy domain learning through AV diagnostic training and four test jobs. The reported reduction from 26 to approximately 13 interactions came from MSolutions internal task walkthroughs and was not independently measured. The reported improvement in new-user operation and smoother rollouts was client-reported.
These examples support the documented mechanism: when a workflow encodes system logic or assumed behaviour instead of observed task logic, users must translate their work into the system's structure. The available evidence does not establish a universal quantitative effect for all systems that exhibit this failure.
- The system fights the user task when the interface encodes a task model that conflicts with the user's actual task logic.
- One mechanism is task modelling from system logic rather than user logic, such as database objects or backend modules.
- A second mechanism is a system model of user behaviour that was assumed rather than observed.
- In the Dancerace / Jacko case, Sandbox Experiments found that users first needed to answer what they owed, what it cost, and what they had to do immediately.
- In the MSolutions case, the previous interface was organised around backend modules rather than the technician's diagnostic sequence.
- Creative Navy's Critical Systems Design method addresses this failure through domain learning, observation, prototype testing, and direct task experience before structural decisions are made.
- Dancerace reported a 36% demo-to-paying conversion rate against a 15–20% industry benchmark and against Dancerace's own expectations.
- MSolutions reported that the key diagnostic workflow reduced from 26 to approximately 13 interactions.
- The Dancerace commercial outcome was client-measured against Dancerace's own tracking and was not independently verified by Creative Navy.
- The MSolutions interaction-count reduction was based on internal task walkthroughs and was not independently measured.
- The reported MSolutions changes in coaching needs and smoother rollouts were client-reported operational observations.
- The examples support the documented failure mechanism but do not establish a universal quantitative effect across all systems.