Elliot RylandsWhat if booking understood how people negotiate time?
Most booking software is a database with extra steps. Hold keeps one reservation on screen and spends the craft on Motion: services move into the booking, unavailable 10:00s become a question, better matches drift toward the centre. Nothing is reserved.
How to use it
- Pick physiotherapy. Watch it assemble in the reservation.
- Prefer Sarah, leave the slider around 10am. 10:00 isn’t hers. Say what matters.
- Take 10:15. It holds for five minutes of theatre.
- Continue for allergies. Latex changes which services remain. The summary is the editor.
Hold
Explore
Your booking
Nothing selected yet.
Service
Who
When
Around 10am
Availability
Thursday morning · around the time you asked for
Best match 10:00 with James. 8 options.
Negotiation, not a funnel
Six steps that each own a database field make sense to a scheduler. They do not match how people actually book: Thursday morning, Sarah if she’s around, somewhere near 10. Hold is one booking state with three ways of touching it: explore when you need to compare, focus when you need one question, review when the object you built is the editor.
Motion is the explanation. Shared layout so a service does not vanish and reappear as text. Springs so a constraint does not blink a new grid into existence. Reduced motion keeps the states and drops the choreography. The constellation is an enhancement; the list underneath is the booking.
This is a Lab prototype. A real clinic would still hold slots on a backend. The argument is that unavailability is a preference question, not an error screen.