Seven pages of booking form, cut to one decision

The brief

The clinic wanted the booking page to "look more professional". That is usually a symptom rather than a diagnosis, so before drawing anything I asked for two things: the analytics for the booking pages, and twenty minutes with whoever answers the phone.

The receptionist was the more useful source. Almost every caller said a version of the same sentence — they had started booking online, got stuck, and rang instead.

Where people left

The old flow ran across seven screens. Mapping the drop-off against them made the problem obvious, and it was not visual design.

Two of those seven screens collected information the clinic never used, and one asked patients to choose a department by its internal name.

What I did

1. 01 Deleted the two screens whose data nobody read, and moved insurance and address collection to the desk, where staff were re-checking them anyway.
2. 02 Replaced department names with symptoms in plain language, in Tamil and English. Patients know what hurts, not which speciality treats it.
3. 03 Put the whole booking on one screen: reason, doctor, slot. Three choices visible at once, so the patient sees the end of the task from the start.
4. 04 Showed real slot availability up front rather than after login. The old flow asked people to register before finding out whether a slot existed.
5. 05 Dropped account creation entirely. A phone number and an OTP confirm the booking; the record is created behind the scenes.

The states nobody drew

The original design existed as three tidy screens showing a doctor with plenty of free slots. Reality is mostly the opposite, and those conditions had been left to the developer to invent.

• Fully booked doctor. Offers the next available date and a colleague in the same speciality, instead of an empty calendar.
• Slot taken mid-booking. Common at 9am. The screen says so plainly and keeps the rest of the form filled in.
• OTP not arriving. A resend that appears after fifteen seconds, plus the clinic's phone number as a way out.
• Connection dropped. The booking either completed or it did not, and the screen commits to one answer rather than spinning.

The happy path was already designed. Everything the patients actually hit was not.

Outcome

Completed bookings went up without any increase in visitors, which is the only version of that result worth reporting — the same people arrived and more of them finished. Reception call volume fell enough that the front desk noticed within the first fortnight.

Nothing here was clever. Two screens deleted, department jargon replaced with symptoms, availability shown before login, and the four failure states specified so the developer did not have to guess at them.