Feature design
B2B2C Healthcare
COVID-19 Response
Telemedicine
Medcard24 was the patient-facing platform for finding doctors, booking appointments and managing care. Medstar supported doctors and clinics with clinical workflows and patient information. They had no connected remote-care workflow.
Context
When healthcare suddenly had to move online
Medstar and Medcard24 were two established healthcare platforms supporting doctors, clinics and patients — but they were not connected around remote care.
Patients couldn't consult doctors remotely, request prescriptions online or communicate with healthcare providers outside physical appointments.
When COVID-19 lockdowns began, this became critical.
Doctors were seeing extremely high patient volumes, while elderly and high-risk patients needed to avoid unnecessary visits.
The business needed to establish remote healthcare quickly — without yet knowing what the right telehealth model should look like.
The obvious answer was:
Build video consultations.
But I wanted to understand one thing first:
Would video actually work for the people who needed remote healthcare most?
When COVID-19 made in-person care unsafe, the gap between the two platforms became critical. Patients needed remote access to doctors, while clinics needed a way to deliver and manage care remotely.
The initial brief was simple: build video consultations in six weeks.
The Challenge
We had six weeks — and a lot we didn't know
My Role
I owned the end-to-end design process, from research and problem framing through to product decisions, interaction design, testing and developer handoff.
User research
User flows
Information architecture
Prototyping
High-fidelity Design
Usability testing
Developer handoff
Constraint
Phase 1 had to be researched, designed and delivered in six weeks.
There was no time for a traditional:
Research
Design
Development
sequence.
We had to identify the riskiest assumptions quickly, test them, and use the evidence to decide what was worth building.
My Team
1 Product Manager
1 Business Analyst
4 Developers
1 QA Engineer
The challenge wasn't only speed.
We also had to determine what remote care should actually look like.
The team initially assumed video would be the primary consultation channel. I needed to validate that assumption and decide what to build before we scaled the solution.
Research
The initial assumption was video
We needed to test whether video could serve patients, doctors and clinics effectively.
What we needed to learn
Could patients actually access video consultations?
Would video work for elderly and accessibility-constrained users?
What would doctors and clinics need to deliver remote care?
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
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 multi-channel model.
Research shifted the product direction from:
How do we put a consultation on video?
to:
How do we make essential healthcare accessible remotely through different channels?
Video + Chat
Video worked well for consultations where visual interaction mattered.
Chat provided a lower-friction alternative for users without suitable hardware, poor connectivity, accessibility constraints or simple follow-ups.
No single channel worked for every patient or every consultation type. We designed both.
The problem was bigger than the consultation
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
Video-first
Video + Chat
A connected telehealth ecosystem
We connected the patient and clinical platforms and introduced the missing admin workflow to support the complete remote-care journey.
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 data
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 products I designed to extend the remote-care ecosystem.
What I Designed
Connecting the experience across the ecosystem
I led design of the core end-to-end workflows across the patient, doctor and administrator experiences, translating the product strategy into a shippable experience across Medcard24 and Medstar.
From booking to prescription
From service logic to product interfaces
Designing Under Pressure
Research, design and development happened together
With only six weeks for Phase 1, research, design and development happened in parallel.
I worked directly with the team to test the highest-risk assumptions and adapt the design as technical constraints emerged.
My role was therefore not only to produce screens.
I decided what not to build, what needed to change, and what had to be prioritised first.
Every decision balanced:
User needs
Healthcare workflows
Technical feasibility
Six-week delivery constraint
Patient experience — Medcard24
Booking and managing appointments from the patient side.
Clinical experience — Medstar
Managing the consultation and patient workflow from the doctor side.
Clinical experience — Medstar
Impact
From emergency response to a scalable remote-care service
The immediate goal was to establish remote healthcare during lockdown. The solution became part of a wider ecosystem connecting patients, doctors and clinics across Medcard24 and Medstar.
Product scale
37K+
physicians on platform
120K
appointments at peak
Product outcomes
4.8
App Store rating
48%
reduction in offline visits
The biggest product change was not adding video. It was creating a connected remote-care model across patients, doctors and clinics.
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.
The Takeaway
I didn't just design a telehealth feature. I redefined the problem.
The project started with a request to build video consultations. Research showed that the real challenge was broader: making remote care accessible and operationally viable across patients, doctors and clinics.
I shifted the team from a video consultation feature to a connected telehealth ecosystem. Six-week Phase 1 delivery window
⚡
Core consultation flow designed and shipped during active lockdown
💬
Video + Chat
Two consultation modes so no patient gets excluded
👥
Multi-User Platform
Coordinated workflows for patients, doctors, and administrators
⚖️
Medical regulations shaped every flow from the start
♿
WCAG 2.1 compliant design for users across all age groups and abilities
🎯
Scheduling ownership removed from overloaded doctors
