COREY ANN LEAMON

aboutresumeblogphoto

/ grubhub timepicker


project type

ui, ux


client

Grubhub, in-house


collaborators

Vasu Tyagi (PM)

Mike Wright (web engineer)

Roland Tecson (iOS engineer)

Peter Daniels (andr engineer)

Nick Iuliucci (usability)


At launch, Grubhub's scheduled ordering feature used native timepicker UI in iOS, Android, and web. Due to the nature of the platforms including both 24/7 search capability as well as constrained restaurant hours, the default UI were burdensome and setting diners up to fail by allowing them to choose invalid times. Literally thousands of error states were possible once a diner adjusted their delivery or pickup time with the constraints of a restaurant in place.


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 8 – 245 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 12% and climbing, with increasing cases of large-value corporate orders being more than 24 hours ahead. This opened the effort for a 30-day version of the timepicker UI, requiring new user flows to capture status checks and constraints on payment methods.
[credit card validation when order is 5+ days in advance]


[30-day picker in mobile web]
Work for the most recent iteration is ongoing, with tests being run on a production branch for web and InVision prototype for mobile.





<< back to projects

all content developed by corey ann leamon, 2017