4 pillars foto.png

Cinch Financial

I worked for Cinch Financial as a full-time product designer. In this case study, I break down the different designs that were shipped or being built before Cinch suspended ops and closed development.


cinch financial

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

For a few months, I was lucky enough to work on the complex and so important problem of disrupting financial wellness through comprehensive advice with a smart, passionate, cross-functional team of designers, developers, QA engineers, data scientists, business analysts, and product managers. Cinch as a company did great work before suspending operations, and I would do it all again.




  • Sketch

  • InVision

  • Google Suite

  • Jira & Confluence

My Role

  • Full time product designer



A Bit of Background on Cinch

Personal, pocket CFO at your service

Cinch was your “CFO in your pocket,” giving advice that was comprehensive and smart, and most importantly, unbiased. We acted as a fiduciary, never nudging users toward products for kickbacks. We went beyond just budgeting or credit score monitoring, because we wanted to be a true one-stop shop, a complete financial intelligence platform, for users. Anything regarding a user’s personal finances could be found in a Cinch account—a little financial hub. We wanted to democratize financial sophistication and education to give everyone a chance to find financial freedom. Here’s a video giving an overview of the app.


Tracks on Tracks on Tracks

We organized ourselves into different tracks—cross-functional teams tackling a specific vertical or long-term project. I was part of three tracks: auto insurance, spending, and a track we called “Pyewacket” that worked on three projects, a new homepage, enhancing the Spending dashboard, and revamping the savings and Safety Net part of the app. My work with the auto and spending tracks were much more focused on implementation and incremental changes sprint-by-sprint. My work with Pyewacket was focused on bigger, more conceptual work that spanned sprints. You can see that here and here.

I’ve broken this page up by work I did by topic: Auto Insurance and Profile.



Auto Insurance

One of the “verticals” of our comprehensive advice was auto insurance. Each vertical had a “move”—flows with questions, bits of education, and action plans to better their situation. When users went to the advice part of the app, they clicked through the moves and decided whether or not they would follow our advice. For auto, we took a look at users’ insurance plans and looked for cheaper ones to save them money. There was a basic flow, three main steps. In a few sprints, I redesigned aspects in each part of the flow.


Questions in the exact right order

We were careful to ask the questions for the auto insurance flow in the right order. We didn’t want to fatigue our users, and we didn’t want to ask them questions they didn’t need to answer. I came in after the flow was put together by my design lead. As business requirements and the system changed, we worked on revising that flow for a few sprints after, collaborating with the developers each step of the way.

Original flow for auto insurance move supporting multi-car and multi-driver policies


  • The way we presented the user’s information in their about me section changed (see later on in case study), so two of the screens with the driver and car details were no longer needed.

  • We needed a way to be able not only to add a driver, but also add a person at the same time. We had different sections of information, and two of them were household and car insurance. Under household, we stored all the information of the people in the user’s household. Under car insurance, we stored the information for the insurance policy, the drivers, and the cars. We matched the information on drivers in car insurance with the information from people in household. If a user needed to add a driver to a policy that was not already added to the household, the flow wouldn’t allow it.

  • There were certain situations our system didn’t support. For example, if a user didn’t have a policy, we didn’t support shopping for a brand new one—only comparing against current coverage and looking for savings. That meant a user could’ve gone through our entire flow and gotten to the end, only to have hit a page that told them we couldn’t help. That was a waste of user’s time.



  • Adding a driver at the same time as a person was tricky, but we worked with the developers to find a solution that worked. We played around with navigating the user off screen to a new list of questions to create a person first. After finishing, they would be dropped back into the original flow. That was difficult and messy in the back end, as well as a lot of unnecessary movement for the user. We decided that when a user clicked “add a person,” the additional questions needed to add a person before adding a driver showed up first in the list. By answering the questions, the user was able to add both the driver and the person simultaneously.

  • In order to save time for the user, we rearranged the order of the questions. Instead of driver > car > policy, we arranged it policy > driver > car. That way, if a users circumstance was unsupported, they wouldn’t have to answer unnecessary questions.

  • These changes were being shipped.

