Case study Uber Eats: feature to buy from 2 different restaurants in the same order

Ironhack’s project — Research and UI/UX Design

Let’s imagine something together! It’s evening, you had a long day, you are tired, probably like today, and you are at home with your girlfriend or boyfriend! Starving! And here we go on the classic question in every couple’s life: what are we going to eat? Awkward silence. The last thing that you want to do is to go to the kitchen or leave the house and dine in a restaurant. So, the obvious answer is, what else, but delivery.

You start looking at the options on Uber Eats, and think that pizza is exactly what you need! Too bad for you though, your girl or boyfriend actually is in a Japanese kind of night mood. What to do now?

Possible solutions: First, one will have to convince the other to give up on pizza or maybe sushi. Second, you will need to pay twice the delivery fees by placing two different orders, with a big chance of eating at different times.

But, what if you could order from two different restaurants in one single order using Uber Eats?

My role

This week I had the pleasure of working with my client Pedro, a classmate who, for a single and same meal, has this urge and need to buy from two restaurants on the same order from UberEats. For our purposes, this activity did not take into consideration any constraints, especially on the business side.

The mission of this project was to analyze an already existing app and incorporate a new feature into it. The feature I developed was based on an area of functionality, to be explored and compared with user input. Based on research, iteration, and testing, this project will culminate in a high-fidelity prototype of a native app that reflects my best path forward.

Timeline

I had 4 days to work on this project, Monday through Thursday. As there were just a few days, time management was essential. I divided my days and allocated my tasks as follows:

• Monday: desk research, client interview, user story, user flow, and guerrilla research.
• Tuesday: user journey map, low fidelity, and testing.
• Wednesday: mid-fidelity and testing and high fidelity and testing.
• Thursday: finish high fidelity and testing, and presentation preparation.
• Friday: presentation.

Research methodologies

To better understand the problem, I used the following research methods.

• Client interview
• User story
• 1:1 interviews (Guerrilla research)
• User Journey Map
• Benchmarking

Client Interview and User Story

First, it was essential to talk to Pedro and better understand the scenario and his perspective of the problem. According to him:

As a user of Uber Eats, I want to be able to buy from 2 different restaurants in the same order. So that way, my girlfriend and I can eat different dishes without having to pay for 2 delivery fees.

Research statement and goals

My main goal was to better understand how people use Uber Eats when they want to order different food. To achieve that, I tried to understand the user’s mental model when using food delivery apps.

Questions I needed to answer:

• Who are the users, and what are their goals?
• How does the assigned scenario fit into their day?
• What’s the hypothesis about how the new functionality will change their behaviors?
• How should the new functionality tie into the navigation of the product? You are expected to try variations.

Recruitment criteria and process

For this study, I looked for Uber Eats users who have placed meal orders for themselves and at least one other person, on the same occasion. My criteria were:

• Have ordered food for more than 1 person
• Have ordered food online using apps at least once in the last month
• Portugal residents

As food delivery is a subject almost everyone is a part of, I had no difficulty finding people to interview. Hence, I didn’t need to carry out surveys to find interviewees and interviewed 5 people for this project.

Questions

I used the open-ended questions listed below as a guide so I could get all the answers I needed throughout the interviews.

• How many times do you order food from delivery?
• In which situations do you order food from delivery?
• Which delivery apps do you use? What makes you choose one or the other?
• Can you tell me a little bit about your experience ordering delivery when you’re with someone else?
• When people don’t want to eat the same thing, how do they handle the situation?
• Would you use a feature that would allow the same delivery person to pick up both orders?
• Would you be willing to pay a little more, but not twice as much, for the same delivery person to pick up the 2 orders?

For all interviews, I used the open-ended questions listed below as a guide to solicit the answers needed.

• How many times a month do you order food delivery?
• In which situations do you order food delivery?
• Which delivery apps do you use? What makes you choose one over the other?
• Can you tell me a little bit about your experience ordering food delivery when you’re with someone else?
• When you and the people you’re with don’t want to eat the same thing, how do you handle the situation?
• Would you use a feature that would allow the same delivery person to pick up both orders?
• Would you be willing to pay a little more, but not twice as much, for the same delivery person to pick up the 2 orders?

Analysis and synthesis process

After each interview, I summarized the information in order to categorize what the pain and gain points were, and other relevant information on solving the problem.

Overall, not being able to order from different places is a problem. To solve this, users accept to pay 2 different fees or else negotiate for the other person to accept the restaurant.

User journey map

I had a lot of invaluable insights during the interviews, and to better visualize all the data, I built a user journey map to better comprehend the opportunities.

After the research part ended, the participants confirmed positively that the user story I created was accurate and correct. And it was time to think about interface solutions.

Happy flow

I’ve come up with this happy flow even before starting the ideation part. As I mentioned earlier, this activity did not include any possible business constraints, so my creativity wasn’t limited.

Two major aspects were crucial in envisioning the logistics for the success of the main task: limit the distance between the possible restaurants to be chosen after the first one and the option for the user to choose which the delivery person should pick up first. With that in mind, let’s talk about prototyping!

Prototype

The prototyping process went through low, mid, and high-fidelity. In each of these steps, I tested with my client and other 5 users. I repeated the process several times to ensure my design met the user’s needs.

Low-fidelity

I started low fidelity using pen and paper. That way, I managed to quickly translate my ideas to the paper and have a better picture of the structure, layout, and information architecture. As soon as this was done, I was able to quickly iterate, and improve.

Mid-fidelity

When I was satisfied with the iterations that I did (number of times I have repeated the process) with my low fidelity, it was time to translate my low fidelity into mid-fidelity. For this part, it was time to think about buttons and spacement.

High-fidelity

This is the final version of my high-fidelity. The main task of the user is to: access the application, see the banner of the new feature, choose a pizza, add it to the cart. After that, he sees the button to make a purchase in a second restaurant, chooses sushi, proceeds to checkout, and chooses that sushi to be collected first.

Iterations Low to High-fidelity

Below, you can see the main screens’ evolution from low to high fidelity.

This is the landing page of the app. As you can see, I’ve placed a banner to ensure that all users are aware of the new feature. During the tests, the banner changed its position to match more naturally with the flow and visual of the Uber Eats app.

This is the page that appears after the user adds orders to his cart. On this page, the user will see a button to continue ordering but in a second restaurant. I made some changes in the text of the button because as per the users, they didn’t think it was clear enough. After running some tests, “add extra order from a different restaurant” made the action intuitive and clearer for the users.

When users click, they see a text explaining that the restaurants being shown are within a 10-km range from the first one. The reasoning and logic behind using a green background in this part was to make it clear and bring to the users’ attention that this is a second purchase and that it is from a second restaurant. I initially tested with black text and with a background, and people ended up ignoring the text. But after the change to green, all 5 users saw it perfectly.

The last part is one of the checkouts pages, where the users will have the opportunity to choose what they wish to be collected first. In some instances, you can order a cold meal and a hot meal. For example, a salad bowl and a pizza. When this happens, it is ideal for the delivery person to collect the salad bowl first since it’s cold.

Next steps

• Talk to the stakeholder about the viability of the feature
• Continue iterations

Reflections

After successfully accomplishing my tasks, I have 3 major takeaways from this project.

• Learn from your interviewees and in order to do that, you need to make and ask the right questions
• Adopt best practices in Figma as this will make your life easier during the iterations
• Great design is the result of the repetition and constant improvement of good designs (Repetition is the key).

Tools: Guerrilla research, User Story, User Journey Map, Atomic Design, Low-fidelity, High-fidelity, Prototyping, and User Testing.

Technologies: Pen & paper and Figma.