Don't leave users hungry for more
A case study on how to improve the user's experience when it comes to waiting for their delivery meal
Bad user experience (UX) can not only break your user's journey, but also break their trust in your product.
Sometimes, this could be a technical issue that is out of the designer’s control: perhaps the function is still being developed or the technology isn’t available yet. Whatever the factor is, the user’s experience should still be prioritized, even with technical drawbacks.
Hungry customers = bad reviews
When you work in the food delivery industry, you are dealing with a lot of hungry customers. That means these customers—when their demands and expectations are not being met—are more prone to frustration and anger. Customers who end up feeling disappointed will have a negative experience with your app and give your business a bad review.
What does it take to get a good review? Once the user has confirmed their order payment, the countdown begins. Ideally, as long as the user receives their order by—or even better, before—the restaurant's estimated time of arrival, the user will be satisfied and most likely rate the experience positively.
But what if external factors, such as a delayed response from the restaurant or bad driving conditions, influence the order? What can be done to ensure that the user forgives (or forgets) a negative experience?
As a UX designer at EAT.ch, my focus in this study is to make sure that the user's journey is as pleasant as possible after they have confirmed purchase of their meal, while factoring the possibility of a late order.
Because stakeholders did not want to implement technical developments at this stage, I needed to improve the experience without adding functionalities that currently do not exist in the app, such as live-tracking of the user's food delivery.
After the user has confirmed their order, they arrive at a screen that thanks them for their purchase and includes an estimated arrival time, their order status, and map.
Depending on their purchase, the estimated arrival time will either state "as fast as possible" or the delivery time they have selected during the order (e.g. "Pre-ordered at 17.30").
What this screen does not tell the user
The time that the order made. While there is an estimated time of arrival, the screen does not say when the order was made by the user. This makes it difficult for the user to track because they cannot compare the time difference between when the order was implemented and the time it takes for the order to be delivered.
The time that the order was picked up by the courier. it would be very useful and reassuring to the user to know the exact time when their order has been picked up by the courier. However, since the page is static, it would not be possible to display this information without having to update the page.
The location of the order. While there is a map on the screen, it is a default map and does not display the user's live location. This has created confusion and even panic for some users. One user described, "I live next to a lake and I didn't see the lake on the map. I panicked because I thought I had put in the wrong location!"
Pain points and how to improve them
Through secondary research, I compiled data based on real reviews from EAT.ch customers.
Delivery times are vague, inaccurate, or not displayed. The user already knows that every order is being made as quickly as possible, so this information is not helpful. In this case, an estimated delivery time would be more helpful, as well as providing updates to the page to allow users to see that their order is moving forward.
The live-tracking on the page does not work. The static map is confusing users into thinking there is live-tracking when clearly there isn't. It has also created anxiety for some users. Until a working map is implemented, I think it's best to remove the map altogether.
The tracking of the courier is done on an external app via SMS. One user wished that the entire experience could be done within one app. Another user has their SMS notifications turned off so they did not even know that this feature was possible, and therefore only relied on the static page. This could be resolved if the page would automatically update every time there was a status change.
1. Thank you! Your meal is coming right up.
Once the order is placed, the user is taken to the default "Thank you" page. Here, the countdown begins. A timestamp telling the user when the order has been placed. The text below indicates the next step: "Now waiting for restaurant confirmation."
In the green text, the app reassures the user that further updates will be handled on this screen, as the page will automatically refresh when there is a change in their order.
2. Ding ding! Information received.
The timeline is now visibly active. The user can see that their order was confirmed at 17:54 and is being prepared.
3. We're on our way! Your dish is ready to go. 😎
This part of the journey will be the most anxious for the user. Now that they know that their order is on the way (and they are hungry), expectations are high.
At this point, all we can do is reassure the user by letting them know that due to forces outside of our control, their delivery time may be affected: "We are operating during peak hours, so please note that there may be a slight delay in delivery time."
4. Almost there! I know! We can't wait either.
This may or may not be factual, but by this point the hungry and excited user is checking the page more frequently. So, the screen refreshes once again after the driving time has reached its halfway point to show a slight update in status.
The timeline doesn't change on this screen, just the illustration and text.
5. We're here! Enjoy your meal. 😋
Once the driver has reached their destination, the screen changes to the final screen. The arrival time is displayed, order is complete, and hopefully, the user is happy!
Reassurance is key to a good experience
Based on user reviews and feedback, I learned that a hungry user is looking for transparency but reassurance. If live-tracking was possible, then the user understands that they have access to the information they need.
However, in the case that that isn't possible, then what we can offer is reassurance to the user that their order will arrive. Because that's really all they want to know.
And if their order doesn't arrive? Well, that's for another case study. 🙂
All illustrations are copyright of Just Eat Group