Feature design
B2B2C Healthcare
COVID-19 Response
Telemedicine
COVID-19 made an existing product gap impossible to ignore.
Medstar and Medcard24
Two platform already supported doctors, clinics and patients, but the two platforms were not connected around remote care. Patients could not consult doctors remotely, request prescriptions online or communicate with healthcare providers outside physical appointments.
I joined as the Product Designer across the two products.
The initial direction was straightforward:
Build video consultations.
But research showed that a video-first solution could exclude some of the people who needed remote care most.
I helped the team shift from a video consultation feature to a connected telehealth ecosystem — within a six-week Phase 1 delivery window.
01 - Context
When healthcare suddenly had to move online
Two established healthcare platforms — Medstar (doctor MIS/EHR) and Medcard24 (patient portal, owned by SK-Telemed) — operated with no connection between them. Neither supported remote workflows. Patients could not consult doctors remotely, request prescriptions online, or communicate outside physical appointments. When COVID-19 lockdowns began, this became critical. Doctors were seeing 48-50 patients per 8-hour shift — around 10 minutes per patient — and regularly staying longer when complex cases demanded more time. High-risk and elderly patients could not access care safely in person, but there was no remote alternative.
The opportunity
The business needed to establish remote healthcare quickly — without knowing yet what the right telehealth model should look like. The obvious answer was video.
The real question was:
"Would video actually work for the people who needed remote healthcare most?"
Lockdowns made in-person care dangerous and unsustainable. Doctors were seeing over 150 patients a day with no remote alternative. Patients stayed home and went without care. The system needed a digital escape route, fast.
Doctor Burnout Risk
Unsustainable patient volume with no way to reduce in-person load
No Remote Option
The platform had no consultation flow outside physical visits
Elderly Patients Stranded
High-risk patients couldn't safely access care
Zero Scheduling Infrastructure
No digital way to manage or redistribute appointment load
02 - The Challenge
We had six weeks — and a lot we didn't know
My Role
I owned the end-to-end design process:
User research
User flows
UX Research
Information architecture
High-fidelity Design
Prototyping
Usability testing
Developer handoff
Team
I owned the end-to-end design process:
Sole Product Designer
1 Product Manager
1 Business Analyst
4 Developers
1 QA Engineer
Constraint
Phase 1 had to be researched, designed and delivered in six weeks.
Research, design and development therefore happened in parallel.
We couldn't spend months validating every assumption.
We had to identify the riskiest assumptions quickly, test them, and use the evidence to decide what was worth building.
03 - Research
The initial assumption was video
The team initially assumed that remote consultations would primarily happen through video.
I focused research on three questions:
1.
Could patients actually access video consultations?
2.
Would different patient groups be comfortable using video?
3.
What would doctors and clinics need to make remote care operational?
The research surfaced an important constraint:
A significant proportion of patients did not have access to webcams.
For some elderly users, video and messaging technology also introduced additional barriers.
This meant that simply reproducing an in-person consultation through video would not create an inclusive remote-care experience.
A video-first experience would have excluded the patients who needed remote care most. Chat had to become a first-class channel, not a fallback.
Research synthesis & Ideation
Mapping insights to Action
Consolidating primary clinical insights from over 40 user interviews to prioritize product features for the remote care platform launch.
Research Finding
User Need
Design Opportunity
Many patients didn't have webcams or struggled with video technology.
Access care in a way that works for them, not just video.
Offer chat consultation alongside video as an equal option.
Elderly patients needed simpler, less technical experiences.
An experience that feels easy, safe and guided.
Simplify flows with clear guidance at each step.
Doctors were overwhelmed with in-person visits and repetitive follow-ups.
Spend more time on patients who truly need in-person care.
Enable effective virtual consultations and follow-ups.
Remote care created scheduling complexity for clinics.
Coordinate availability and manage capacity smoothly.
Introduce admin tools to manage availability & confirm schedules.
Patients needed prescriptions and care continuity without visiting the clinic.
Receive prescriptions and continue care remotely.
Digital prescriptions, access to care & history in one place.
Criteria
Insight
Webcam or good device required
Accessibility (hearing, motor, etc.)
No single channel works for every patient or every consultation type. We designed both.
04 - The Product Decision
Video-first wasn't enough
The research changed the direction of the product. Instead of treating video as the default and other channels as secondary, I advocated for a broader model:
Video + Chat
Chat became a first-class consultation channel rather than a fallback. This was an important shift in thinking.
We were no longer asking:
How do we put a consultation on video?
We were asking:
How do we make essential healthcare accessible remotely through different channels?
That distinction influenced the product architecture, not just the UI.
05 - Expanding the Problem
Remote healthcare wasn't only a patient–doctor problem
As I mapped the wider journey, another gap became visible. Patients needed to book and attend consultations. Doctors needed to manage those consultations. But someone also needed to coordinate schedules and operational workflows.
The original concept was primarily focused on:
Patient
Doctor
I introduced the need for a third workflow:
Patient
Administrator
Doctor
This expanded the product from a communication feature into a connected service.
The product evolved through three shifts
Video-first
Video
Chat
Patient
Doctor
Patient
Administrator
Doctor
Consultation feature
Connected telehealth ecosystem
This was the most significant product-level contribution I made on the project.
A connected telehealth ecosystem
We connected Medcard24 (patient app) and Medstar (clinical platform) and introduced admin workflows to deliver a complete remote care experience.
Patient
Find doctor
Book appointment
Video / Chat consultation
Receive prescription
Follow-up care
Medcard24
(Patient App)
Search & discover
Manage appointments
Video / Chat interface
Messages
Prescriptions
Secure
Sync
Medstar
(Clinical Platform)
Patient records
Clinical context
Consultation outcomes
Prescriptions
Analytics
Doctors
View schedule
Consult patient
Create prescription
Follow up
Clinic Admin
Manage availability
Confirm schedules
Coordinate care
ECOSYSTEM EXPANSION
IDIS2GO (Remote Diagnostics)
Show2Doc (Doctor–Patient Communication)
Additional services for a seamless care journey
06 - What I Designed
Connecting the experience across the ecosystem
The goal was not to create three isolated experiences. It was to make the workflows work together.
07 — Designing Under Pressure
Research, design and development happened together
With six weeks for Phase 1, there was no traditional sequence of:
Research
Design
Development
Instead, the team worked iteratively.
I used research to identify the highest-risk assumptions, designed flows around them, tested where possible, and worked directly with developers to resolve constraints as they emerged.
This meant constantly balancing:
User needs
Healthcare workflows
Technical feasibility
Six-week delivery constraint
My role was therefore not only to produce screens.
I helped the team decide what not to build, what needed to change, and what had to be prioritised first.
Clinics — Bethel Hospital Berlin, available booking slots. Patient-side booking infrastructure.
Schedule — February 2021, full week view, colour-coded appointments. Admin persona managing load.
08 — The Experience
From disconnected tools to connected care
Before the project, patients and healthcare teams relied heavily on physical workflows.
Instead, the team worked iteratively.
I used research to identify the highest-risk assumptions, designed flows around them, tested where possible, and worked directly with developers to resolve constraints as they emerged.
Before
Consultations
In-person visits only · Exposure risk for everyone during lockdown
Appointment Booking
Call the clinic during working hours · Long queues, no visibility
Patient records
Paper files · No digtal access for patients or remote doctors
Doctor workload
150+ patients daily · No way to redistribute or reduce load
After
Consultations
Video callor chat from home via Medcard24 app · No exposure
Appointment Booking
Book online anytime. Admin manages schedule via Medstar dashboard.
Patient records
Full EHR in-app. History, prescriptions, and treatment plans in one place.
Doctor workload
Doctor workload: Distributed across remote and in-person. Offline visits reduced by 48-51%.
The important change was not one new feature.
It was the connection between these workflows.
09 - Impact
The product became part of a much larger healthcare ecosystem
The immediate goal was to establish remote healthcare during lockdown.
The longer-term product reached significant scale.
37K+
Physicians on platform
120K
Appointments/Day at peak
4.8
App Store rating
48%
reduction in offline visits
The wider Medcard24 ecosystem subsequently expanded into additional healthcare services, including wellness tracking and medication delivery.
The longer-term product reached significant scale.
10 - The Real Outcome
Research changed what we built
The most important outcome wasn't simply launching telehealth. It was changing the product direction before scaling the wrong solution.
We started with:
“Let's build video consultations.”
Research showed that video alone would not serve all patients effectively.
The product evolved into:
“Let's create accessible remote healthcare across multiple channels and connect the workflows behind it.”
That changed:
The consultation model
The product scope
The users we designed for
The operational workflows
The relationship between Medstar and Medcard24
The key shift
From communication feature → connected healthcare service
11 - What I Learned
Senior product design is often about changing the question
This project reinforced something I now apply to complex product problems:
The designer's job isn't simply to optimise the solution they're given. It's to challenge whether that solution is solving the right problem.
The initial brief pointed towards video consultations.
Research showed that this assumption could create accessibility and adoption barriers. The insight changed more than the interface.
It changed what the team decided to build.
I also learned that complex products cannot be designed around the visible user journey alone.
Patients and doctors were only part of the system. The operational workflows behind them were equally important.
12 - What I Would Do Differently
Validate the riskiest assumptions earlier
The project moved extremely quickly, but several important discoveries happened after the initial direction had already been established.
Today, I would front-load three areas.
01 — Device access
Validate hardware and connectivity constraints before committing to a video-first concept.
02 — Accessibility
Include elderly users and low-tech scenarios as explicit research criteria from the beginning.
03 — Operational workflows
Map administrators and clinic operations alongside patient and doctor journeys from day one.
This would allow the team to identify the ecosystem-level constraints earlier and reduce rework during the six-week delivery window.
The Takeaway
I didn't just design a telehealth feature.
I helped change the definition of the problem.
We started with a simple assumption: Healthcare needs video consultations.
We ended with a broader product model: Healthcare needs connected, accessible remote-care workflows across patients, doctors and healthcare teams.
That shift — from designing the requested feature to influencing what the product should become — was the most valuable contribution I made to the project.
