At a glance

Problem

International patients could find hospitals and doctors, but the rest of the journey remained fragmented. Treatment, travel, documents, payments and recovery had to be coordinated across different providers and channels.

Solution

OneCare connects everything around treatment in one place by helping patients discover suitable care, prepare for their journey, track what happens next and continue recovery after returning home.

Live demo

01The opportunity

The gap wasn't treatment. It was everything around it.

India already offered specialised care, lower treatment costs and shorter waiting periods. But for international patients, choosing a hospital was only the beginning.

Documents, travel, accommodation, appointments, payments and recovery still had to be coordinated across different providers and channels.

A patient journey from finding care, through preparing and treatment, to recovery.
How existing medical-tourism platforms compare, with coordination still fragmented.
Looking at the journey end-to-end revealed that the complexity existed around treatment, not just in finding it.

Discovery was already being solved. Coordination wasn't.

Existing medical-tourism platforms largely helped patients discover hospitals, doctors and treatment options. The larger gap was keeping everything around that treatment connected.

Key decision

OneCare wouldn't become another treatment marketplace. It would become the care integrator connecting the journey around treatment.

OneCare connecting hospitals, travel, documents, payments and recovery around one patient journey.

02Designing the journey

Patients don't think in services. They think about what happens next.

OneCare had to connect hospitals, doctors, documents, travel, accommodation, transport, payments and recovery.

Presenting all of these as separate services would simply recreate the complexity patients were already dealing with.

The OneCare journey, organised as Discover, Prepare, Experience and Continue.

Key decision

Make the patient's stage the organising principle.

Instead of asking patients to understand OneCare's service ecosystem, the experience is structured around the patient's stage.

03Structuring the experience

One platform. Two very different moments.

Someone exploring treatment and someone already travelling for care don't come to OneCare with the same goal.

Before committing, patients need to compare and build confidence in their options. Once care is booked, their priority shifts from choosing to coordinating.

Making sense of the service ecosystem

Before finalising the structure, we used card sorting to understand how users grouped OneCare's services and where different parts of the journey naturally belonged.

Card sorting used to group OneCare's services.
Card sorting helped inform how the service ecosystem was grouped before the final information architecture was defined.
Before login, OneCare supports exploring care. After login, it supports managing the journey.

Key decision

Separate exploring care from managing care.

Before login, OneCare supports discovery and comparison. After login, it becomes a journey-management experience centred around the patient's upcoming care.

04Refining the experience

Testing before polishing.

Before moving into the final interface, we tested key flows using paper wireframes to see where the journey broke down, what caused hesitation, and what needed to change.

Paper wireframes used to test early OneCare flows.
Testing early flows with paper wireframes.

Testing didn't just validate the flow. It changed how it worked.

Testing the paper-wireframe flows exposed moments where the journey still asked too much from the patient. Four findings directly changed the experience.

  1. 01

    Don't let unavailability become a dead end.

    What we foundAn unavailable doctor could interrupt the journey and leave the patient without a clear next step.

    What changedSuitable alternatives were surfaced within the flow instead of forcing the patient to restart their search.

  2. 02

    Recommend before asking patients to choose.

    What we foundChoosing a physiotherapist without enough context placed another decision on a recovering patient.

    What changedThe experience recommends a suitable therapist first, while still allowing patients to explore alternatives.

  3. 03

    Make completion unmistakable.

    What we foundBookings and payments needed clearer feedback about whether an action was complete and what changed afterwards.

    What changedConfirmation and journey-status updates were strengthened so patients could understand both what happened and what comes next.

  4. 04

    Different stages need clearer language.

    What we foundSome navigation labels were difficult to distinguish.

    What changedLabels were simplified and differentiated around the patient's journey, making different areas of the experience easier to recognise.

The journey doesn't end at discharge.

Returning home doesn't mean recovery is complete.

International patients may still need follow-ups with their operating doctor, physiotherapy and continued recovery support after leaving India.

  1. TREATMENT
  2. DISCHARGE
  3. HOME
  4. RECOVERY
  5. FOLLOW-UP
Continued care after discharge, including teleconsultation, physiotherapy and follow-up.

Key decision

Make continued care part of the core journey, not an add-on.

OneCare extends the same coordinated experience into teleconsultation, physiotherapy and follow-up so patients don't lose continuity once they return home.

05Designing the experience

Trustworthy, without feeling clinical.

OneCare deals with high-stakes medical decisions, so the experience needed to feel dependable without making an already stressful journey feel cold or institutional.

Deep blue creates structure and trust, while lavender and lace soften the experience. Rounded forms and the connected-line motif carry the idea of continuity from the identity into the interface.

Explorations of the OneCare logo.
The final OneCare mark, built from a connected line.

The mark carries the same connected line into the product, so continuity is visible in the interface as well as the identity.

OneCare colour and typography.OneCare interface components.

From identity to interface

The same visual language carries through the interface, helping the experience feel connected across discovery, planning, treatment and recovery.

One journey, visible from beginning to recovery.

Discover

Find suitable care.

Treatments · Hospitals · Doctors · Packages

Screens for discovering treatments, hospitals, doctors and packages.

Prepare

Get ready for the journey.

Documents · Visa · Appointments · Travel

Screens for documents, visa, appointments and travel before the trip.

Experience

Navigate care in India.

Arrival · Treatment · Payments · Records

Screens for arrival, treatment, payments and records during the stay.

Continue

Recover beyond discharge.

Teleconsultation · Physiotherapy · Recovery · Follow-up

Screens for teleconsultation, physiotherapy, recovery and follow-up.

06From design to build

Taking it beyond the prototype.

We developed OneCare as a responsive web experience, bringing the journey architecture and interface system into a working product.

  1. HTML
  2. CSS
  3. JavaScript
  4. PHP
  5. MySQL
The OneCare interface built in HTML and CSS.The same OneCare pages adapting across screen sizes.Interactive behaviour in the working OneCare product.How patient information moves through the working product.View Live Prototype ↗

07Reflection

What OneCare changed in how I think.

01

Design around the person, not the organisation.

The clearest structure came from following the patient's journey rather than exposing the complexity of the service ecosystem.

02

Visibility reduces uncertainty.

For a long, high-stakes journey, knowing what has happened and what comes next is part of the experience itself.

03

Building reveals different problems than designing.

Taking the experience into code made responsive behaviour and implementation constraints part of the design process.

view detailed case study