Deliveroo tablet and mobile app
Driving network efficiency through the restaurant facing app
With great algorithmic changes, comes great UI responsibility. In 2020, we revamped the way we stored and sent data to our restaurants, specifically around the rider wait time they were going to have.
In our previous approach we couldn’t provide accurate estimates of when a rider will arrive → this leads to mistrust in both the system and riders. Sometimes we even underestimate prep time, so restaurants physically can’t make the food for when the rider arrives.
Just in time was an algorithm change which sends the order to the restaurant at the point at which they should start preparing it.
At this point, we can be much more confident in our rider arrival estimates. Now let’s look at what was in place.
UX Research
To get to the bottom of the possible implications of this change, a content designer, a UX researcher and I ran 8 face to face interviews with key chains, QSR’s, and local bronze restaurants. We also spoke to delivery operational managers, who aren’t tied to a specific site, but overlook how delivery is performing across all branches.
Some of our key partners are the worst offending restaurants when it comes to wait time - so to cooperate with these could be a big win for us.
Our aim was to understand each restaurants step by step delivery workflow, and how confident they feel in knowing when a rider will arrive. We then went through some ideas to get feedback.
The key question was: how were restaurants using the tablet and mobile app in their day to day?
The answer is: chaos. Small businesses don’t want to put all their eggs in one basket, so we are one of many inbound order apps they will be using – and each comes with their own POS (point of sales) app and device.
We’re rarely their main focus. They have orders coming in from in-house and (usually) multiple delivery partners.
So what if we evolved the app to focus less on order detail and more on workload and priorities, driving network efficiency?
Understanding the problem
This is the first sketch I made to try and understand the problem and how it could escalate into a high def UI change to support the algorithm changes. The Rider Experience Time (RET) project intends to improve logistics accuracy across the marketplace, including optimal prep times for restaurants.
‘Just In Time’ algorithm improvements and ROM UI changes are two critical pieces of the RET strategic initiative - which aims to realize a 7p/order cost savings over 2020. It’s imperative that we make Riders and Restaurants aware of the improvements, and drive a long term strategy to change their behaviour across WAR and prep time adherence.
User journey mapping
The new workflow, focusing on real use-cases
Even from across the kitchen, I get an instant view of what I need to prioritise.
We can use expandable cards to display order details, instead of using most of the space to display information they don’t always need.
Make order priorities much clearer, increasing urgency when riders are waiting
Call attention to our improved accuracy, building trust and cooperation
Optimise for a faster restaurant - rider handover, decreasing RET and B10 experiences
Flexible across devices, promoting parity and for customers to use their own. It would significantly diminish the onboarding fee, which included a tablet or phone.
What shipped
New dark mode for improved contrast and accessibility
“Traffic light” style colours to help skim through orders and see what is more urgent (green, orange, red)
Order cards now open as a modal, with parity with our Sunmi devices
Orders sorted according to priority (rider waiting and then closer to pick up)
Orders only appear when the restaurant should actually start prepping it, rather than when it is originally placed
Three possible lanes for orders: prep now, rider waiting and prep later for scheduled orders. This improves restaurant and rider wait time, and only show as needed
Completed orders now in a separate item inside the main navigation (up to 48h)
And what’s best: this launch proved a 48 sec improvement on rider wait time!
Learnings
Map: it seems like a no-brainer, and it was an early ask. However, through using it in prototypes there were no takers from the customers! They saw it as an added complexity, when all they really needed was a realistic, updated arrival time in clear big letters.
What’s more: their actual wish-list item was more flexibility on their end to change the rider arrival time based on how long they’d need to prep a dish. While we use machine learning to try to guess how long they’d need, things sometimes don’t go according to plan, and they wanted control over that.
