Arete

What made this hard

The four things a patient needs are run by different organisations with different systems and different obligations, so presenting them as one journey is a claim the underlying services do not make on their own — and the risk is a product that feels seamless right up to the moment it hands you off and stops helping. Coverage is where that hurts most: eligibility language has to be plain enough to act on and precise enough not to promise something an insurer will later refuse, and getting it wrong in either direction costs the patient. The context tightened it further. Multilingual users, low-connectivity environments and high-stakes tasks ruled out clever interactions and icon-only affordances, and writing for people who are unwell ruled out most of the reassuring tone a product designer reaches for by default — reassurance that overstates is worse than silence.

Research & discovery

Research status — Exploratory, product-design-led

Who

Patients moving between four separately operated services, and the clinical, insurance and pharmacy staff on the other side of each hand-off.

Investigated

Where a telemedicine product stops helping — the finding was that most stop at the booking, while the patient's problem continues into coverage, prescription and fulfilment.

Learned

Coverage is the point of highest risk: language has to be plain enough to act on and precise enough not to promise what an insurer will later refuse.

Changed

The journey was designed past the consultation, and Skip for Now was kept throughout so an uninsured patient is never blocked from reaching a doctor.

Still open

Whether patients read a coverage state as actionable — untested, and the most consequential unknown in the product.

Next test

Test whether patients understand insurance eligibility states and can act on them, with real patients rather than colleagues, and validate the hand-off points with an insurer and a pharmacy.

Key decisions

1. 01

   Framed the design around how information and actions move between roles rather than how individual screens look, because the requirements covered patients, doctors and nurses, community health workers, HMO teams, pharmacies and administrators sharing one product.

2. 02

   Resolved the requirements into four principles that could settle arguments later — simple first, accessible, localised, transparent — and held decisions against them rather than against taste.

3. 03

   Designed the journey past the booking, which is where most telemedicine products stop: need care, find provider, consult, check coverage, get prescription, find pharmacy, continue care. Each step is a place the journey can fail, so each got designed rather than assumed.

4. 04

   Broke registration into progressive steps with visible progress, explicit verification language and real recovery paths, because the first interaction with a health product is where trust is either established or lost.

5. 05

   Put coverage before commitment. The HMO module verifies membership, states what the plan covers and its limits, and surfaces eligible providers before a patient chooses care — and Skip for Now stays available throughout, so an uninsured patient is never blocked from reaching a doctor.

6. 06

   Treated a prescription as unfinished until the medicine is in hand: nearby stock, pickup or delivery, fulfilment confirmation, reminders, and explicit out-of-stock and alternative-medication paths.

7. 07

   Designed the non-happy paths as core UX rather than edge cases — OTP errors, verification loading, HMO approval states, plan removal with reason capture, availability signals and confirmations — and gave status its own vocabulary so error, pending, unavailable and success are never ambiguous.

8. 08

   Paired every action with legible text instead of icon-only interactions, and kept language and cultural context in the copy, so the interface holds up for multilingual users on poor connections.

9. 09

   Built the system underneath — a calm healthcare green with high-contrast neutrals, Noto Sans at defined sizes, and reusable field, card, alert, button and status patterns — so a high-stakes interaction feels the same whether it sits in the patient, insurance or pharmacy journey.

What changed

A healthcare product designed as a chain rather than a set of features: the patient journey continues past the consultation into coverage, prescription and fulfilment, and the moments where it could break — an unverified plan, an out-of-stock medicine, a failed OTP, a removed HMO — are designed states rather than dead ends. One system of colour, type and components holds the patient, provider, HMO and pharmacy surfaces together, and the whole experience is built for legibility, localisation and low connectivity rather than assuming ideal conditions.

Scope & context

• Product scope

  7

  Steps designed, from needing care to continuing it

• Product scope

  6

  Actors the requirements covered

  Patients, doctors, nurses, community health workers, HMO teams, pharmacies and administrators

• Product scope

  4

  Surfaces — patient, provider, HMO and pharmacy

• Product scope

  Offline-aware

  Designed for low connectivity, localisation and accessibility

Evidence

The seven-step journey is designed end to end rather than stopping at the booking, where most telemedicine products stop. The status vocabulary and edge cases are specified alongside the happy paths, the HMO module keeps Skip for Now available so coverage never blocks access to care, and the design system defines a palette, four type sizes and reusable field, card, alert, button and status patterns across all four surfaces. The full case study is published on Behance.

What I would improve next

Eligibility comprehension is the thing to test first — whether a patient reads a coverage state as something they can act on rather than a status they have to interpret — and it needs real patients rather than colleagues. I would then validate the hand-off points with an actual insurer and pharmacy, since the journey's credibility rests on partners the design cannot control, and test the low-connectivity assumptions on real networks rather than on a design file.

With more time

I would design the care record as the spine of the product rather than a section of it. Continuity is the thing the ecosystem promises, and it only becomes real when a consultation, a prescription and a refill visibly belong to the same ongoing story.