Pana Health — Patient Onboarding

Pana Health is a Spanish telemedicine startup connecting patients with general practitioners and specialists via video consultation. Launched in 2021, by 2023 they had validated product-market fit and were scaling — but their onboarding funnel had a significant problem: 62% of users who downloaded the app never completed their first booking.

The Problem

The onboarding flow asked users to complete a 12-screen intake process before they could book their first consultation. The process was designed by the clinical team, not the UX team — and it showed. Every screen was dense, formal, and structured like a medical form rather than a consumer app.

• 12 screens before reaching the booking calendar — most competitors had 4–5
• Medical language used throughout ("presenting complaint", "comorbidities") instead of plain Spanish
• No progress indication — users didn't know how far through they were
• Required fields that weren't actually clinically necessary for a first consultation
• The highest drop-off point: screen 7, which asked for insurance information before showing any value

My Role

I was responsible for the full UX redesign of the mobile onboarding flow — from audit and research through to final prototype and Maze usability testing. I collaborated with the clinical team to understand which data was genuinely required upfront and which could be collected progressively.

I combined three research methods to understand the drop-off:

1. Funnel Analysis

Using Hotjar, I mapped exactly where users abandoned. Screen 7 (insurance) had a 38% exit rate. Screen 4 (health history) had a 22% exit rate. The rest were spread across the remaining 10 screens.

2. Exit Interviews

I conducted 8 user interviews with people who had dropped off. The dominant theme: "I didn't know what I was signing up for yet, and it was already asking me for so much." The app asked for trust before it had earned it.

3. Clinical Requirements Audit

I worked with the medical director to identify which fields were mandatory for patient safety and which were "nice to have" at intake. The result: only 4 fields were genuinely required before a first consultation. Everything else could wait.

Progressive disclosure, not front-loaded forms

1. Reduced Mandatory Upfront Screens: 12 → 5

The new flow required only 5 screens before showing the booking calendar: name, date of birth, reason for visit (free text), preferred language, and a consent checkbox. Everything else — insurance, full health history, recurring medications — was requested progressively, after the patient had seen the product's value.

2. Plain Language Rewrite

I rewrote every label and instruction in collaboration with the content team. "Presenting complaint" became "What brings you in today?" "Comorbidities" became "Do you have any long-term conditions?" — with examples. Reading complexity dropped from medical-professional level to accessible consumer language.

3. Progress Indicator

A simple 5-dot progress bar at the top of each screen. Small change, significant psychological effect — users knew they were making progress and could see the end point.

4. Insurance Repositioned

Insurance details moved to after the first booking — surfaced as an optional step on the confirmation screen with clear framing: "Add your insurance to reduce costs on future consultations." Users who had already committed to a booking were far more willing to provide this information.

5. First-value Moment

After screen 5, users landed directly on the available appointments calendar — showing real doctor profiles, specialities, and availability. The first experience of the product was the product, not a gate.

• Clinical requirements: The medical team initially resisted removing health history from upfront onboarding. We agreed on a middle ground — collecting reason-for-visit as a free text field, with structured health history collected by the doctor before the consultation.
• GDPR compliance: The consent screen had to meet legal requirements without becoming a wall of text. I worked with the legal team to create a consent flow that was complete without being intimidating.
• Insurance revenue: The product team was concerned that moving insurance collection post-booking would reduce insurance-linked revenue. We agreed to test with a 30-day holdout — the conversion rate on insurance capture actually increased by moving it to post-booking.

• Onboarding completion rate improved from 38% to 69% in the 6 weeks following launch.
• The average time-to-first-booking dropped from 8 minutes to under 3 minutes.
• User feedback shifted — "too complicated" complaints in app store reviews dropped significantly.
• The progressive insurance capture flow outperformed the original mandatory flow — patients who had experienced the product were more willing to share their coverage details.