Product Design
PRODUCT DESIGN
Helping Jar users save better through their spends analysis
My Role
Product + Design Strategy
UX/UI Design
Prototyping
User Research
Timeline
3 Weeks
Nov-Dec 2023
Team
1 Product Designer
1 Product Manager
2 Developers
What is Jar 🪙
Jar is a micro-savings app Indian fintech start up in India solving for financial fitness in Tier 2 & Tier 3 cities. It aims to educate and create financially fitter Indians by encouraging them to save everyday in the form of digital gold. Jar has other diversified offerings such as instant cash, SIPs (weekly/monthly), peer-to-peer (and micro) lending, health insurance (now defunct), physical gold coins, jewellery, etc.
What is Spends Tracker 💸
Spends Tracker aimed to solve for better financial management for our users by giving context of their spending frequencies, habits and patterns.
Spends Tracker V1 went live in March 2023 and V2 rolled out in January this year.
What Spends Tracker V1 looked like
Current Gaps and Challenges
It clubbed multiple account expenditures under one umbrella
No category identification, at a micro level - so we knew WHAT the users were spending, but not HOW they were spending
Disjointed, static, single narrative for all users regardless of their user journey or requirement
No data sanity - kept quantifying investments as spends
CTR on the cross-selling card was 1.2% only.
Lack of engagement - zero queries raised on CX for Spends Tracker - implying low discoverability as well
Business goals
We wanted to improve the older version solved for basic problems, such as Spends/Balance, spending pattern, a simple cross-selling card, and the list of transactions on a single landing page. As with any redesign, this was fueled by two major objectives.
1.Introduce Multiple Accounts
We wanted to introduce more functionality to Spends Tracker by including the option to see your spends segregated by accounts.
2.Create Data Sanity
On several levels, we wanted to solve for Data Sanity, like the possible of introducing transaction categories and to differentiate spends from investments
Who we were designing for
Jar’s users are diverse, but I specifically considered a cohort for Spends Tracker defined by the following characteristics
Are relatively digitally literate but not tech savvy but most use Android devices
Are used to localised languages in tech and are familiar with apps like Youtube, Google Search, etc
Are strict with expenses and might have very little room to save extra
Might not be financial literate or seasoned investors/savers
Save money in mostly physical, tangible format (currency notes)
What do our users look like
Ramesh is a shopkeeper in Bangalore who mostly uses all his apps in Kannada. He earns around ₹25,000 - ₹ 35,000 a month. He has little room for other expenses, but wants to save as he knows that is a good financial decision to make.
He uses Jar app to save ₹20 everyday. However, during month end, on some bad months, realises that he is short on money and either has to stop his daily savings streak on the app, or has to withdraw cash to compensate.
Ramesh, a Jar user. Stock photograph
Ramesh discovering what Spends Tracker is
How our average users spend their money
Without empathising with the user’s spending habits, any solution will be partial. Let’s break down our understanding here.The basis of this understanding was realising that we have roughly the following types of spends :
Recurring - EMIs, Credit Cards
Fixed - Investments, SIPs, Rent
Everyday - Groceries, transport, entertainment, etc
Sudden/Un-anticipated - Big purchases, medical bills, etc
Snippet from an actual brainstorm session in office
How spends information could provide utility for our users on a micro level
Establishing this relation helped us focus on the utility of money as well. A lot of back and forth of ideas was done using actual user scenarios and/or use cases that were shared with us through our company-wide daily Jar user-verse blurbs consolidated by our user experience research team.
We were also able to empathise about how we spend money by using our own experiences and emotions regarding money. For example, how multiple accounts are used and relegated to different types of spending, how joint accounts could work, how we can divide the lump of category information into smaller, better buckets, etc.
The diagram on the left helped us develop the user narrative of the landing page monumentally. Because V1 was so limited in its offerings, it was almost like we had to recreate value and rebuild it from the scratch.
Jobs To Be Done Framerwork
Once I defined by cohort and broke down the problem, I used the Jobs To Be Done Framework to build a narrative basis the insights from the user data + research team
Design objectives for this project
A helpful, more intuitive way for Jar users to consume spends information and developing a positive relationship with savings as a behavioral motivation and business goal
Some user insights from our research team
A helpful, more intuitive way for Jar users to consume spends information and developing a positive relationship with savings as a behavioral motivation and business goal
How might we questions along the way
We then brainstormed, about how apart from providing information to the users about their spends, additional value could be created so that they visit this flow again and again. We focused on creating incentivisation so that our users can see merit in saving with us.
Mitigate the confusion around balance information as we're more focused on spends on this screen
Incorporate gamification to incentivise revisits on this page more, i.e. setting limits
Improve categorisation by utilising metadata from combing thousands of texts
Add deeper personalisation by adding contextual cross-selling cards for a higher CTR
Create a better transaction experience by adding functionality related to information location
Add elements of delight such as "save in gold" nudge as per, pop-ups nearing pay-days, etc.
Creating a user journey like the one below helped me identify any edge or left-out cases, prioritise information and flag any additional logic requirements from the product manager for the project. It also helped me take all the cases in a step-by-step manner.
Iterative process before finalising a product direction
We did many, many iterations before finally coming up with a version of Spends Tracker that would suit our user needs and business goals the best. This included taking important calls - do we need to show multiple accounts upfront? Do we prioritise graph first or categories first? How would the future scope look like from this point?
What the final results looked like
The landing page revamp
The first focus is now on Spends, and the multiple bank icons.
You (the user), who has not set a spends limit, will get information about their daily average spends across a week. This acts as a nudge to set the limits.
The consecutive element is setting the limit itself, followed by categories. This is then followed by a graph showing the spends across 3 months, and then a separate page where all transactions can be seen. The last element is a cross-selling card encouraging the users to set up Daily Savings.
Prototype of the Spends Tracker V2 landing page
Gamification via setting spends limit
Once the user has set a limit, the spends widget shows up which looks like a progress bar. We have three zones in spends - green, purple, yellow, and red zones. Zones amount to spends in the following way :
Green - 0% to 35%
Purple - 35% to 65%
Yellow - 65 % to 85%
Red - 85% and above
If you’ve reached the red zone, you are provided with a one-time haptic every time you come to this screen - the spends card shakes/vibrates to denote a sense of alert.
If you’ve crossed the limit but the month has not ended or you’ve not increased your limit, you will be notified the amount with which your spends has exceeded.
Once the month ends and you’ve stayed within the limit, you will get the nudge to buy gold manually. This nudge only remains for 24 hours at the month end and then disappears.
All 5 states of the spends limit widget
Transaction tab in action
An advanced transaction tab
A big difference from the V1 is adding a separate transactions record screen in V2. While an important part of the information you can peruse, it was an exercise in prioritising UI real estate and would also work to incorporate filters better. We used data to check allot an accurate serial positioning to the filters. The order was - Banks, Categories, Amount, and Month. The applied filter categories would show only the number of filters applied via checkboxes and not the names. The filters were divided into :
Categories reflected the same categories shown on the landing page
Months currently only catered to 3 months, however, post design handover, we also kept the idea open of increasing this time frame in the future.
Banks included all the banks deciphered through transaction texts - however we distinguished them using account/card details on the right side
Only amount filter had radio buttons, rest had checkboxes.
All the different categories, consolidated
Contextual cross-selling cards + categorisation buckets
Action state of the Pay-day nudge which adds a sense of delight
Contextual cross-selling cards based on previous transactions
Full expanded state of the categories on landing page
© Soumya Raj 2024