goals image soft lite.png

Cinch - Goals

I worked as a full-time product designer for Cinch Financial. In this case study, I talk about a design that was in progress—a user funding a goal.

Cinch Financial

Changing user behavior and improving financial wellness through AI-driven comprehensive advice

I worked full-time on the product design team at Cinch Financial. 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 that case study.



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.

The participants:

  • We conducted the study with six men of different races and locations

  • Three of the participants had irregular income or were gig workers

  • Ages 20 - 40

  • One undergrad student, one engineer about to go to grad school, one physician assistant, one gig worker, one data scientist, and one business owner

Study goals:

  • 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.

Notes grid with six participants (real users) from the session


Directions we took after the research session:

  • Spending dashboard 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 the Spending dashboard, 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 Goals and the end of month review entry point in Snapshot.




calculating… counting down…

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 and then put aside that monthly amount into your Safety Net number. There was no way to tag transactions toward goals or track if you were funded or not. Users considered it a calculator. Additionally, we didn’t envelope money for goals and other purposes to break the mental model around that type of money management.

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.

Safety Net Page

Safety Net Page



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 user reached the date with the goal funded.

  • The user was not able to fund their goal by the deadline.

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.


Moving parts in the flow

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.

Goal funded user and system flow

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.


The use cases

#1: The user is funded, but has not completed the goal yet. Clicks NOT YET.

#2: The user is funded and made the purchase. The transactions are already on the list. The user spent less than their goal amount.

#3: The user is funded and made the purchase. The transactions are already on the list. The user spent more than their goal amount.

#4: The user is funded and made the purchase with unlinked cash.



End of month review entry point

Coming soon!