Mobile Booking Flow: Interruption Checklist
A mobile booking flow must survive real-world interruptions: lost connections, accidental back taps, and time zone confusion. This guide offers a practical checklist for designing a flow that recovers gracefully and prevents duplicate bookings.
Time zones and slot availability
Choose the displayed time zone deliberately: an in-person appointment may be clearest in the venue's zone, while a remote service may need both venue and customer times. Label the zone explicitly. Store the event's zone identifier alongside its scheduled time, and use UTC instants where appropriate for comparison. Recheck availability when a slot is selected and when the booking is confirmed. If it is gone, offer alternatives without discarding the other details.
Suppose a user in Dubai books a service with a provider in London. The app shows slots in Gulf Standard Time, but the backend checks availability in UTC. If the user's device time zone changes mid-flow, the app should refresh the slot list and notify the user of any changes.
Back navigation and state preservation
Users often tap back to review earlier selections. Preserve their entries rather than clearing the form. If the booking system supports temporary slot holds, explain the expiry and release rules. Otherwise keep the selection as a draft, not a reservation, and recheck availability before confirming. Never label a slot as held unless the server has actually reserved it.
A concrete test: start a booking, select a slot, tap back to the previous step, then forward again. The slot should still be selected and the form data intact. If the slot was released, the app should show it as unavailable and prompt the user to choose another.
Duplicate submission prevention
Duplicate submissions can occur from double taps or network retries. Disable the submit button immediately after the first tap and show a progress indicator. On the server, use an idempotency key to ensure that repeated requests with the same key do not create multiple bookings. If a duplicate is detected, return the original booking confirmation instead of an error.
Suppose a user taps confirm twice due to a slow connection. The app should process only one booking and display a single confirmation. The user should not see two bookings or an error message.
Confirmation and recovery
After a successful booking, show a clear confirmation screen with all details: date, time, time zone, location, and a booking reference. Provide options to add the booking to the device calendar or share it. If the connection drops after submission, the app should not assume failure. Instead, check the booking status on the next launch or when connectivity returns, and inform the user of the outcome.
A pass/fail test: simulate a network failure immediately after submission. The app should either show a pending state and later confirm the booking, or clearly state that the booking was not completed and allow retry. It should never leave the user unsure.
Handling unavailable slots and errors
When a selected slot becomes unavailable, avoid a dead end. Offer a list of nearby available slots and allow the user to switch with one tap. For other errors, such as payment failures, provide specific guidance and a way to retry without re-entering all data. Log errors with enough context to diagnose issues without compromising user privacy.
Suppose a user selects a slot that is taken while they are on the payment screen. The app should return them to the slot selection with the unavailable slot marked and alternatives highlighted.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.