Add a Feature: UberEats

The Ask

The challenge asked for the creation of a new feature for a popular app, I chose to give it a try with the UberEats app. The feature had to make sense in the real world and follow the design system the application currently has.

‍

User Research

I downloaded the following apps to get an idea of what the food delivery market was like. Going through each app was the basis of the features list I created.

Five qualitative interviews where conducted in the Brickell area of Miami. The interviews consisted of open-ended questions about past experiences with UberEats and competitors.

‍

‍

The common pain points found from the user interviews, where the following:

• There was a perception of delivery times being slow or the estimated times varying as time progressed.
• In two cases the food that was ordered did not arrive at all, leading to complaints about drivers, and their experiences with customer service
• The users also noticed that as they looked at the map feature, they would frequently see drivers going to the restaurant and disappear, this would later be followed with a later than estimated delivery.
• Another complaint was the  warmth of the food tended to be on the cold side, and this was a very common occurrence.

Jobs To Be Done

In this particular case focusing on the customer jobs section and applying the Jobs To Be Done (JTBD) framework, allowed me to see that there was a bit of service design to this challenge. It was necessary to take into account the links between the restaurants, the drivers, and the end-user.

With this I could use a Value proposition chart to make sure the feature would add value to the business and the users.

Assumptions and Constraints

The assumptions I had with this project was that the restaurant's incentive to report lead times would be strong enough for them to actually do that. This would mean some sort of onboarding and education to the customer, leading to an additional cost for the business.

The constraints on this project where mostly time based, from concept to execution this took 4 days, including preparing a presentation. Because of that I only did the interface for the end user.

Further Research

I asked a lot of Why's, a shoutout to my days of Lean Manufacturing. What became apparent was the following:

• Driver’s don’t get paid to wait in line, and cancel picking up orders if they feel it will take a lot of their time
• Restaurants sometimes don’t begin preparing the meals until the drivers are there, other times they are unable to meet the current demand
• Driver’s cancel on the pickup restaurant based on prior experience (Surprisingly McDonald’s is a common one)

All of this directly contributed to:

• User waiting longer than expected
• Driver taking the blame for the delays, or receiving poor tips
• An organizational behavior issue arrises as there are a lot of moving parts.

‍

The Minimum Viable Product

Introducing UberEats Top Pick.

• 47.8% more prime visual real estate for restaurants
• They can now show up on top of all other categories
• More visibility for restaurants and delivery times are much more accurate than other restaurants.

For a restaurant to enjoy this they must:

• Provide up to the minute accurate kitchen production lead times
• Be located in an optimum distance to the user, taking into consideration the rate of heat dissipation of the food (potential study in the future of heat retention practices Drivers could use)

What will this do:

• Accurate lead times means drivers waste less time waiting for meals to be prepped
• Drivers are less likely to cancel at places that are exact with the meal prep process
• Restaurants will post their lead times, in the optimum timeframe. Where overestimating the timeframe will result in unappealing delivery times for app users; underestimating the timeframe can result in driver’s canceling on the order.

This will benefit everyone:

• Drivers can deliver food thats still warm. Which hopefully means more tips.
• Users are happier with the speed and quality of the delivery
• Restaurants will compete for the Top Pick space, and the systematic solution will result in continually better service.

‍

Sketches (Lo Fi)

Feedback Loop

The first usability tests, tested with 5 users, showed the following insights:

• The icon for the feature was not clear to the user
• Removing the text "Featured" would look better.
• 5 star review pattern on the bottom of the card, actually distracted the user. Instead of indicating a rating they saw it as a way to rate the restaurant.

‍

Interactions (Mid Fi)

The next part was easy. I used the same cards layout that Uber uses, but adjusted the layout to give ample visual space for the new feature.

‍

Usability Testing

I tested with 5 users and found minor navigation issues, that had to do with scrolling on the prototype.

Maze was able to identify where user's where getting lost and showing a heat map.

Most importantly, I did not provide the user with backwards navigation on one screen.

‍

The Design Patterns

To demonstrate how the feature is different from a normal card I made a side by side comparison.

High Fidelity Prototype

Here is a run through of the prototype.

‍

Conclusion

This was not an easy project, every idea that came up had in some way or another already been implemented. The UX team at UberEats are incredible, stepping into their shoes for a week to find new opportunities took extraordinary effort. As the story continues, after this project had been finished a few months later I saw this feature roll out on UberEats.

I finished the project mid September and  took a screenshot when they rolled out the feature around November/ December.

Final Thoughts

This was a project in my fourth week of Ironhack. The reason I go back to it, is because a few months later, this feature actually rolled out from UberEats. This was one of those moments of validation that I had hit the nail on the head with the UX.

read full case study