When the MVP Lied: Deep Systemic Design in a Hospital Setting
A MVP that works well is sometimes the worst starting point for a product. It validates a hypothesis under ideal conditions, with engaged users, within a controlled scope. When the time comes to scale, conditions change, and the cracks appear. This case explores how deep systemic analysis lets you read those cracks correctly.
The Context: Vigil, a Care Team Coordination App
Fictional case
Vigil — Care Team Coordination in a Hospital Ward
The product: A mobile application for care teams in an internal medicine ward. It centralizes end-of-shift handovers, priority patient alerts, and nurse-physician coordination.
The MVP: Deployed on a single pilot unit of 12 volunteer caregivers over 4 months. Encouraging results: 87% of handovers completed in the app, positive user feedback, handover time reduced from 18 to 9 minutes on average.
The problem: When deployed across 6 additional units, adoption collapses. 8 weeks after launch, only 34% of handovers go through Vigil. Teams revert to paper notebooks and WhatsApp groups.
The natural reaction to this situation, in most product teams, is to look for the problem in the interface: maybe the onboarding is too long, the notifications poorly calibrated, the transmission form too complex. You open Hotjar, look at heatmaps, schedule user tests. You sketch an improved flow.
That is a level 2 mistake. Here is why.
Applying the Four Levels to the Vigil Case
Level 1 — The observable event
Adoption collapses at broader deployment
34% effective usage vs. 87% during pilot. Caregivers across all 6 new units revert to prior practices despite training.
Flow-first reading
Onboarding problem, UX too complex, poorly calibrated notifications. Optimize the app entry flow and the handover form.
Level 2 — Recurring pattern
Workarounds are identical across all units
In every unit, the same behavior: the app is used for formal handovers (audited ones), but WhatsApp remains the real channel for real-time coordination. Paper persists for quick notes between caregivers.
What it reveals
This is not a UX problem specific to one unit. It is systemic behavior. The same workaround strategy emerges independently in each context.
Level 3 — Structure
The app was designed for auditors, not caregivers
Tracing the product genesis reveals that functional requirements were defined by the nursing directorate and quality department, in response to regulatory traceability obligations. The in-app handover is primarily a document, not a communication tool.
What it reveals
The product serves two incompatible needs in the same interface: rapid coordination (caregiver need) and formal traceability (institutional need). Caregivers rationalized: the app for what gets audited, WhatsApp for what is useful.
Level 4 — Root belief
"An undocumented handover never happened"
The deep institutional belief: a handover's value lies in its traceability, not its operational effectiveness. Coordination that is not in the system does not legally exist, therefore it does not count.
What it reveals
Caregivers know that documentation does not equal communication. The low adoption rate is not a user failure. It is a rational resistance to a tool that primarily serves the institution, not patient care.
"The low adoption rate is not a user failure. It is a rational resistance to a tool designed for the institution, not for care."
Why the MVP Had Lied
The pilot unit was composed of volunteers: motivated caregivers, already convinced of the utility of a digital tool, with a head nurse championing the project. In this context, the level 4 institutional belief was neutralized by individual enthusiasm.
At scale, the new units had no internal champion. The caregivers had not chosen the tool. And the structural pressure of level 3, regulatory traceability, took over. The MVP had not validated the product. It had validated that highly motivated people can make any product work.
The warning signal you must not miss: when a MVP relies on volunteer, engaged users, it tests the resistance to change of those who already want to change. The real test begins when users did not choose to be there. That is precisely the moment where the minimum viable depth, going down to level 4 before launching iterations, makes the difference between a deployment that confirms and a deployment that reveals.
The Meeting That Would Have Changed Everything
Here is what the scene looks like when you reach level 4. Three weeks after the failed deployment, a meeting is called. Around the table: the nursing director, the head nurse from the pilot unit, the product lead, and two nurses from units where adoption failed.
The product lead opens with the numbers. 34%. He proposes simplifying the form and reworking the onboarding. The nursing director agrees: they should also plan an additional training session.
It is one of the nurses who interrupts, almost shyly: "Actually, we do use the app. For the morning transmissions, the ones management reviews. But to talk to each other during a shift, we stay on WhatsApp. It is faster, you can correct things, you can ask a question. In the app, once you have written something, it is written."
Silence. The head nurse from the pilot unit recognizes the same behavior in her unit. She had not mentioned it because the adoption metrics were good.
The nursing director rephrases slowly: "You mean we have two different needs and we put them in the same tool." It is not a question.
That is where the conversation shifts. No longer about UX. About what the institution actually wants to trace, and what caregivers actually need to tell each other. The decision to separate the two modes does not come from the designer. It emerges from the room, once the right question has been asked.
This moment would not have existed if the product team had arrived with a new version of the form. Minimum viable depth is also this: creating the conditions for the real conversation to happen, rather than avoiding it behind a redesign.
What the Redesign Would Have Produced Without This Diagnosis
Likely result: marginal improvement in adoption, persistent workarounds. The level 4 problem remains intact.
Expected result: reconciliation of both incompatible needs. Adoption can grow without asking caregivers to choose between efficiency and compliance.
What This Case Teaches About the MVP-to-Product Transition
A MVP validates under conditions, not universally
Pilot users are never representative of users at scale. Their engagement neutralizes systemic resistances that the next users will have no reason to overcome.
Uniform workarounds are the best level 3 signal
When all users independently invent the same workaround, it is not a training gap. It is proof that a deep structure makes the workaround rational.
Institutional and user needs do not merge
Trying to satisfy both in the same flow always produces a tool that serves both poorly. Explicit mode separation is often the only honest design decision.
Level 4 shifts the product conversation
Naming the root belief forces a conversation nobody wanted to have: who does this product actually serve? That is not a design conversation. It is a governance conversation.
Parent article
Deep Systemic Design: Don't Draw a Flow Before Finding the Cause
---
Methodological note: The Vigil case is entirely fictional. Data, context, and characters are simulated for pedagogical purposes. Any resemblance to an existing product would be coincidental. The four-level analysis framework draws on the work of Donella Meadows (Thinking in Systems, MIT Press, 2008) and causal loop analysis principles applied to product design.