01
Time
2026
Team
Solo Project
Redesigning the clinic waiting experience. An independent concept study inspired by Doctolib, not affiliated with or commissioned by them.

01
I booked a doctor's appointment two months in advance. I arrived on time and still waited 40 minutes.
Doctolib solved the question of "Can I get an appointment?" It never solved "Will I actually be seen on time?" An appointment time is not a treatment time.
Research shows that actual waiting time has no significant effect on patient satisfaction (P = 0.365). Perceived waiting time does, dramatically (P < 0.001). Patients don't need to wait less. They need to know what they are waiting for.
02
I mapped the full patient journey from booking to consultation. The waiting room is the only phase where anxiety keeps rising instead of levelling off. Before arrival, patients still have certainty to hold on to: a confirmed time, a plan. Once they check in, that certainty disappears. This uncertain phase is also the longest one.
That defined the design goal: restore certainty instead of trying to shorten the wait.
03
My first idea was a sensor on the consultation room door that triggers the queue automatically whenever it opens. Then I thought about how doctors actually move. A door opens for many reasons: fetching files, a bathroom break, a quick word with the front desk. The sensor would fire constantly for the wrong reasons, and the queue data would end up less trustworthy than no data at all.
The direction that worked came from somewhere much more boring: the German Bürgeramt ticketing system. Patients already know the logic. Take a number, watch the screen, wait for your call. There is no new mental model to learn. The design challenge was to adapt this familiar system to the emotional context of a medical visit.
04
If the current call is 324 and your ticket is 331, are there exactly seven people ahead of you? Not necessarily. Some may have given up and left. The gap between two ticket numbers and the real queue length are two different things. Confusing them would create a new kind of misleading information, which is exactly what this system is supposed to eliminate.
So the system tracks them separately: the ticket number for identification, and the actual number of patients ahead, which answers the only question patients truly care about.
05
This is a service system across three devices rather than an app redesign. It covers the patient journey from check-in to consultation.
Mobile app. One number dominates the screen: how many patients are ahead of you. The ticket numbers (324 / 331) are secondary, styled deliberately so patients are not tempted to do the misleading math themselves.
In-clinic screen. Designed for the reality of German primary care, where 67.5% of practices are run by a single doctor. The screen shows three inseparable elements: doctor, ticket number, and room number. Borrowing from McDonald's pickup screens, it also shows the next numbers in line, giving patients time to prepare instead of being startled by their call.
SMS notifications. A fallback for a real-world constraint: mobile signal inside clinics is often weak. Only two messages are ever sent, a check-in confirmation and a your-turn alert, each with an opt-out. Enough to cover the gap without becoming noise.
06
Doctolib's revenue comes from doctor subscriptions at €139 per month per practitioner, about 85% of total revenue. Patient satisfaction directly shapes whether a practice renews. Roughly 70% of the German market remains untapped. A waiting experience like this could become the feature that convinces the next practice to subscribe. No competitor currently offers it.
07
This project doubled as an experiment in combining strategic design with AI. AI accelerated the research synthesis, competitive analysis, and documentation. The key judgments were mine: rejecting the door-sensor idea, spotting the trap of confusing ticket numbers with queue length, adapting the Bürgeramt ticketing logic rather than inventing a new mental model, and limiting SMS to two messages.
08
Full research documentation is available, including competitive analysis, interview templates, and the service blueprint. Happy to walk through it in a conversation.


