BunBite

A food delivery app that is designed to satisfy users' need of exploring different food flavors in one order - either just for themselves or with a group of friends.

Have you ever wanted to get a meal from one restaurant and a drink or dessert from a store right next to it?

I have. But unfortunately, most delivery apps only allow orders from one restaurant at a time. So to achieve this, one would have to place two separate orders, pay service and delivery fees twice, and make two drivers go the same route at roughly the same time, which can be inefficient and costly.

What if there is an app that allows users to place orders from multiple restaurants at once?

For the capstone project, my team explored this idea and designed a solution that helps with this problem.

Team

Yuqiao Wang

Yichuan Zhang

Ellie (Qi) Zhou

Research Methods

Competitive Analysis,

User Interview,

A/B Testing,

Usability Testing

Design Tool

Figma

Duration

3 months

(Spring 2021)

Solution Overview

So, how exactly did we approach this problem?

Week 1-4: Idea Brainstorm & Exploratory Research

Research Question 1: What do other food delivery apps offer?

Research method - competitive analysis

We conducted a competitive analysis with 8 other well-known apps/services on the market, including Chowbus, Uber Eats, GrubHub, DoorDash, EatStreet, Postmates, Instacart, and Yelp.

Key finding: our product idea could be a key brand differentiator among competitors.
Only two out of the eight apps provide what we would like to offer, and each of the two has its own disadvantages.

Research Question 2: Can we generalize this problem to a wider group of users?

Research method - user interview

To answer this question, our team decided to conduct interviews with the target users of our product, which is anyone with food-delivery needs.

Key finding: multi-store ordering is a necessary problem to solve for users, not only when they get food for themselves but also when ordering for a group of people.

Findings from our user interviews indicated that users have a strong interest and willingness to use an app that supports the feature of multi-store ordering, with the expectation that this would lower the delivery and service fees they pay. Additionally, it would align with their current habit of buying food and trying dishes from different restaurants. Two interviewees also mentioned possibly using this when ordering for a group of people to satisfy different people’s flavor preferences.

Week 5-7: Start Designing (Low-Fidelity)

After exploring more around the problem space and confirming our initial thought, our team decided on the following MVP features for our product:
1. Single-person single-store ordering, like any food delivery app offers.
2. Single-person multi-store ordering:

Persona A is used to having her meal along with a cup of bubble tea. She would like to order from one restaurant for the meal and bubble tea from another store nearby in one order so that she doesn’t have to pay the delivery fee twice.
3. Multiple people ordering from multiple stores in one order:

Persona B is inviting friends to have dinner at her place and would like to order foods that satisfy different people’s different tastes and preferences. She would like to order food with her friends from multiple restaurants in one order and have them delivered to her place at the same time.

Each of our team members brainstormed how the interface would look like and how the user flow would lay out, and we each sketched a potential solution. With some discussions around the similarities and differences of our ideas, we defined the overall framework of our product.

However, there were some different opinions around how some workflows should lay out. Instead of making the decision right away, we chose to bring the issue to the users and listen to their opinions. Therefore, we put together different versions of low-fidelity prototypes, all pertinent to our objective but had two major distinctions:

Distinction 1 - selecting multiple restaurants

Start with ordering from one restaurant

and being able to add additional restaurants

Start ordering by choosing restaurants already bundled together

Distinction 2 - displaying menu

Menu displayed by different restaurants

Menu displayed by different food categories

Week 8: User Testing I

Research Question: What is users' preferred way of multi-store ordering?

Research method - A/B testing

The goal of this research is to gather users’ expectations with a product that satisfies multi-store ordering, their unbiased thoughts on the different prototype versions, and their preferences among them. To minimize biases, we balanced the order of presenting the prototypes.
Once the research plan was created, we conducted a pilot test was conducted to evaluate both the testing plan and the low-fidelity prototypes we designed. Some flaws were identified from the pilot test and updates were made before conducting more tests with the additional users.

Key finding: users prefer viewing the menu by restaurant rather than by category, but they had equal preferences for the workflows of starting a bundle order.

2 users liked starting with one restaurant and then seeing the nearby recommendations, while the other 2 users liked starting with bundled orders.

Week 9: Design Iteration (Mid-Fidelity)

Since the users' opinions on how to start a multi-store order were tied, we were uncertain about how to proceed. After some internal group discussions and consulting with our professor, we finally settled on keeping the parts that made sense to the users and combining the commonalities between the two solutions as much as possible.

While finalizing the different prototype versions into one, we also refined more design details and added additional features and interfaces, such as onboarding, inviting friends, order confirmation, bill splitting, etc.

Week 11: User Testing II (Evaluative Research)

Research Questions: Are users able to complete the assigned tasks on the prototype? How do they feel about the processes?

Research method - usability test

With the mid-fidelity prototype, we were able to conduct a second round of usability tests. At this point, instead of looking at the user's preferences and expectations, our focus was more on obtaining detailed feedback on the interface design and the interactions to complete given tasks.

Key finding: overall, users were able to successfully complete the tasks and found the workflows to be intuitive.

All users successfully completed the assigned tasks on the mid-fidelity prototype, although they still pointed out several places that created confusion. From summarizing their feedback, we identified around 20 design changes that could be made.

Week 12: Final Design (High-Fidelity)

Finally, combining everything we learned from the users, we finalized our final high-fidelity prototype. The final product includes the following core functionalities:

1. Place orders from a single restaurant or a bundle of restaurants in one order.

2. Invite friends to a group and order together from one or multiple restaurants. This can be done by sending invitation links or through in-app friends.

3. Pay for a group order in different ways (i.e. one person pays for the entire order, each person pays for their own ordered items, everyone splits the bill evenly).

Final Words

Reflection

Throughout the semester, we followed the agile framework by conducting multiple rounds of research and making design iterations, and almost all of our design decisions are backed up by user feedback. Therefore, we are confident that our product is intuitive for users and is able to meet their goals. It is also crucial to realize that there are additional user groups for our product, such as delivery drivers and restaurant owners, so our next step is to do more research on how the app will work for these user groups. The pricing model is another important matter, as we need to figure out how to charge users with the delivery, service, or subscription fee while ensuring the profit of our product.