Cinch Financial
↖︎ back to the project
2018: started mid-July, launched mid-August
.png)
In the Safety Net part of Spending, we let the user add goals that could be used as accruals for a future bill or for an actual goal. It was pretty simple. The only things we took into account were the total amount and the due date. We’d divide the total by the number of months, then put aside that amount into your Safety Net number each month. Most personal finance apps use the "envelope" savings method, but we didn't. According to our subject matter experts, e didn’t envelope money for goals and other purposes to break the mental model around that type of money management.
There was no way to tag transactions toward goals or track if you were funded or not. Users considered it a calculator.
The design team was doing a big redesign of the entire Safety Net section—starting with its name. We started calling it “Savings.” Users didn’t seem to understand Safety Net as well as they could’ve, and it just didn’t resonate with them.
The design team worked with our business analysts in coming up with new ideas and policies around where we told users to allocate money for their savings, how we set up the funding process for goals, and how we could get credit card debt out of Safety Net’s monthly contributions and into other parts of the Spending section of the application. My task in this redesign was to think about what happens once the user reaches the due date finish line and is funded for their goal.
When the user reached the date, nothing happened. We didn’t track the goal, nor did we tell them good job/try again. It was just kind of… there. There were two situations to consider:
The second situation had to be thought out and dealt with on a larger scale. We did not want our users failing, and that kind of prevention meant tracking goals from the minute they are made, giving updates throughout the journey, and warnings/advice when they were at risk or failing. If we only interacted with a user about the goal when it already failed, then we failed.
So I started to think about users being successful in their goals and what that meant for them, for their finances, and for our system. I started out sketching the “feel good” congratulatory screen the user would see once they reached their goal date and were funded.
It might seem simple what needs to happen—congratulate the user. That was only a small part of it. When a goal was funded, that meant the user had been putting aside the amount we told them monthly for them to make that purchase safely.
It also meant that a large transaction would be coming through our system. In order for the user’s Pocket Money number to be accurate, that transaction needed to be ignored from Pocket Money with the reason being they used their savings for the purchase. That wasn’t a very intuitive way to handle accomplishing goals in Pocket Money, so, at the same time I was working on this, other tracks were working on creating an option to associate transactions with goals in the transaction detail pages on the Spending dashboard.
The last aspect of this was if the user actually made the purchase. The user could have been funded, but not gone and made the purchase yet. The trigger for this feature would have been the first of the month the goal was due and the user had enough money in their reserves.
Currently, the goals section contains monthly contributions to future expenses, which includes things like non-monthly bills. This was confusing to users. First of all, people didn’t understand what a “monthly contribution” meant. Second of all, contribution carries a connotation of being voluntary, and people think of bills as bills, regardless of their frequency. People don’t think of them as goals. People’s mental model around goals is that they are things to aspire to and work toward, not things they have to pay. Things they have to pay are bills. And round and round we go among bills, goals, mandatory payments, saving up vs. paying down, recurrence, etc.
So, we decided to start to create a clearer separation between bills and Savings. That included putting all bills and credit card payments together and savings and goals together. The following use cases are in consideration of this change.
Each project and feature I worked on either stemmed from or was influenced by from that user research session. I've broken each out into its own page to for readability.
