Cinch - Spending
I worked as a full-time product designer for Cinch Financial. In this case study, I talk about a design that was in progress and being built—improvements to the spending dashboard and bills page—at the time Cinch suspended ops and closed development.
Changing user behavior and improving financial wellness through AI-driven comprehensive advice
I worked full-time on the product design team at Cinch Financial. As I mentioned in my other case study, Cinch closed development and suspended operations. In this case study, I go over some bigger projects that we were working on but didn’t get implemented. If you are interested in some of the work I did that was implemented, head over to the other case study.
*If you already read the background from the other case study, then skip to Spending Dashboard stuff.
Background and the research behind this
About Cinch and the product
Cinch aimed to provide a personal advisor/pocket CFO, giving unbiased, comprehensive, and automated financial advice to everyone. There, we tackled the beast of personal finance with behavioral economics principles and data-driven solutions. The design team balanced being focused on thinking big and conceptually into the future and implementation sprint-to-sprint to ensure we stayed on track on our roadmap.
There were three main parts of the app that users could navigate to: Advice, Spending, and Snapshot.
Users went to Advice for guidance. We’d take the information they provided via self-answered questions, linked accounts, and credit score and give them advice on areas of their finances like credit card debt, auto insurance, student debt, life insurance, checking fees, savings, and their payment methods.
Spending was where users could monitor their spending and the budget we automated for them. They could see their Pocket Money (how much money they had to spend), their Safety Net (money they should be putting aside for the “uh oh” moments, savings, credit card pay downs, and goals), bills, income, and transactions.
Snapshot was the high level look at the user’s accounts and assessments over the past 90 days—debt (debt and credit), reserves (available cash), consumption (money in/out flows), and protection (life insurance coverage).
the day we learned some things and validated others
What do you get when you put a few product designers, a behavioral economist, a business analyst, and a user researcher in a room? Lightbulbs (is that the joke?)
For a full day, we held a remote research session with six real users on their experiences with Cinch. Two of our participants couldn’t make it.
We conducted the study with six men of different races and locations
Three of the participants had irregular income
Ages 20 - 40
One student, one engineer about to go to grad school, one physician assistant, one gig worker, one data scientist, and one business owner
Illuminate areas of confusion around features, specifically in Spending, such as Pocket Money, Safety Net and monthly contributions, and Goals
Find pain points and see how users were interacting with different parts of the app
The following image is the notes grid I created to combine all the observations and see them side by side. The last column is the takeaway from the topic of its intersecting row.
Resulting directions and key takeaways:
Spending needed to be improved to become more of a configurator where users could adjust the information as needed. At the moment, we gave users limited interaction with the components of spending, and it was causing some inaccuracies.
Credit card debt and repayment of it shouldn’t be in Safety Net/Savings, it should be in bills. Users’ mental model around credit card payments was not money being put aside, but rather, active and recurring payments each month.
Safety Net as the section name was not quite working. Like Spending, it needed a revamp and improvement, as well as the capability for editing and more user interaction/input.
Goals was an area for untapped potential. Users were not using it, but would if it had more value.
Snapshot held great value as a centralized hub, and that overall, comprehensive look at financial health was important to users. In addition, the end of month review was incredibly useful. The only thing that was lacking was more insight into what that snapshot meant—trends, analysis, behaviors, etc.
The work was split up and distributed appropriately among the different tracks. I personally worked on improving the Spending dashboard and bills, incorporating the end of month review in Snapshot, and fleshing out Goals.
In this case study, I cover my contribution in Spending.
Potential was the word a couple of our users used to describe the Spending dashboard. The building blocks were there, we just needed to add to it. From our research, we found a few problem areas and potential solutions for them.
Users felt that the transactions list didn’t give them the whole picture.
Users didn’t understand why they had to click around to see all the types of transactions (in flows, bills, pocket money, credit card payments, etc.), and it was requiring them to do extra thinking.
It was hard to interact with the transaction list in a way that was meaningful, as it was just a sortable list of Pocket Money transactions from the last month.
Users had trouble getting accurate numbers because they couldn’t edit or add bills manually. They could only categorize a transaction from a linked account as a bill.
Turn the Pocket Money transactions list on the Spending dashboard into a complete list of transactions.
Add search and filter by account functionalities in order to interact with transactions in meaningful ways. Users could already sort transactions, but they couldn’t do much else.
Transform the bills section into a configurator for accuracy. Users were limited by only being able to recategorize a Pocket Money transaction as a bill. Giving users the ability to interact with the bills section and add offline bills would fix some issues with accuracy.
A comprehensive and meaningful transaction list—what more could you want?
More inflows than outflows, but I digress. There were small changes we needed to make on the design side.
A way to differentiate in the number which is money in and which is money out. We didn’t want to represent it in color because annotations were already different colors, so we chose to add a + to the inflows.
Annotations to draw distinctions among the different types of transactions in the list. (Most) Users already knew Spending dashboard to be where the Pocket Money transactions are, so we wouldn’t have annotations on those. We would add annotations to inflows and bills. Those annotations would be differentiated by color.
A sum of the transactions upon user interaction through search, sort, or filter. Because the list no longer was just outflows, we had to show both figures—the sum of money in and the sum of money out.
We knew we wanted to add filtering and searching, but what did that mean for implementation?
For search, results were based on the description in the transaction cell itself. Users would type the whole word and hit “enter” before any results would come up. We didn’t want the transaction list to constantly be flickering with results each letter typed. Most of our users were on mobile, so we only had so much screen real estate to use for these functions. I played around with trying to fit it all on one bar, only using icons, hiding until point of need, and other ideas. I made a pros and cons list for the different options.
For filtering, we went back and forth between being able to filter by multiple categories at a time. I included account (by card) and by transaction type (Pocket Money, income, bills). I mocked up examples of both, and we ultimately decided that for this release, we would only have one filter type to start—filter by account. If users wanted to see the specific transactions, they could navigate to the bills and income sections of Spending.
It was also tricky to find a representation of what is filtered and the number of filters applied. I had to make sure that we could filter by more than one account at a time, and that the accounts in the drop down were legible and distinguishable.
Sorting stayed the same.
A better way to understand your transactions
After a few iterations and design reviews with the team, we came up with a solution that worked.
For a comprehensive transaction list, we included all transactions—in and out—with colored annotations to distinguish them. Blue was income, purple was bills, and no annotation was Pocket Money. If a transaction was ignored, we changed the opacity of the text and numbers in the cell to 60%. The transaction totals would contain a + if they were inflows.
For the search, sort, and filter functionalities, we decided to do two bars—one with search and one with sort and filter—above the transactions. When the user interacted in any way (other than sort) with the transactions, the sum of the transactions appeared. We designed it this way to reduce the mental accounting on the user. If a user is interacting with the transactions list, they are actively looking for something or trying to figure something out that combined the different transaction types. That’s when a sum would come in useful. Otherwise, we kept the Spending dashboard as simple as possible to reduce the cognitive load by giving them one number—their “safe to spend” Pocket Money number.
Additionally, We opted to only sum up the amount of money in/out, and didn’t sum up the number of transactions, as it didn’t come up with users during research. The user could filter by account, and the type of account (credit card, deposit, savings, etc.) and last four digits would be listed under the name for easy recognition. We worked closely with the UI engineers to ensure that the interactions with these functionalities would make sense and be what the user expected.