Case study: Allowing group orders in food delivery apps

Welcome to my first-ever medium article! I worked on this problem statement in December 2020 and was too nervous to post it but here it goes.

🧐 What is the problem?

An interesting data pattern at Swiggy — a leading food delivery app in India, suggests that people order food from multiple restaurants to be delivered at the same address. These are larger orders when compared to the ordering pattern of the user from that location. The team has come up with the hypothesis that these orders are made for parties & large gatherings. They are exploring a new feature that allows multiple people to add food to a single order using their own devices.

Since I had limited time to solve this problem, I decided to plan out a process to help me reach an optimal solution for this feature.

🕵🏽‍♀️ Research

Right off the bat, a group ordering feature made a lot of sense to me — a feature that would allow both, me and my vegetarian friend, to enjoy food from our favourite restaurants without having to place two orders, resulting in increased delivery fees, tips, and orders arriving at different times.

But before jumping straight into solutioning the user experience for this feature, I wanted to validate the team’s hypothesis and also learn about the current user behaviour.

• When is this feature needed? For large gatherings as per the team’s hypothesis, or with a smaller group of friends?
• What are the other pain points that need to be solved when building a group ordering feature?
• What are the other pain points that people usually face when ordering food that could magnify if we allow group orders?

To find these answers and to learn more about user behaviour with food delivery apps, I sent out a survey to a bunch of people.

While I waited to get enough responses, I interviewed two friends about their experiences with ordering food for multiple people. Based on these 2 user interviews, I mapped out a journey of users who have ordered food for multiple people before.

Scenario #1: Hosting a party for friends

Scenario #2: Casual Sunday evening with family

Based on these, I could conclude that:

• The current experience of having to order food from a single person’s device is definitely a hassle — from deciding on a restaurant to viewing the menu.
• While allowing multiple people to add food in a single order would solve a lot, it still does not solve the frustration of having to order from a single restaurant — which is what Swiggy does today.
• Payment is a unique experience whenever you are with other people — whether it's at an actual restaurant, at a panipuri stall, or from a food delivery app. Making payments depends upon the dynamics of the group you are hanging out with.

Soon, I also received around 15 responses for the survey I had sent out.

Based on the survey, I recognized some major pain points that people face today when ordering with a group of people

Ordering from multiple restaurants

• People use food delivery apps mostly when they are in the company of a few people, not at a large gathering or a party (as stated in the hypothesis).
• This is because in a small group people are more likely to be choosy about what they want to eat. Whereas at parties or large gatherings, people are likely to settle for whatever other people have ordered already.
• This leads to one of the huge pain points which is having to order from a single restaurant when you’re with a bunch of people who all have different tastes and food preferences. This is also backed by the data we had earlier which shows that people are ordering from multiple restaurants to the same address.

The time of delivery

• While choosing a restaurant, people are also extra conscious about how much time it will take to be delivered. While this is frustrating even when you’re just ordering food for yourself, you lose even more patience when you’re with others. This could be because the group only has a limited time to hang out with each other.
• Hence, people would rather order from a restaurant that would deliver food faster, than order from their favorite restaurant that would take a bit longer.

Paying for the order

• Paying for your order in a group can be a confusing experience — who is to be paid back, who is yet to pay, and how much is to be paid?
• Method of payment depends upon group dynamics and varies in different settings — some groups split equally, some go dutch, and sometimes one person pays for everything.

💡Ideation

Based on the research conclusions, I laid down some principles to follow when building the group ordering feature.

• The action of creating and joining a cart should be achieved with the least amount of steps, ideally 1–2 steps.
• Creating a group cart should NOT be any extra responsibility for the Host of the party. The Host is trying to have a good time with their friends — not be an event/food monitor.
• Since we will be allowing users to order from multiple restaurants, the experience of browsing restaurants, reading menus, and placing orders should be the exact same, no new behaviour should be introduced.
• The best possible experience would be if all the orders arrive at the same time — hence they should be delivered by the same delivery partner.
• Due to the time constraints of this problem statement — I have also assumed that the delivery timelines of different restaurants would align and not be an issue.
• The host should be able to decide the mode of payment, and the experience of making payments should remain the exact same, no new behaviour should be introduced.

👾 Visual Design

Discovery of Group Cart Feature

It would be 100% necessary to add a discovery point on the home page of the Swiggy App, so that users would be introduced to the Group Cart feature. However, the home page is used for promoting all kinds of new features in the app. If a new feature or product is introduced in Swiggy tomorrow, then it would replace the Group Cart touchpoint based on various constraints of priority, which makes this real estate rather flaky.

I wanted to introduce another touchpoint that could introduce a new behaviour of creating group carts.

1. Users can discover the feature on the Home Page, after which they are redirected to “Cart”.
2. This introduces a new behaviour of creating group carts to the users. Hence, if Swiggy wants to promote a new product on the Home Page in the future, users would already know where to find this feature again.
3. The action of creating a group cart is a secondary CTA, as the percentage of users who would be creating a group cart would still be much lesser than users who make regular orders.
4. The action of “Joining a Cart” is done via a banner at the bottom of the page, instead of adding too many buttons.

