Time for a doctor to find relevant information and understand a patient’s medical history
15to30minutes
Case study
Dalvia Santé: Turning generative AI into a usable product for doctors
- Role
- Product Designer
- Year
- 2024 - 2025
- Team
- Healthcare Design Expert · Product · Tech · AI
Dalvia Santé is a generative AI product designed to help doctors navigate complex patient records faster. It generates summaries tailored to the context of care, surfacing relevant information from the patient record, and can prepare a discharge letter as a starting point for review.
When I joined the project, the need and underlying technology were already defined, but the product experience still had to be designed from the ground up: which use cases should we focus on, what information should be generated, and how could this technology fit into doctors’ actual workflows?
Because our primary users were hospital doctors, we also had to consider where the product would actually be used. Their work moved between consultations and patient visits across the hospital, so quick access to patient information could not depend on being at a desk. We therefore prioritised mobile as the main product experience.
I worked alongside a Healthcare Design Expert, Product, Tech and AI teams. We shared the research and main UX decisions, while I took more direct ownership of UI design, interaction design, high-fidelity prototyping, the mobile foundations and Design-to-Dev delivery.
The challenge
How can we reduce the time doctors spend navigating patient records, so they can spend more time with patients?
01Use cases
Turning AI technology into practical use cases for doctors
Dalvia was built around a clear idea: use generative AI to help doctors review patient information faster through generated summaries.
We already had a fairly clear idea of the experience we wanted to build. Before moving further, however, we set up a research phase with a panel of ten volunteer doctors.
The goal was to understand their workflows, needs and pain points, but also to confront our initial product assumptions with the reality of their day-to-day work.
One summary could not fit every situation
The information a doctor needed could change depending on their speciality, the consultation, the patient and what they were trying to understand at that moment.
A general summary could be useful, but sometimes they needed something much more focused.
We therefore adapted the experience so doctors could define what they wanted before generation: selecting the type of summary and, when needed, configuring the period, document types or categories of information the AI should take into account.
Doctors did not all navigate their day in the same way
The interviews also showed us that doctors did not all access patient information in the same context.
Some were preparing or conducting consultations, while others were reviewing patients currently hospitalised or moving between rooms during ward rounds.
We translated that difference directly into the product structure: from the home screen, doctors could quickly switch between hospitalised patients and consultation patients, rather than navigating through the same list regardless of context.
02Trust and control
Giving doctors control over what the AI generates
Once we understood what doctors needed from the product, another question became critical:
How do we use generative AI in a medical context without asking doctors to blindly trust what it produces?
We designed the experience around three principles: giving doctors control before generation, helping them verify the result afterwards, and making the limitations of the available data visible.
Control the generation
Doctors choose the type of summary they need and can define the context and information the AI should use before generation.
Instead of asking the system for a generic answer, the doctor keeps control over what the result is meant to help them understand.
03Prototype and field
Making the product real enough to test before development
Before development, we needed to answer two questions: could doctors actually use the experience we had designed, and was it robust enough to demonstrate outside the Design team?
A standard click-through prototype would not reproduce enough of the real product behaviour to answer those questions.
I proposed using ProtoPie, made the case for it with the team and built the high-fidelity prototype myself. It included a working patient search using realistic fictional data, keyboard input, account creation and OTP, generation states, scroll behaviours and micro-interactions.
I also designed it to work offline so we would not depend on event connectivity during demonstrations.
User tests
Testing it with doctors
We then tested the prototype with 7 doctors, using scenarios ranging from finding a patient to generating and reviewing a personalised summary.
The sessions were prepared and analysed jointly by the Design team, allowing us to identify where the experience still needed clarification or adjustment before moving forward.
Live demo
SantExpo 2024
The same prototype then became the main demonstration tool for SantExpo 2024, France’s major annual healthcare and social care event, while the product itself had not yet been developed.
I contributed to the pitch and demo scenario, then presented the product over three days to healthcare organisation leaders, CIOs and doctors. Across the event, we ran more than 80 demonstration sessions.
The demonstrations also generated a clear signal of interest: several hospital organisations expressed interest in joining the first establishments to test the solution.
04Foundation & delivery
Building the mobile foundations
La Poste Santé & Autonomie was a new Docaposte business unit, with its own visual identity and product needs. Docaposte already had Cobalt, its Design System, but at the time its foundations were primarily designed for web experiences and did not yet cover the mobile requirements we needed for Dalvia.
Rather than creating a separate Design System for La Poste Santé & Autonomie, I extended Cobalt for this new context. I built the mobile foundations Dalvia required, including typography, tokens and mobile components, and introduced a La Poste Santé & Autonomie theme while keeping the system connected to Cobalt’s existing foundations. The direction was reviewed with the Cobalt Design System lead to ensure continuity with the parent system.
This work started early in the project rather than after the experience had been designed. From the beginning, I involved the iOS and Android developers and the PO so that platform constraints, component behaviour and implementation considerations could feed directly into the system as the product evolved.
Color system
Accessible color tokens adapted to Dalvia’s healthcare identity and mobile interface needs.
Typography
Mobile type styles designed to maintain clear hierarchy and readability across the product.
Components
Reusable mobile components built and adapted from the Docaposte Design System foundations.
Grids
Responsive mobile layout rules providing consistent structure across screens and content types.
Icons
A shared icon language extended with healthcare-specific assets required by the product.
Accessibility
Contrast, interaction states and touch targets considered directly within the system foundations.
Preparing the experience for implementation
Once the main flows were stable, I prepared a dedicated delivery file covering screens, states and variants.
The high-fidelity prototype complemented the static specifications whenever behaviours or interactions were difficult to communicate through screens alone.
I then worked directly with the iOS and Android developers and the Product Owner during implementation, clarifying behaviours, reviewing components and checking the experience as it moved into the real product.
05 Results
Less time navigating records. More time for care.
The goal was never simply to generate summaries, but to reduce the effort required to understand a patient’s situation and prepare key documents. After implementation, the product showed a clear reduction in the time required for these tasks.
- To understand a patient record
- vs 15–30 min before
- To produce a discharge letter
- vs 15–30 min before
05Reflection
Designing AI also means designing how users stay in control
Dalvia evolved from a technology whose product experience still had to be defined into a structured experience, tested with doctors, demonstrated to its market and prepared for development.
The main lesson I took from the project is that, in a field as sensitive as healthcare, designing a good interface around an AI-generated result is not enough.
You also have to design the relationship between the user and the AI: what they can control, how limitations are made visible and how they can verify information before acting on it.
