Connecting three professions in one ecosystem
In France, coordinating home nursing care still runs largely on informal habits, with texts between nurses, paper prescriptions and phone calls to pharmacies. AMME wanted to structure all of it in a single platform. The challenge wasn't to digitise an existing process, but to create one where none had ever existed, across professions that work very differently.
I was brought in for design and framing, so designing the product, specifying it and setting its architecture. Development and launch sat with the client. So what this case study shows is how I frame a problem and make decisions, not a product in production with its metrics.
Three professions, three logics that contradict each other
To understand what this product needed to be, I ran interviews with all three professions involved, nurses, pharmacists and patients. A fundamental tension came out of it, since their needs partly contradict one another.
The patient wants simplicity, zero effort. The nurse needs the opposite, a dense, fast tool that never makes her do the same thing twice, with a further nuance between self-employed and salaried practice, to handle inside a single interface. The pharmacy demands absolute reliability and precision, which imposes constraints on the other two.
Designing here wasn't about placing three interfaces side by side. It meant accepting that every decision has a cost somewhere. But before getting to those trade-offs, a more upstream question imposed itself. Were we solving the right problem?
Leaving the brief's ecosystem behind
The brief started from an interdependent ecosystem, with patient, nurse and pharmacy connected in one loop. I argued for the opposite, a standalone product first, and it's the decision I'm proudest of on this project.
Launching an ecosystem means having to convince three parties at once. Three concrete problems follow from that.
The first is the chicken-and-egg effect, this time with three parties. The pharmacy won't sign up while no nurse in the area uses the tool; the nurse won't sign up while no pharmacy receives her prescriptions; the patient only shows up if their nurse asks them to. Nobody moves first.
The third is regulatory. Making pharmacy, nurse and social security talk to each other requires end-to-end HDS certification, with timelines that stretch with every party added. A standalone product can be certified on its own, and faster.
On top of those structural arguments sat a market logic. Interdependent products form a fragile structure, and if one of them misses its launch, the whole thing collapses. Arriving on the market with a single product that creates value immediately is a far safer bet.
It took several framing sessions to get that direction adopted. The final decision was an application that centralises and delivers value even if the other parties aren't there yet, with the ecosystem features arriving later as additional layers. It reoriented everything that followed.
The prescription as the single point of entry
This is the decision that serves all three professions at once, and the one that best embodies the product's promise. Today the prescription travels on paper and everyone re-enters it. I argued for a single scan, where the prescription is captured once, then its information is passed automatically to the nurse and the pharmacy.
Harder to build, but it was the only choice consistent with the promise, don't digitise the mess, remove it. Simple for the patient, time saved for the nurse, reliability for the pharmacy. One decision, three needs served.
One calendar that adapts to context, not two interfaces
On the nurse side, I could have built two interfaces, one for self-employed and one for salaried. Simpler, but heavy to maintain and wrong in spirit, because a nurse is still a nurse, it's her context that changes.
So I designed a single calendar with a filter. By default she sees « All », can switch to « Me », and colleagues' appointments are visually identified when she works in a practice. Statuses are colour-coded for fast reading. The same screen serves a solo practitioner and a salaried nurse in a five-person practice.
A dense pharmacy interface, by choice
In a unified product, there's a temptation to harmonise interfaces visually. For the pharmacy, that would have been a mistake. I designed a kanban view on tablet, with three columns (pending, ready, collected), cards coloured by payment status, the prescription readable directly and two primary actions.
It's the densest screen in the product, and deliberately so, because pharmacists have the expertise to read it and they need it. Simplifying it would have turned it into a tool they'd work around within the first week.
The scope also covered a national back office (network oversight, regional statistics, scheduling, HR), onboarding for five profiles each with its own verifications (RPPS, SIRET, social security number) and a rounds-planning tool, as many workstreams as I'm happy to walk through in person.
Validating and iterating with the client and domain experts
The work didn't stop at the mockups. I had the interfaces validated by the client and by domain experts in test sessions, then iterated on ergonomics, functionality and how well the screens were understood. In a product where a nurse handles a prescription or a social security number, checking that an interface is not only usable but understood isn't optional.
Compliance as a design tool
Building GDPR and HDS in from the design stage, rather than at the end of the project, drove a lot of decisions, such as role- based access, data limited to the strict minimum for each interface, clear consent and care-sheet signing via CPS card. When you only show what the user needs, the interface gets clearer, not poorer.
What I take away
Designing in a regulated sector demands a kind of honesty that B2C doesn't. When an interface handles a social security number or a prescription, it isn't enough for it to be clear. The user has to understand what they're doing and why it matters. That's harder to achieve.
I also learned to question a brief, even one coming from the top. Moving away from the ecosystem model towards a standalone product challenged the original vision, but it was necessary. Part of the job is being able to say that the right problem isn't the one you were handed, and to demonstrate it rather than assert it.
Had it shipped, the metric I'd have watched first wouldn't have been the number of nurses signed up, but their sustained usage. A nurse still active week after week proves the standalone product creates value on its own, which was the whole bet. A second signal would have confirmed the layered strategy, namely how often an active nurse brings in a second party, her pharmacy or her patients.
Finally, a project that doesn't ship teaches as much as one that does. Sometimes more, because you can't hide behind the result.