Group Cart Experience as a Host

1. When the Host clicks on “Create Group Cart”, they are redirected to a page that shows details of how others can join their cart.
2. Keeping in mind one of the principles I wanted to follow — that the Host is trying to have a good time with their friends and not be an event/food monitor, I discarded the idea of sending invite links to each person in the group via Whatsapp/SMS or having to browse through a list of 100s of contacts and sharing the invites manually.
3. As I explored several other options, I settled on 2 ways: sharing a Unique Code and a QR Code.
4. Scanning the QR Code is simple because most digital users are already familiar with this action, and the group is hanging out in the same place. There is no effort required from the Host to add people to the cart.
5. Sharing a Unique Code is a behaviour that users are familiar with thanks to the game Among Us. Since the group is hanging out at the same place, this is as simple as just saying the code out loud.
6. Also, if you’re hanging out with a lot of people, you would not want to pass your phone around for everyone to scan the QR code. Hence sharing a unique code becomes the easiest way to invite others to your code. For this reason, this option holds higher precedence. It is the first thing that the user sees and is differentiated with Swiggy’s brand colour.

Joining a Group Cart as a Guest

1. Tabs are used to introduce the two ways of joining a group cart.
2. Based on my assumption that sharing a unique code is the easiest way to join a group cart, it is presented as the default option. User can navigate to the next tab to join the cart via a QR code.
3. However, this can be tracked once the feature goes live, and if my assumption is incorrect, the Scan QR code can become the default tab.

Placing Orders

1. Once a guest joins a cart, the goal should be to quickly let them start placing orders. Hence the only primary CTA shown here is to start browsing restaurants.
2. The information about who joined the cart is a good-to-have, but does not hold the highest priority — you could just ask who has or has not joined the group cart in person. Also, I did not want this list to take up too much space in case the list becomes too long.
3. Considering these factors, information about who has joined the group cart is shown at the top. Users provide their names when they sign up and this value can be picked up from there. Users have profile pictures linked to their emails and this can be fetched via APIs.
4. In case there are technical constraints for fetching a user’s pictures, we can explore other ways such as showing the first initial of the name instead of the profile picture, or simply showing a list of names.
5. In research, it was found that some users care about how much the delivery time would be. A prompt can be shown which warns all users if the delivery time exceeds by 1 hour. However, they should not be stopped from ordering food from restaurants that are far away. This is a decision that depends upon a varied list of reasons happening in real-time and the dynamics and situation of a particular group.

Group Cart behaviour

1. The list of orders made by everyone in the group is shown in the cart once orders are placed.
2. Everyone in the group cart — the host and the guests can view the unique code and QR code again, in case they want to share it with any new guests.
3. “I’ll have what you’re having” — users can click on the plus icon to add another guest’s order as their own. The restaurants will receive this as n number of quantity of the same food.

Paying for the orders

1. While I initially thought about letting the host select the mode of payment when setting up the group cart, it did not fit the principle of making the process of cart creation a 1–2 step process. It added to cognitive load and did not feel natural to make them decide this before even placing any orders.
2. Replicating the real-life experience, the host can choose the mode of payment after everyone has placed their orders.
3. The rest of the payment experience remains the same to not introduce any new behaviour.

Tracking status of orders

1. Users can track orders placed by everyone on the tracking page. In case everyone is paying for their own orders, the status of payments can also be viewed on this page.
2. In the rare case that someone’s payment fails, others in the group have the option to pay for them.

📊 What would I track once the feature is live?

• If the behaviour that was found in research (people place multiple orders to the same address) was eliminated by the introduction of the group cart feature.
• The number of group cart orders made, of course. This would be to analyze the feature adoption and discoverability of the feature.
• Any drop-offs while joining a group cart to analyze if there is a gap in the user experience and the ways you can join a group cart.
• % of carts that were created but no orders were placed.
• The average number of users in one group cart and their respective reviews — to analyze if there is any correlation observed
• The average number of restaurants ordered in one group cart and their respective reviews — to analyze if there is any correlation observed

🤔 Some cases to solve for in the future

• If users want to place the group order before they meet, would the experience change or remain the same?
• Allowing someone other than the Host to pay the complete bill
• To allow or to not allow cash on delivery payment option for group cart orders
• Tracking all the orders on the map
• Cancelling a single order from the group cart after payment is complete

👀 What I would improve upon

• If I had to work on this feature without time constraints I would also research more on what a Delivery Partner experience currently looks like on the Swiggy app today. And what would change with the Group Cart feature. Eg. If picking up a group order earns them more or less than a normal order. If it earns them less, they could decide to never accept a group order, which would affect the overall adoption of the feature.
• I would also think of a better name for this feature that aligns more with Swiggy’s quirky brand image.

🏁 That’s a wrap!

If you’ve reached this far, thank you so much for reading! 😇

Did you know? You can give up to 50 claps on Medium, press and hold the clap icon and try it out! 🙃😁

Connect with me on LinkedIn or Twitter and let me know your thoughts.