The Background

Over the past few years, Swiggy has grown from a food delivery service to a one-stop convenience platform. We introduced new business lines like grocery, pick-up and drop and so on. Even though there were some bumps during the covid phase, currently there are over 14M active users on the app. Food service alone has over 2M daily orders.

Digital payments have grown manifold in the past few years in India. But most of them still involved a multi-click process with the inconvenience of switching between Swiggy and bank screens, dealing with OTPs or PINs and frequent failures. In the beginning of 2022, ~65% of the daily transacting customers went through this friction while paying and 15% faced one or more payment failures.

One-click payment is possible on wallets, but even there, customers need to ensure they have sufficient balance maintained. Even though we had our own wallet — Swiggy Money, its adoption was as low as 1.5% of daily transacting customers.

The Challenge

The company’s vision at this point was to increase the profitability of food delivery business and expand the new services to more cities. We wanted to make food unit economics more positive by increasing the number of orders per day, average order value, etc.

To support this vision, our high level goal was making checkout seamless (by eliminating or handling errors gracefully), and convenient (by reducing the friction of multiple steps).

Buy Now Pay Later services had been gaining traction in the digital payment industry in the country. Given the increased convenience it offered, the challenge was to evolve with customers and make payments almost invisible — just tap to pay and we’ll take care of the rest.

Customer Insights

Our research team helped us with a market research to understand user perceptions, adoption and usage of other BNPL services and existing BNPL payment on Swiggy — LazyPay.

To understand the broader checkout schema, we also conducted user immersion sessions, where we invited people over a phone call to talk about their payment preferences, challenges they faced, etc.

Some insights we discovered:

• Users adopting BNPL services were already comfortable with other digital methods like UPI and wallets. Most of them didn’t use credit cards either as getting approval was difficult.

• BNPL users on Swiggy (lazypay) liked the online onboarding and one-click payments. They were frustrated with short repayment periods, low credit limits and unawareness of high late fees.

• People usually sticked to what payment domain they were comfortable with. Even though more convenient methods were available. For eg. users paying with UPI were generally tech savvy but didn’t feel the need to keep money aside in wallets.

• Most of them preferred trying a new method if they were getting a discount or cashback.

The Approach

One thing was clear after this. Convenience didn’t just mean reducing the friction or number of steps while paying, but also keeping in mind what the consumers felt comfortable with. 

Payment preferences are based on trust. We needed to build trust in the most seamless way possible. 

Surely Pay Later and other one-click options were useful for the most frequently ordering, digitally savvy, power users. But we needed a whole array of seamless payments taking care of what’s best for all.

This was the beginning of introducing a native suite of Swiggy Payments — UPI, Wallet (Swiggy Money), Pay Later, and Branded Credit Card —  each serving its most trusted users. And since they were all going to be built on Swiggy, it meant less payment failures, instant refunds, and users didn’t have to switch between multiple apps.

How we got there

Each native payment product has its own story. I was closely involved in building all of them with 3 other designers. For now, I’ll mostly focus on how we designed Pay Later.

The grand schema

My earliest challenge was to propose how we would package the native payment products to users and how Pay Later fits in the grand schema.

Should we keep it separate from the existing Swiggy Money wallet and upcoming Swiggy UPI? Or should we have one umbrella for all of them. To figure this out, I partnered with my product manager to design possible combinations and narrowed it down to 2 concepts. 

Concept 1: Keeping 3 separate payment options

(Left) Payment page showing Wallet and Pay Later. (Right) Account management for all 3 options

Concept 2: One umbrella Swiggy Pay with Wallet, Pay Later and UPI

(Left) Swiggy Pay with balance combined from Wallet & Pay Later. (Right) Umbrella account management

I started showing these around to the folks at Swiggy — who not only work here but most are avid Swiggy users themselves. We debated a lot about first impressions, usability, design decisions, pros and cons, etc.

Since this was the first exploration in this direction, previous data couldn’t help us drive a decision. And the team wasn’t ready for a full scale A/B testing due to time and resource crunch. Clickable Figma prototypes were very effective to get feedback from the team and helped other stakeholders easily visualise the possibilities.

What did we learn

1. Keeping the 3 options separate gave people a freedom of choice and they felt more in control. 

2. Understanding the umbrella term was difficult since it was a new mental modal. Especially when limits kicked in for wallet and credit.

3. For the combined approach, people asked questions like “where is money is coming from?” They were concerned about debt/late fees.

Ultimately we decided to go ahead with the first approach — A native suite with independent payment options. It was more user friendly and aligned with our goal of making payments seamless.

Partnering Up

After we had clarity on what we wanted to build, our business team partnered with Lazypay — the existing BNPL provider on Swiggy. 

• This was a win-win situation since both companies would benefit from growing their user bases.

• We could use their backend architecture to ship our products faster.

• And there was an initial validation that people liked Lazypay on Swiggy, although the penetration was low.

What it meant for the users

From our customer insights we knew the existing Lazypay users were frustrated with short repayment periods, low credit limits and inconvenience of switching to another app. The last thing we wanted was Pay Later becoming the same.

Fortunately, since everything was gonna be built on Swiggy it meant less friction and better communication at a single place. Also, Lazypay agreed to set a unique credit limit just for Swiggy orders.

Next steps

