Multi Role Workflows Are Fragmented

Multi-role workflow fragmentation in complex software

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.

Multi-role workflow fragmentation occurs when a system serves users with genuinely different tasks, operating rhythms, and consequence profiles. A single interface architecture can serve one role well while creating friction for others, especially when the product was first shaped around one role's mental model and later extended for additional roles.

The fragmentation is often not visible as a deliberate design decision. It accumulates through extensions, patches, and compromises. Users in underserved roles create workarounds, the workarounds become habitual, and the operational cost of the mismatch becomes harder to see.

This situation is common in products where users share a system but not a task. The examples described here include enterprise SaaS platforms used by planners, operators, and field technicians; clinical devices used by surgeons and nurses from different physical positions; and practice management software used by receptionists and clinicians in different operational modes.

Why feature additions do not resolve structural role conflict

Multi-role workflow fragmentation is not resolved by simply adding features for underserved roles or reorganising navigation. Those changes address symptoms when the underlying question is architectural: do the roles share a task model that one interface can support, or are the operating rhythms and consequence profiles different enough that one architecture will degrade at least one role?

When teams treat those two conditions as the same, the common failure mode is a sequence of feature additions and layout adjustments. Each adjustment may improve the product for one role while increasing friction for another. The product changes, but the underlying architecture remains unclassified.

Creative Navy's Critical Systems Design method treats role conflict as evidence to classify before design direction is chosen. The important distinction is whether the issue belongs at the interaction-pattern level or at the interface-architecture level.

Workarounds distinguish unified-model issues from architectural failures

Observed workarounds are the main signal for distinguishing a unified-model issue from an architectural failure. Stated preferences are not enough, because users usually ask for improvements inside the interface they already know rather than asking for an architecture they have never seen.

Task-specific workarounds suggest that different roles are encountering the same interface problem in similar ways. In that condition, the underlying task model may be shared, and the unified interface can be improved by fixing the interaction pattern or information hierarchy.

Role-specific workarounds suggest that each role has developed a distinct coping strategy because the interface fails each role in a different way. In that condition, the issue is not only interaction design. The interface architecture is likely wrong for at least one operating mode.

Unified model when roles share workflows but need different information hierarchy

A unified model is appropriate when roles share workflows but have different information priorities. The conflicts are about what should be prominent, what should be accessible, and in what order. The task structure is shared even if the role priorities differ.

In a unified-model resolution, the design work is concentrated in information architecture and information hierarchy. The product does not need to be split into separate interfaces if one structured interaction model can represent the shared workflow while making role-specific information priorities legible.

Creative Navy's Critical Systems Design method uses microtask analysis to examine discrete tasks independently of assumed sequence or flow. In this situation, microtask analysis helps identify whether apparent role conflict is actually a hierarchy problem inside a shared workflow.

Architectural separation when roles operate in incompatible modes

Architectural separation is appropriate when roles operate in different modes with different physical environments, time structures, consequence profiles, and mental models of what the software is for. In that condition, no information hierarchy can resolve the conflict because the roles do not share the same task model.

Separate interfaces for separate modes are not described here as a failure of design ambition. They are the correct response when observation shows that a unified architecture would optimise for one role while degrading another.

Creative Navy's Critical Systems Design method uses tension-driven reasoning to identify what drives each role conflict. The output is not automatically a unified design direction. The output is a classification: unified model or architectural separation.

Three enterprise roles resolved through a unified model in Triopsis

The Triopsis Workforce Management SaaS case is described as a unified-model resolution for three roles in one workforce management interface. The roles were schedulers planning thousands of weekly interventions and coordinating crew availability, operations managers scanning for exceptions and managing risk across broader time horizons, and field technicians performing tasks outdoors with gloves, in sunlight, under time pressure and interruption.

The role conflicts were concrete. A layout optimised for schedulers emphasised speed, batch actions, and immediate team availability, but it hid exception signals that operations managers needed. A structure that reassured field technicians by surfacing required steps and safety confirmations obscured timing data that planners needed for sequencing decisions.