New flow—was in process of being shipped


quote cards on provider page


The Problems:

  • When a user was eligible for quotes in our system, we showed them their options in cards. The old design was inaccurately presenting quotes for monthly and pay in full premiums. The monthly premium figure was not showing the user that they pay a down payment in the first month that is higher than their premium when they choose to pay month-to-month. So, the pay in full estimates we gave for a monthly comparison were higher, even though it is always less expensive to pay in full upfront.

  • Additionally, a problem was that we were trying to compare apples to apple sauce, because the two numbers—monthly payments and upfront payment—were different outcomes of the same situation. One was a lump sum, and the other was an installment. Trying to convert one figure into the other just wasn’t a great approach or a clear representation of the situation.



The Solution:

  • Instead of trying to make comparisons in the same metric, I presented the costs of each payment method side by side in the way that the user would make the payment (i.e., cost per month with the cost of the down payment vs. the total cost of the upfront payment). That way the user would choose whether they wanted apples or apple sauce without confusion. They also would be able to scan the quote faster.

  • I also got rid of bullets and put the final two pieces of information—expiration date and term length—at the end in a sentence for a cleaner presentation.



Do we even need the situation summary on its own?


Problem: It was causing an extra click for no reason on some of the moves, mainly auto. The information we were giving on that page just served as a speed bump, slowing users down from getting to their destination: less expensive quotes on car insurance plans. That’s always a problem.

Solution: To trim unnecessary parts of the page, and to prevent anything from getting in the way of the user and the intended goal—finding car insurance—I merged the strategy page and the provider page, cutting out the “Cinch Says” and the “Just the Facts.”


Let’s do it with all situations, then!

Problem: the page for “keep your insurance” wasn’t adding much value, nor was it giving the user enough information about their current situation. Even though we recommended they stick with their current plan,  we weren’t giving them any evidence that we searched or what the market looked like.

Additionally, the page itself was the same layout as our roadblock pages, communicating to the user that something is wrong—which is not the case.


Solution: I merged the strategy page and provider page to give the user the recommendation to keep their insurance, but also, provide them with quotes so they can be fully informed. This way, the user has a full picture of the situation and also doesn’t feel like they hit a roadblock or system error.





Where to put the auto insurance information we collect?


Problem: The About Me section in Profile isn’t organized in any way. All the questions the user answers and can edit are listed on the same screen. At first, users could only add their auto insurance information if they were a single driver with a single car on their policy. We were in the process of making our system allow multi-car and multi-driver (MCMD) policies. With MCMD, this About Me setup was no longer possible. Having information for multiple drivers with multiple cars all under one screen without separation would’ve been messy and confusing, and difficult for the user to make sense of and access.



Solution: Separating auto and personal information out is the first step to a more organized About Me section. Eventually, this will have to be organized in a better way so that accordions are not used. We had multiple verticals that users provided information they would need to access from their profile, and accordions just wasn’t scalable. This was a temporary solution.



People can change, you know



Problem: We ask the user if they are a revolver (carries credit card balance month over month) or transactor (pays credit card balance monthly) when we collect their account and credit information. After that, the user has no way to edit that credit card usage information after they answer for the first time. We ask them if they pay their credit card off every month—“yes” for transactor; “no” for revolver with an additional question on APR—but don’t have a way for them to update. If a user’s status changes, and they cannot tell Cinch, we will be giving them inappropriate or inaccurate advice.

Screenshot 2018-09-29 10.32.06.png

Solution: I put the information under the account details. Clicking the cell will give the user the ability to edit their original answer by directing them to the question. If the user is a transactor, they only have one question—“do you pay this card off each month?” under the account. If they are a revolver, they will have two questions, the additional bit of information being their APR.