The challenge for me was to understand constraints and possibilities this architecture brought in. We had a lot of discussions with Lazypay’s product and design teams in the coming days. A few things I learned:

• New users had to go through a KYC process to unlock higher credit limits. This along with the repayment of dues could only be run on Lazypay which we decided to open in web within the Swiggy app. 

• There were different cohorts of users we needed to consider. For eg people using Lazypay on other platforms, existing Lazypay users on Swiggy, new users, etc.

• The tech was built to identify the cohort just with a mobile number, so we could explore a personalised experience for them.

The Onboarding

Designing the onboarding experience was one of the biggest challenges in this project. We knew we had identified the usefulness of Pay Later for the right target audience. But first we had to get them try it out.

When figuring out the the grand schema, we thought of a onboarding users with a bottom-sheet. This is how it looked like:

When we were showing this around to people, we realised it didn’t really communicate the value of Pay Later strongly. Seeing some bullet points in a bottom sheet didn’t excite people to try it out. Also, we could have done something better after users made their first payment.

But there was bigger problem — the KYC process. 

From Lazypay we had learned that the was a cumbersome and long process where you had to enter your personal details, upload documents, etc. Imagine when you’re hungry we ask you to do all that. We feared people were likely to skip and pay with something else.

I asked myself two questions:

• How might we onboard users with a bang! An experience that creates excitement and pulls them into trying out Pay Later?

• How could we reduce the initial friction? Make the first time experience satisfying ? Getting people as fast and smooth as possible to feel the real value of Pay Later — convenience.

Keeping all this in mind, I took a visually heavy and story driven approach for onboarding. The intention was to create an experience which would take users to a whole new world of Pay Later.

I proposed a gamified experience where users could try Pay Later with just one step of mobile verification. This ofc meant a limited credit and settlement time — which wasn’t the upto the full potential of Pay Later.

The plan was to let people try it out first, understand the value they are getting, and ask them for KYC later — for instance when settling dues. 

We discussed this with Lazypay and they really liked the gamified approach. But there was one challenge. The KYC flow was supposed to be running on their backend. Although we all agreed the proposed flow was much better in terms of UX, revamping the entire flow required the engineering team to rewrite the architecture. This would have easily set us back by two months.

What followed was a series of discussions and debates. We finally aligned on keeping the KYC experience to what Lazypay had already built. We still wanted to make it feel like a Swiggy experience. We convinced them to change the UI tokens like colour, typography, etc. according to Swiggy’s design system.

Involving the experts

Parallelly I was working with our content strategist to figure out product and marketing copies. We had already identified user segments from our discussions with Lazypay. The goal was to personalise the content and bring the maximum value to each segment.

We collaborated on spreadsheets (left) to figure out the entry points and translated it to Figma (right)

Another aspect of any native payment was managing it. We were thinking of one stop to add money, settle dues, see previous transactions, etc. Swiggy Money already had this framework, but the team was working on new features at this point like gift cards & currencies. 

I won’t go into the details, but it involved massive changes on the existing design. I collaborated with two other designers to figure out a common framework for all native methods. It made sense since everything was eventually gonna be part of the larger consumer design system.

A glimpse of the framework we designed for Swiggy Money, Pay Later, UPI

Fighting Battles 

People were mostly aligned on the overall approach. Everyone really liked the simplified one-step onboarding for first timers and the management framework for native payments. 

Contrasting Opinions on the Visual Direction

An immersive experience with the purple branding made Pay Later look like it wasn’t part of Swiggy. We included our marketing team in the discussion and they had a similar opinion. 

In the end, the team was more aligned on keeping every Swiggy native payment under one brand. Anything too far from Swiggy’s look and feel and we might not be able to easily leverage the trust people had. So, we moved forward by redoing the visual styles.

I tried to defend my decisions explaining the intent behind it — creating excitement among the users and pulling them into trying it out. I perhaps had a different vision here — giving each native product its own personality and not keep everything same just for consistency.

However, the team thought about it differently and I was not in a position to influence it at this point.

The Dreaded Deferred Flow

Our legal team strongly objected on allowing users to transact without a KYC. It was very upsetting since we were all set on the gamified approach and ready to handoff the design to engineering. This was a big shocker!

The government has mandated the KYC (Know Your Customer) process for any financial institution to establish personal identity and avoid any frauds. We could have still used it for a limited time per consumer but it was a grey area. The laws could become more strict any time and we would have to revamp the entire product overnight.

We went back to the board and did some rethinking on the onboarding process. The only way was to let go of the one-step trial and complete the whole process. We talked to Lazypay and discovered that ~70% of the people completed the process when they had to enable Lazypay on any other app (like Swiggy previously) — which kept our optimism alive.

Bringing it all together

Onboarding

Payment

Quick Payments

Reflection / Learnings

While I was moving forward, I was constantly collaborating with the team for feedback, showing prototypes to get consensus from stakeholders and senior leadership. Since there wasn’t enough data to help drive a decision, we spent a lot of time debating design decisions.

Managing feedback and bringing everyone to a consensus was challenging. When swimming in a sea of different viewpoints, it was important to learn what to focus on and when.

This project involved a lot of stakeholders and panned out on multiple touch-points. It was important for me to look outside tasks, uncover restraints and keep in mind the extensibility of the system. It was a reflection on knowing my strengths and filling any gaps by involving the right people at the right time.