Rebuilding a telemedicine patient app in 30 days
First product designer, design lead and product owner
Three month engagement (April to July 2026) for a digital health company that equips pharmacies with telemedicine booths. As the company's first product designer, I rebuilt the patient app with a tech lead and two developers, while laying down a design system, a product management system and the design framework of an AI assistant that is not allowed to diagnose.
The business model depends on the number of consultations actually started. A patient who enters the funnel and drops out has already cost their acquisition. Over a year, 80% of patients consult only once: nothing in the journey gives a reason to come back once the prescription is delivered. The organization did not help: no design function, a component library frozen for more than a year, product management scattered across several tools, a shrinking product team and a very tight budget. On June 15, leadership set two priorities, consultation volume and the mobile app, with a store submission on July 15.
A review of the existing app in early June found four problems that a patch could not fix: a fragmented session (signed in to the app, signed out of the consultation), a double navigation, a home screen that reorganized itself around the connected devices in use, and a funnel of 8 to 13 screens including a health insurance screen that only 3% of patients managed to complete. The architecture followed stacked features rather than the journey. Stripping the shell would have kept the embedded web view, and with it the double session: a rebuild was the only option.
I removed what was most attractive. The first version refocuses the app on online consultation: connected devices, health metrics, AI analysis and the subscription are out of scope. Economic reason: the consultation is reimbursed and monetized by volume. Regulatory reason: these features exposed the product to a medical device requalification, with an 18 to 36 month certification against a 30 day deadline. I carried this removal to a leadership team that cared about these features.
The health insurance screen leaves the funnel in favor of an advance payment and a clear explanation of reimbursement. A screen with a failure rate close to 100% does not collect data, it manufactures drop-offs. My first hypothesis, delaying authentication until the waiting room, was abandoned and documented: checking entitlements with the national health insurance requires identification before the patient is connected.
The AI assistant is not allowed to diagnose. Instead of a clause in the terms of use, the limit is visible in the interface: a permanent scope banner, an imposed answer structure (information, context, action), escalation to a doctor triggered by the content of the conversation and never by a counter, and refusal designed as a journey with a real way out. Two home buttons ("describe a symptom", "understand a prescription") were removed: an affordance is a promise, and these announced a medical act. The non-medical framing was validated by the data protection officer, with data anonymized before it is sent to the model.
On the design system, a full migration of the existing Angular library was out of reach without a design team or a budget. I built a new system in parallel, with a shared token vocabulary, for everything new: two repositories, nearly 90 components, 12 color ramps, a 13 level type scale and layouts for three contexts (desktop, mobile, booth tablet). Accepted cost: two brand greens coexist for a while, with a written precedence rule. A Claude Code skill pack generates code aligned with the system: without a design team, governance goes through the tool rather than the document.
The patient app was rebuilt in React Native, reusing the native building blocks of the consultation. Mockups were presented to developers 48 hours after the decision, with one week sprints and a testable demo at the end of each, and three builds in two weeks. The specification has 7 epics, 24 user stories and eight screen sections with their four states (empty, loading, data, error). In the waiting room, no waiting time is ever displayed: the position changes continuously, and a frozen number would lie and ruin trust in the rest of the screen.
On product management, I audited six databases (three incompatible priority scales), moved tracking from Jira to Notion into four databases linked by a single chain, requalified 92 inherited requests and opened an intake form to the whole company. The model was tested on fifteen real situations before rollout: four pass, eleven get stuck, seven fixes. Documented handover to a junior product owner. A ten slide vision deck presented to the executive committee obtained two decisions: a single app with care and prevention sequenced, and a priority order between programs, pharmacy and connected devices.
What is not measured: the app was not yet published when I left, the design system has no adoption measure, the product management system had been live for a week and the assistant was never opened to the public. The funnel redesign remains a reasoned hypothesis until step by step completion is tracked. Still open at handover: the exact regulatory qualification of the app, a session bug that signs the user out fifteen minutes after a consultation, and a passwordless authentication never tested in production.
What I would do differently: set up measurement before the funnel redesign (completion by step, drop-off, assistance time in the pharmacy), get the technical confirmations the store listing depended on in the first week, instrument design system adoption from its first version, and write the product management governance before configuring the tool.
