Case study Doctor.One

Reframing the problem.

Doctors weren't inviting patients to the app. So I stopped calling it an invitation — and reframed the entire onboarding flow as sending a message. The friction disappeared.

Role
Sole designer
Scope
Research → handoff
Platform
Two iOS apps
+50%
invites sent
Old flow — an 'Invite patient' screen
New flow — a doctor sends a message instead of an invitation

Doctor.One is a medical messaging platform built around direct, ongoing communication between doctors and patients — continuous care instead of the appointment-based model.

Two apps — one for doctors, one for patients
Continuous care, not appointment-by-appointment
One onboarding flow, redesigned end to end
My role

I was the sole designer on this feature. I sat in on doctor interviews to understand the problem firsthand, designed the entire new flow from scratch, built an interactive prototype for testing, and worked closely with the PM and developers through implementation.

The strategic direction came from the team. My job was to turn that direction into a product that actually works.

My involvement
Research
Flow design
Prototyping
Dev collaboration
Implementation
The problem
“I just don't know when to bring it up.”
— from doctor interviews

Doctors weren't inviting patients to the app. When I talked to them, the answer was surprisingly simple: they didn't know when to do it — and they were afraid of rejection. A doctor is not a salesperson. Proposing a new tool during a consultation felt uncomfortable, and the product reinforced that discomfort.

Buttons labeled “Invite patient” or titles screaming “Add new patient” implied the patient could say no. Nobody likes the feeling of being rejected.

Old screen with an 'Invite patient' button
“Zaproś pacjenta” = “Invite patient”
The old flow

Five steps that ended in silence.

Home → “Add patient” → enter phone number → choose care type → choose plan → success screen. After the last screen, the doctor had no idea what happened next. No follow-up. No continuation. Just the feeling of having sent something into the void.

Doctor home
01  Home — “Add patient”
Enter the patient's phone number
02  Enter phone number
Choose care type
03  Choose care type
Choose plan
04  Choose plan
Success screen — then silence
05  Success — then silence
The decision

Stop treating it as an invitation. Treat it as a message.

We identified the core insight and I redesigned the entire flow around that new mental model. New name. New entry point. New way of thinking.

The new flow

Starts where the doctor already is - in a conversation.

Home → “New chat” → enter phone number → a chat screen with plan selection and a pre-filled message → send. The doctor creates and sees the chat immediately, even before the patient registers an account. No silence. No void.

Inbox — start a new chat
01  Inbox — “New chat”
Enter the patient's phone number
02  Enter phone number
Choose a care plan and send the message
03  Choose plan & send
Message sent — the chat is created instantly
04  Message sent
Why it works

A doctor doesn't invite a patient. A doctor sends a message.

That's a fundamental difference. Sharing medical recommendations is a natural part of the doctor–patient relationship. It doesn't require a special moment, and it carries no risk of rejection.

The old model
“Invite a patient”

Implies the patient can say no. Needs a special moment. Feels like selling — and carries the risk of rejection.

The new model
“Send a message”

A natural part of care. No special moment required, no risk of rejection — the doctor simply continues the conversation.

The outcome

The best UX makes the problem disappear by changing the context.

Doctors who weren't sending invitations started simply writing messages instead - and invites sent rose 50%. The feedback was clear: this felt natural. The friction was gone.

What they say

He doesn't just “execute tasks,” but challenges the status quo and proposes innovative solutions that we hadn't even considered, often spotting opportunities to improve the product before they become issues.

Maciej Malenda · CEO, Doctor.One
Read the full letter
Next

Building a design system to scale.