Creative Navy-recorded case evidence included 43 user interviews across 21 participants and three in-situ observation sessions. That evidence showed that the conflicts were not only preferences in disagreement. The conflicts reflected the organisation's task structure as it appeared in the interface.

Creative Navy's Critical Systems Design method classified the Triopsis case as a unified-model problem because the roles shared the same workflow. The roles operated it at different speeds, with different information priorities, and with different tolerance for uncertainty. The task structure was shared, so a single carefully structured interaction model could serve all three roles.

Creative Navy-recorded design work in the Triopsis case mapped 47 microtasks against three personas. Product analytics from real users in the live system recorded 62% faster job discovery, 83% faster job sequence optimisation, and 58% faster weekly planning.

Clinical role differences resolved through one Kardion MCS Controller screen

The Kardion MCS Controller case is described as a unified-model resolution for clinical roles using one screen in different physical positions. The controller is used during cardiac procedures and for longer-term cardiogenic shock support.

Two groups used the same device screen simultaneously. Scrub nurses and perfusionists stood approximately 3 metres from the controller during procedures and monitored motor current and device positioning signals. ICU nurses worked close to the controller and monitored flow rate, arterial blood pressure, and run time over longer care episodes.

The role conflict was spatial as well as informational. A hierarchy optimised for surgical-distance reading made elements large enough to read at 3 metres without diverting attention from the patient, but those same elements became visually dominant at close range. A hierarchy optimised for close-range nursing monitoring made elements too small to read reliably from 3 metres under time pressure.

Creative Navy's Critical Systems Design method treated the fixed physical choreography of clinical use as the basis for the screen hierarchy. Elements critical to surgical-distance reading were large enough to be legible at 3 metres. The detail layer needed for close-range nursing monitoring remained present at a scale legible nearby but not dominant at distance.

This resolution is described as layout logic grounded in observed clinical practice, not responsive design. The Kardion MCS Controller received FDA approval, passing regulatory evaluation as submitted with no design changes required. That regulatory result is not a measured usability outcome and does not specify an FDA pathway.

Reception and clinical modes separated in IDEXX Animana

IDEXX Animana is described as an architectural-separation case after eleven years of serving reception staff and clinical staff through a single interface. The evidence described here comes from field research across 35 clinics, 150+ participants, and 3 countries.

Receptionists worked in an ambient awareness environment. They handled multiple simultaneous demands, short task windows, constant context-switching, and error consequences visible immediately to waiting clients. Their cognitive requirement was breadth, speed, and error prevention through simplicity.

Clinical staff worked in focused, sequential case attention. Vets and nurses handled one case at a time, with sufficient time available and error consequences that were clinical rather than reputational. Their cognitive requirement was depth, completeness, and accuracy.

The workarounds in Animana were role-specific. Receptionists had developed coping strategies for managing multiple animals per client at a glance. Clinical staff had developed strategies for avoiding the interface clutter that a reception-oriented layout imposed on consultation screens.

Creative Navy's Critical Systems Design method classified the Animana situation as architectural separation rather than unified-model redesign. The recommendation was to develop distinct interfaces for reception and clinical roles because a unified interface optimised for either role would degrade the other.

How Creative Navy's Critical Systems Design method classifies the resolution

Creative Navy's Critical Systems Design method addresses multi-role fragmentation through the Sandbox Experiments phase. In this situation, Sandbox Experiments maps the workflows of all roles before design decisions are made.

Microtask analysis documents discrete tasks independently of assumed sequence or flow. That practice reveals whether role conflict is interaction-level or architectural. Tension-driven reasoning then identifies what drives each conflict: shared task model with different information priorities, or structurally incompatible operating modes.

The output of this analysis is a classification rather than a design direction. A unified model is appropriate when the roles share workflows and need different hierarchy. Architectural separation is appropriate when role-specific workarounds show incompatible modes and mental models.

Without this classification, design effort is directed at the wrong level of the problem. Interaction-level fixes cannot resolve an architectural mismatch, and architectural separation is unnecessary when a shared task model can be served through a better hierarchy.