Case Study: Swiggy Schedule & Subscriptions, enhance your meal planning concept
📝 A detailed case study that highlights my design process in designing for a new feature of the Swiggy app
The Problem Statement
A lot of people depend on food delivery services for their meals. During open-ended research, it was revealed that many regular users feel that while there are several options for them to order from, they don’t tend to have time on their hands when they want to order food.
The product team wants to solve this disconnect by building a feature to schedule orders and extend it to create weekly and monthly subscriptions.
Full Problem Statement is available here
Role
Product Designer and Researcher
Time Taken
Around 2 weeks, 4–5 hours daily
Getting Started
Defining task
As a Product Designer, I have to build a first-time user experience for customers enabling them to schedule and subscribe to meals.
- The scheduling feature allows users to order their meals in advance at a specific date and time as per their needs.
- The subscription feature allows the users to pre-order their meal of choice on a weekly or monthly basis.
Deciding the platform
I had to choose between the existing food delivery apps which comes to — Zomato and Swiggy, both being in the food delivery business where:
Swiggy is more inclined towards becoming a delivery specialist (Swiggy genie, Swiggy POP, Genie, Bookshop) while Zomato wants to be a food specialist (Restaurant POS, Ads; Offline canteens, B2B food sourcing)
I chose Swiggy because of its intuitive design and clean architecture. The vision of Swiggy is also a significant criterion that relates to my problem here.
Who are the stakeholders?
Swiggy provides a platform for both restaurant and customer needs. It is obvious for these features to work, one has to consider objectives, needs, and frustrations for both our stakeholders
- Customers of online food app
- Partner Restaurants (Restaurant staff members)
What are their objectives?
Made some hypotheses on the objectives of both Customers and Partner restaurants in regards to the scheduling and subscription feature
From Business POV — Repeated orders will generate more revenue. More successful deliveries will drive more restaurants to opt-in for the scheduling and subscriptions feature. Hence this will enhance the business model and user acquisition for the product.
Research & Empathize
Did Research to-
- Understand the current food ordering journey and validate my assumptions
- Identify the factors that affect the food ordering process
- Discover any new problems that exist underneath
- To understand the need for the feature and if it’s worth it?
- To figure out how the scheduling and subscription model should operate
Secondary Research
I started looking over articles, quora, and google analytics and scanned all the food delivery apps for similar features like Dominos, Zomato, Pizza Hut, etc., to find out the following:
- None of the apps(except Dominos) had any scheduling-specific features.
- None of the food apps had an order subscription feature of any sort.
- Favorites or Past orders are closest to what helps users in repeating orders (yet not enough)
Primary Research
I also carried out Primary Research with friends who often depend on online food delivery apps for their meals.
Key Insights
Our Customers —
- Want guarantee of timely orders without friction (Assumption validated)
- Want updates in case of any anomaly, easy reimbursements (Assumption validated)
- Often miss and skip meals in tiffin service (New problem identified)
- Want coupons and added offers — increases chances of subscribing to an order(New insight identified)
- Often scan their Past Orders to search and place an order (New insight identified)
Our Restaurant Partners —
- Want more customers and popularity, which in turn increases revenue (Assumption validated)
- Need a list of scheduled items for planning and preparations (New demand identified)
- Want to retain customers even on cases with item unavailability. (New problem identified)
- Can serve only at their convenience and time-frame (Assumption validated)
Analysis & Ideation
User Personas
From my research and interviews, I found that based on the food intake behavior and daily life pattern, I can categorize customers into three personas stated below
User Storyboarding
I framed several use cases for the given personas to empathize with their pain points and define feature objectives, as they provide for users need —
How might we?
- HMW make scheduling and subscription a seamless experience for the user
- HMW let restaurant owners have control over what and when they could deliver
- HMW highlight the consideration that restaurants have for customers and strengthen the trust between them
- HMW ensure that in the case of anomaly, customers face no friction
- HMW implement a solution that adds to the business revenue model as well
Some key fundaments, on which the feature must be built for our Users and Partners Restaurants —
Assumptions
- It is possible to develop and deliver the scheduling and subscription feature from a technical perspective.
- Partner restaurants have agreed to opt-in for scheduling and subscription features for at least one week and three months, respectively.
- Partner restaurants update their Partner app data regularly.
- Delivery of meals will be done on time without any delay, specifically for scheduled and subscribed items.
- Last but not least — Swiggy customers will use this feature.
👉 Assumptions are the record or data we believe are true but can’t verify them at the moment due to lack of time and resources.
Introducing Swiggy Schedule ⏰
What is the Scheduling feature?
A feature that allows users to get their meal delivered at their preferred date and time.
Scheduling will provide users total control over delivery, enabling them to reschedule and cancel their orders at their will.
How audience can use it?
It is essential to layout the primary user controls and permissions for the new feature design.
Customers should be able to:
- Schedule their meals from the available items listed by the restaurant
- Track the scheduled order and reschedule it
- Cancel the scheduled item (existing cancellation policy applied)
- Add a note for specifications on the scheduled order
- Connect with restaurant staff for confirmation or other inquiries (through chat or call)
- Get updates on their scheduled orders
Restaurant Partners should be able to:
- Accept and confirm the scheduled order
- Reject and send alternatives(items and open schedules) to the customer
- Reject the order altogether(unusual)
User flow and Architecture for Scheduling
Exploring UI patterns and designs
Before diving into wireframes and designs, I thoroughly scanned every corner of the Swiggy app that helped me to understand — how to align my solutions with the current design idealogy and UI patterns of the app.
Scheduling an item
An item can have different availability status. To understand this concept, I went through Partner App introductory videos on Youtube from where I concluded that the items could be:
- Available — can be ordered, can be scheduled
- Unavailable for today — cannot be ordered today, can be scheduled except for today
- Unavailable for unknown time — cannot be ordered, cannot be scheduled
Case 1: Scheduling an available item
To schedule an available item, the user has to check the Schedule Delivery button and select a date and time from the slider which appears next. Item scheduled successfully 🎉
Case 2: Scheduling an unavailable item
Unavailable items are the ones that will be marked available by the next day. The idea is to provide users an option to book(schedule) these items in advance.
Restaurants are upset about the fact they lose customers over item unavailability. Since customers can schedule items for over a week — marking unavailable items open for scheduling wasn’t a problem but a solution to retain customers.
Partner App: Marking Item Availability
I almost understood the working and usage of the Partner App and drafted a basic user flow for how restaurant staff can manage the availability of items through their Partner App.
Tracking the scheduled order
Both the regular and scheduled order is handled the same way, except for scheduled order — users get a time gap as it is added to the scheduled list of restaurants before going active.
Case 1: Scheduled order is accepted by the restaurant
After an order is placed, the restaurant accepts it(usually). Users can reschedule a confirmed order before it goes active.
An order goes active when it is marked as “Food is Being Prepared” by the restaurant, which is done at max. 1 hr before the scheduled delivery
Case 2: Scheduled order is not accepted
A restaurant might not accept the order due to unavailability of sorts. In such cases, they either cancel the order or provide alternatives to the user. Users can choose from the alternatives or cancel the order to get a 100% refund.
Partner App: Handling Scheduled Orders
To understand if this solution is feasible for restaurants, I laid out basic user flow for the Partner app, focussing on actions they can take on requests of scheduled items
View all Scheduled orders
Lists of scheduled orders should be noticeable at a glance without overshadowing exiting details on the app.
- Home and Search tab — System data only, doesn’t contain any user data or input ❌
- Cart tab — item(s) added from a single restaurant. Not a match for the concept of the scheduled order, also from the tech perspective ❌
- Accounts tab — Account details(rarely used), past orders(often visited), easy user interaction, feasible and usable. Fit for scheduled orders ✔
1. Reschedule or Cancel confirmed orders
Cancelation of confirmed scheduled orders before food preparation starts will cost ₹75 cancelation charges and 100% refund. Post which users are charged a 100% cancelation fee. However, users can reschedule an order until food preparation starts.
2. View Status of Scheduled item
Scheduled orders will fall under categories according to their status of preparation and delivery —
- Once an order is scheduled → Listed under Scheduled Orders
- Once food preparation starts →Marked as Active, listed under Scheduled Orders
- Once scheduled order is canceled or delivered → Listed under Past Orders
Introducing the feature to Customers
Apart from designing for the feature functionality, it was important to make users aware and introduce them to this feature.
1. HomeScreen
The use of Non-modal overlays, which have been used by Swiggy several times before and are perfect for my use here.
Detailed info on non-modals can be found here
2. Nudges
3. Notifications
Introducing Swiggy Subscription 🍽
What are Subscriptions?
A feature allowing users to buy subscriptions of the food items they often order, to ease the daily hassle of ordering meals.
Subscription for multiple meals comes at a discounted price and can be redeemed whenever a user feels the need to order.
It draws inspiration from the concept of coupons used in daily life.
What if you had to pay for your daily milk in cash — Every single day?! Will be a pain to handover small amount of cash daily and track monthly transactions.
User flow for Subscription
Subscribing a meal
Several possible scenarios can be used to motivate users to subscribe. Subscriptions can be made when a user —
- Wants to repeat one of their past orders out of habit
- Search for items from a particular restaurant page
- Orders normally (custom selection of items)
Case 1: Subscribing a Past Order
A user wants to repeat the order from the past orders, chances are they repeat more than just once — enters Swiggy Subscription✨
Case 2: Subscribing through Restaurant SwiggyBOX
SwiggyBOX items are hand-picked meal packs prepared by restaurants for their customers. These wholemeal packs are purposely targeted to customers who order lunch and dinner more often from a restaurant.
- SwiggyBOX Subscription for first-time users — Since, this is a new meal concept, so restaurants can provide first meals for free to their customers who opt for SwiggyBOX Subscription. Post which customers can make their decision to continue subscription pack on basis of food quality and quantity.
- Assumption — Restaurants are willing to provide their first meal free for customers who opt for SwiggyBOX Subscriptions, can be compensated with other revenue models
Case 3: Subscribing a Custom order
Users can also make custom subscriptions from the list of available items provided by the restaurant. In such a case, they can avail subscription discount.
Case 4: Money based Subscription
I researched daily food cost per person in India and came across several articles claiming different values, from which I found average cost ranges from ₹100 — ₹500.
A subscription plan for the above prices range can be availed on a weekly/monthly basis. This is how the model would work —
- The user purchases a money based subscription
- The user will provide their list of favorite items(editable) to the restaurant (mandatory & extras included)😍
- The restaurant makes a tiffin/meal from the list provided, according to the price plan chosen by the user
- The user gets their subscribed meal whenever they want🎉
Couldn’t design wireframes for this idea, as it required much thinking and brainstorming and I was under a time constraint.
View all Subscriptions
After a user has bought a subscription, they can view it from their accounts section. Based on usage, a subscription can be categorized into —
- Active subscriptions — The user has at least ordered/scheduled once from this subscription pack
- Inactive subscriptions — The user has not ordered even once from this subscription pack
- Past subscriptions — The user has ordered all the coupons from this subscription lot
Redeem your Subscription
While redeeming a subscription, user objectives must be kept in mind. A subscription can be redeemed or used by the following options —
- Placing an Order from Subscription
- Scheduling an Order from Subscription
Edge Case: Say a user subscribed for 2 orders weekly for 2 weeks, they ordered a week’s order(2) in one day and now want to order from next week’s subscription. In such a case, user can redeem their subscription with a confirmation message, after all, they have paid for the meal and can have it whenever they want ;)
Introducing feature to the Customers
Banners, Nudges & Tooltips
… and that’s a wrap 🎉
What else?
Edge case
Expiry Concept: Say a user subscribed for 4 orders a week, now the week has come to an end and the user still has 2 orders left under subscription. In such a case — should the coupon expire? should the duration of the plan exceed? — if Yes, then by how much time?
Implement more ideas
- Naming a subscription — Need of naming subscription may arrive in case of a different order
- Design the wireframes for Restaurant(Partner App) as well
- Design for Money based Subscription Plan
- Test the idea on real-time customers and re-iterate
Resources —
