These constraints led to two designs: one in which a diner could choose a delivery time within the five-day constraint, and a future-state timepicker permitting a time selection for 30 days. The redesign goals for iOS, Android, and web were to reduce friction, increase time selections from 30 to 15-minute intervals, and to only permit the selection of valid times. This meant both UI needed to accommodate a range of 1 – 96 possible selections within any one day.
Vasu and I created logic for language and default times most natural to the common use case. For instance, when a diner switches to days ahead, the time defaults to noon as lunch is the most common order time and it places them squarely within the center of the possible time range. When restaurant constraints come into play, diners are given possible hours of delivery or pickup within the timepicker, and then restricted from choosing invalid times. Circumstances determine if the picker then defaults to the next available time or noon.
[choosing next-day in web]
[iOS picker in search]
[iOS picker on a menu]
Because the timepicker and ability to schedule sets the foundation for multiple corporate features, it was imperative to validate work through user testing, A/B tests, and data analysis on each platform. After collaborative iteration on order logistics (following poor test results), on web we saw a 0.23% lift on the homepage for both brands and all visitors. In iOS, we immediately saw +0.5% LTV and +0.4% AOV across both brands and all diners.
As we began to gather data from the launch of scheduled orders and the new timepicker, we learned that over 92% of all scheduled orders were for that day and AOV was $25-28 more than for ASAP orders. The percentage of all orders which are scheduled is at 2% and climbing, with increasing cases of large-value corporate orders being more than 24 hours ahead.