Brief: To build a new feature for Swiggy which will allows multiple people to add food to a single order using their own devices.

I came across this problem statement through one of the whiteboard-challenge practice websites. It really got my attention, as this was something I personally experienced and felt trouble dealing with.

Total Duration: 2 Days

Research

Before jumping on to anything, I wanted to understand if it really was a real problem or just something that only I felt. So I did secondary research to dig out some data around group ordering. Here is what I found:

Explanation: Because of the lockdown imposed, people are spending more time with their families and friends, increasing the order size (items per order) by 20% compared to the pre-COVID era. Orders with meals for 3 or more persons have recovered well and are higher than even pre-COVID levels currently.

So there is a need. And honestly, I would have skipped this problem statement if the data showed otherwise because, being a UX designer, we want to solve for real-world scenarios, right? The last thing we need is another eye candy two-screen design.

The next big question is: How deep is the problem? What are the challenges that users face? Here are some scenarios that I could think of from the top of my head:

1. If you are a group, deciding upon a single restaurant to order from isn’t straightforward.
2. Ordering from multiple restaurants can lead to higher delivery charges
3. There are conflicts between what to order
4. It doesn’t make sense to create multiple food orders at the same address at the same time.
5. If people are ordering before a party (let’s say from their home), then there is a lot of jumping between messaging app to communicate their choices.

Brainstorming

Now that I know I am headed in the right direction, time to pull out the big guns, post-its! I pulled up a bunch of them and started listing down the use cases of such a system (I also tried sketching scenarios for the important ones to create a better understanding):

1. Delay in ordering

Waiting for food is the worst! Especially when you are having a party. But most of the time, we are at fault because someone couldn’t decide their order or someone forgot to place the order. This leads to an overall not-so-good customer experience.

2. Bill Splitting

If I only had a penny for every time I had to ask people to return their share of the bill. There is just so much back and forth.

3. Limiting Restaurants

Let's say you only want people to order from the best discount places. Or it is a themed party like “pizza night.” Or you want to restrict people from ordering from far away places.

4. To avoid multiple orders, guest need to see what others are ordering

5. Addons should be only visible to the host before the checkout process otherwise everyone might end up adding the same thing.

6. Not everyone is hungry or wants to decide what to order. So they can simply opt-out

7. Sometimes people will be ordering before the party starts while sometimes they will order during the party

8. It’s essential to mention the right amount of serving here else it could lead to food wastage or food shortage.

9. Budgeting for a party is an important factor, especially for college students.

Here are some basic assumptions that I have made to keep things simple:

1. A Single delivery partner is delivering the orders
2. Delivery timelines of different restaurants would align and not be an issue
3. Collecting the orders will be based on the factor of preparation time and distance from delivery to make sure food remains hot
4. All the items on the restaurant menu are tax inclusive.

Design

I divided the whole thing down into two flows — first, the leader of the party, and second, the invitees to the party. Then I created some quick rough wireframes for both the flows serving all the use cases defined above. I have integrated this feature into an existing food delivery app, Swiggy (which is a largely India-focused food delivery platform). And I have tried to follow their design system end to end. Here is how the final design looks:

Creating a Party

I have intentionally selected the top right position for the ‘party’ feature as the top navigation will be fixed, making the new feature noticeably. The person hosting the party will be the Admin/leader; invitees can either join by scanning the QR code (if they are nearby) or through an invite link (if they are away and ordering before the party starts).

Joining a Party

Invitees can join either by scanning the QR code or just tapping the link shared with them.

Party Setting

The Party feature will have three important settings again based on the use cases discussed, party menu, set budget, and set timer. The party menu will show some important metadata like the location, cost, and vegetarian/non-vegetarian/vegan category. This will help the admin make sure the restaurants are not too far from each other, and the budget is under control.

Ordering Status

If an invitee is not hungry or can’t decide for himself, he can set the status to inform others. And through the top-right menu, he can also choose to exit the party.

Ordering Food

Even if the restaurant restriction setting is enabled, the invitee would see other restaurants if they want to order from someplace else or just wants to discover. The cart will have the name of the person who has added the item next to it and a “total serving” number fixed next to the bill to avoid food wastage. After placing the order, the total amount can be exported to another app, ‘Splitwise,’ which will help distribute the bill among the party members.

Few ideas that I initially considered but rejected:

1. Simply linking users’ carts through a code (just like we invite people on computer games) could have been another way, but I preferred this system more because it’s much more interactive and brings in other features.
2. Friends could be directly invited by implementing a search functionality but that’s a slightly difficult process (because there are so many people by the same name and it’s difficult to verify) and could lead to Swiggy looking like a social media platform.
3. Party could have been saved as a group on Swiggy for the future. But in every other party, one or another member is missing and most of the time the group members/party members aren’t the same.
4. Since most of the users don’t have a profile pic on Swiggy, placeholders could be used initially with an option to change the profile picture in the account settings.

Let me know what do you think about this or what more could be done to improve the experience for the user.