A booking flow that works on a phone in a waiting room
The patient is standing up, one-handed, on bad reception, at 9pm. Design for that person and everyone else is covered.
Clinic sites are usually designed at a desk, on a large screen, by someone sitting down. The person who uses them is doing none of those things. They are in a waiting room, or on a bus, or in bed at nine at night having decided the shoulder is not getting better on its own.
Three questions, in order
Almost every visitor is asking the same three questions in the same order: do you treat this, who will treat it, and when can I come in. A site that answers them in that order needs very little else. A site that opens with the practice history answers none of them.
- Do you treat this problem?
- Who is the person who will treat it?
- When can I be seen?
We build the booking flow first and let the rest of the site exist to support it. Services pages exist to answer question one. Practitioner pages answer question two. Everything ends at question three.
If the booking flow cannot be completed with one thumb, it cannot be completed.
The practical constraints follow from the person. Tap targets sized for a thumb, not a cursor. Form state that survives a dropped connection. No date picker that assumes a mouse. And a confirmation the patient can screenshot, because that is what they will do.
Written by Raion