Background

We launched Groww Pay in 2022. The goal that year was just to build the entire payments infrastructure and scale the product. When I moved into the team, we were already #8 in India for payments by volume ($0.7B monthly) and were managing 2.6M transactions every month.

With so many transactions, our rudimentary, gets-the-job-done ledger was struggling. Finding past transactions for customers was an increasingly pain-staking task. The ledger didn't have search, no filters, no separate page to view payments to a specific person.

Since Groww Pay was also powering payments for Groww's investments side of things, it was getting quite messy. There were three separate pages (in three separate locations) to find: past UPI transactions, past bill payments & past Groww Balance top-ups.

This problem was only going to get worse for our more active users. Over 500K customers had already made 10 payments on the platform. As they started to adopt Groww Pay as their default UPI app, we also saw a huge demand for a better experience. A better “Transaction history” was one of the most asked for features in our NPS surveys and also whenever we talked to our customers.

Opportunities

From the problems we had identified and gotten feedback on, we already knew some essential features we wanted to build: search and powerful filters.

We identified a few more opportunities:

• Digestible, actionable spending analytics
• Payment category tagging
• Richer details: profile pictures, merchant icons, location data

To scope things a bit better, we decided to skip location data and start with very basic analytics which wouldn't delay our release.

Search & Powerful filters

Groww Pay is primarily a bill payment app. So after exploring a few ways I could lay the page out, I decided to keep only the Bills / UPI filter exposed. All other filters were one level deeper, things users would need on rare occasions.

Spending analytics

We had reason to believe users liked to keep track of their spending after seeing behaviour around payment notes. Over 100K transactions had notes attached, mentioning why they were making the payment. People who had a habit of adding notes did it consistently.

From personal experience, I wasn't very bullish on spending analytics. Spending analytics takes effort and consistency. You either need to have a very robust auto-tagging system or it falls apart. Having to manually tag every little transaction becomes a chore. Since university, I'd already tried multiple apps to find something that worked for me but hadn't found any which stuck.

I wanted to test whether users would find it useful or not before building a whole system around it. So we decided to do two simple things:

• Monthly net spend for users
• Payment tags: auto-tagging using MCC, editable by users

*Every transaction comes with an MCC code, indicating what it could've been for. For instance MCC 5812 is for restaurants and MCC 5661 is for shoe stores. Their accuracy wasn't certain but could be a good default/fallback.

Depending on response from users, we could decide later whether we wanted to continue building this. This helped us launch faster and solve bigger user problems first.

Hygiene improvements

As I mentioned earlier, history was built as an MVP. There was a lot of room to improve visually - like adding profile pictures and merchant icons. This immediately brought some life to the page and made things more scannable.

This was a really easy but important improvement. When you're ordering from Swiggy or making a payment via a gateway, you won't see proper merchant names. You'll see what their entity is called - which can be confusing. We manually fixed this for top merchants on Groww to give a more human experience.

Visuals

I noticed the way we handled completion states and the respective status icons was getting a bit confusing. Looking at it from a systems lens, I proposed newer status icons. Transaction history was a good place to test them out and see if we could propagate them everywhere in the app.

Across the app, we use the yellow semantic where some attention is required and user intervention is needed. In our context, the user can't do anything but wait. If transactions go into a processing state, it takes 2-3 minutes to resolve and go into one of the three: success, pending, failure. In any case, the user can't do anything. Because of this, I wanted to remove the yellow, warning semantic from the status icon and replace it with a neutral "processing" icon.

Another improvement was leveraging shapes to convey status. This could enable us to gradually use just the shape without the details in places where we were constrained by space and had to use a tiny icon.

Story of the Note

I also wanted to do something special with the success page and played around a lot with what we could do visually.

My personal design language draws a lot of inspiration from physical, recognisable objects which I translate into my work. Naturally, I looked at a lot of currency notes.

Improving discovery for anxious users

When it comes to their funds, users are naturally hyper anxious. Making a payment and it doesn't process immediately? Panic. Friend texts you they paid you for lunch? Look for a notification or check the app immediately. This is why transaction history is one of the highest WAU property in the tab at 23%.

Whenever payments don't process within 2mins, they are deemed 'pending' within NPCI systems and can take up to 2-3 days to resolve. In some scenarios, the user's been debited the amount but the funds haven't reached their friend. Is the money lost? When will they get it back? It's a situation of really high anxiety.

But, history shouldn't be solving this in the first place. We wanted to be more proactive in our communication around payments. This was a small win before we fixed bigger issues.