Pakistan's largest health platform, rebuilt around how people actually search for care.
Health products assume a patient who already knows the system. Pakistani patients arrive with a symptom, not a specialty. I redesigned discovery, sign up and booking around that reality across a mobile app, a web platform and a clinic SaaS. Appointment conversion rose 30%.
Healthwire set out to be the front door to healthcare in Pakistan: find a doctor, book an appointment, consult over video, order medicine, book a lab test. On paper that is a marketplace. In practice it is five different products a stressed person has to navigate on a mid range Android phone, often on a patchy connection, frequently on behalf of somebody else in the family.
I ran requirements gathering directly with the founders and the CEO rather than through a spec document. That access mattered: it meant research findings could change the roadmap in the same meeting they were presented, instead of being filed as feedback.
When I joined, the product had listings and a booking form. What it did not have was an answer to the question every user actually arrives with: "I feel like this, so who do I need?"
First time users of any health app, often on a shared mid range Android, frequently booking for a family member rather than themselves.
Doctor discovery, video consultation, in clinic booking, pharmacy and lab tests. Each has a different mental model and they all share one home screen.
App, web, clinic SaaS and B2B tooling shipping in parallel. Anything not systemised would not survive the release cadence.
The company was building toward a Series A. Design had to prove it moved retention and conversion, not just how the product looked.
Healthwire's users cannot complete the first step of the journey on their own. The product asks them to name a medical specialty before it will help, then asks them to create a full account before it shows any value. Most people know their symptom, not the specialty that treats it, and most will not commit an email and password to a service that has not yet proved useful. The result is a funnel where the two largest drop offs happen before a single doctor is ever viewed.
Reframed as a design question: how might we take a person from "I feel unwell" to a confirmed appointment without requiring medical vocabulary or an account up front?
"I didn't know there was a separate doctor for skin problems. I always just went to a general physician and waited to be told."
People searched for stomach pain, chest pain, fever in a child. Nobody typed "gastroenterologist". A specialty first taxonomy was effectively invisible.
The default path was asking family. A profile with no social proof read as a stranger's phone number rather than a doctor.
The largest single drop off was not search or listings. It was the account wall: email, password, confirm, OTP, all before any value.
Bookings were often made for a parent, spouse or child. The product assumed the account holder was always the patient.
Shape of the funnel as we understood it from analytics and support data. The two circled losses, service discovery and the account wall, are the ones the redesign targeted.
Fourteen semi structured interviews across Lahore and Karachi, split between patients and clinic front desk staff. Six moderated usability sessions on the existing product. Funnel analysis on the live booking flow, plus a read of every support conversation from the previous quarter. Requirements and priorities were set in weekly sessions with the CEO and founding team.
Audited Marham, Oladoc, Sehat Kahani and Practo alongside international benchmarks like Zocdoc and Doctolib. I scored each on discovery model, sign up friction, trust signals and pricing transparency. Every regional competitor was specialty first, which confirmed the gap was a category problem rather than a Healthwire problem.
Interview findings were converted into a ranked set of HMWs and used as the brief for ideation. Everything downstream traces back to one of them.
Four personas came out of the interviews and drove every prioritisation call afterwards.
Two findings changed the product. First, the front desk was a user. That finding is the reason the SaaS product exists. Second, people wanted to see the hospital, not just the doctor. A recognisable building is trust in a market where credentials are hard to verify.
Before any pixels, I mapped every entity and every route between them: doctors, specialities, hospitals, labs, pharmacy, consultations, appointments, profile. The point was to find the shortest honest path from "I feel unwell" to "I have an appointment", and to prove to engineering that it existed.
The core journey drawn as a decision map: instant call, video consultation, or in clinic visit, each with its own failure branches. Every diamond in this diagram is a moment where a user could abandon, and each one got a designed answer: a waiting time estimate, an alternate slot, a fallback to chat support.
Six decisions did most of the work. Each came from a specific research finding, and each has a specific thing it was trying to move.
Users arrive with an intent, not a browsing mood. So the first screen is five clear doors sized by how often people actually need them, with the free option labelled free.
The old flow put a wall of fields in front of a person who was already anxious. I rebuilt it as a progressive sequence: two screens, a visible two segment progress bar, and a single job per screen. No password at all. A phone number and an OTP, because that is the identity Pakistani users actually carry.
A CV does not build trust with someone who cannot evaluate it. The profile leads with what a Pakistani patient actually uses to decide: satisfaction rate, how many people have been seen, the fee stated plainly, the next available slot, and which hospital they sit in.
Research kept surfacing the same behaviour: people trust institutions before individuals. A well known hospital name means something. An unfamiliar doctor's name does not, yet. So hospitals became a first class object with distance, available doctor count, photography and a direct route into that hospital's specialists.
A consultation usually ends in a prescription or a test. Burying those in a menu meant losing the user at the exact moment the platform was most useful. Both became full storefronts, with discounts stated in the card, home sampling made explicit, and re order surfaced for medicines people buy monthly.
The original model assumed the account holder was the patient. Interviews said otherwise. One phone books for the whole household. Appointments and records were rebuilt around who the appointment is for, so a son booking for his mother does not have to lie to the form.
The handoff file itself. Pick a section on the left and the frame jumps to that page. Pan and zoom work inside the frame.
Four surfaces shipping in parallel with one designer only works if the system does the repeating. I built tokens, a component library and usage documentation so engineers could assemble screens I had not drawn yet, which is exactly what happened as the platform expanded.
The palette is deliberately calm. Healthcare content is stressful enough, so colour separates services and marks state rather than decorating. Each service got a pastel identity so users could recognise the pink card as Find Doctor before reading a word.
The patient app is the visible half. The half that made the business work is everything behind it, because an appointment is not real until the clinic can see it.
iOS and Android. Discovery, booking, video consultation, pharmacy, labs and records. The primary surface, since most Pakistani users are mobile only.
healthwire.pk, the SEO and discovery front door. Someone searching a symptom on Google lands here, and the booking flow has to survive on desktop too.
hcloud.pk. Scheduling, patient records, prescriptions and billing for the clinic side. This is what stopped bookings being rekeyed into a paper diary.
Onboarding tools for hospitals and labs, plus internal ops dashboards for the team managing supply and support.
The number that mattered internally was conversion: how many people who opened the app ended up with a confirmed appointment. Removing the account wall and rebuilding discovery around symptoms moved it 30%.
The funding round is the line that goes on a CV, but it is not the achievement. The achievement is that a platform built for a market with low digital health literacy got people to complete a medical booking on a phone, unassisted, and then come back for medicine.
The front desk finding reframed the entire product, and it arrived late. The people who operate a service often understand its failure better than the people who consume it.
Layouts sized around English broke when real Urdu content landed. Language should have been a constraint from the first wireframe, not a localisation ticket.
The system saved the project, but it was built under pressure. Starting it a quarter earlier would have cost less and shipped more.
"No doctors available in your area" is a design problem with revenue attached, and we were guessing at how often it fired for far too long.
A debt recovery platform serving three parties with opposing interests, plus a conversational AI agent.
Read case study →
Fourteen HR modules in one subscription platform, designed end to end in six weeks.
Read case study →
Three products in one system: customer app, worker app and admin console, all reading the same job.
Read case study →
NFT event ticketing that kills counterfeits and scalping, sold without ever leading with blockchain.
Read case study →
School payments and a learning app inside a platform with 16 roles and 4 languages.
Read case study →