— CHUX Long Form Case Study —
I was a team designer for these projects. I took part in the research sessions that provided the insights we turned into UI enhancements. These features and changes took place in the summer of 2018.
Check out the before and after. Clicking the link above the images below will open a lightbox with the relevant version's mockups.
Then read the case studies for each project by choosing the relevant tab.
Cinch was founded in 2014 and closed its doors in 2018. I joined the team toward the end of its run. While I believe the concept had potential, there were several challenges—some significant, some minor—that ultimately hindered its success.
Cinch was building the world's first autonomous personal financial manager to optimize your entire financial life. Utilizing innovative technology, AI, and behavioral economics, Cinch operated as a fiduciary—no lead generation or embedded products, ensuring true unbiased advice for a subscription fee that fosters a genuine client-advisor relationship. Unlike other personal finance solutions, Cinch addresses both behavioral and product challenges in financial decision-making, covering everything from credit card debt to car insurance.
The hook was, “Think like a company and imagine Cinch as your always-on, entirely loyal CFO.”
The app had four different sections when I joined the team.
A snapshot of the user’s financial health, based on the idea that a user treats their financial life like a business.
A hub for budgeting with details on how the user is doing in that month. If the background was purple, they were doing well; yellow, they were in danger of going over budget; red, they were over budget.
Prioritized advice communicated through “moves”--pieces of advice on what to do to improve their financial situation. Moves could include changing or applying for credit cards, car insurance, phone plans, and checking and savings accounts that could save money or lower fees.
User financial information that plugs into the recommendation engines.
What do you get when you put a few product designers, a behavioral economist, a business analyst, and a user researcher in a room?
A headache.
Just kidding. Actually, you get a lot of insights.
For a full day, we held a remote research session with six real users on their experiences with Cinch. They were six men of different races and locations, aged 20-40, all with different jobs: an undergrad student, an engineer about to go to grad school, a physician assistant, a gig worker, a data scientist, and a business owner.
The work was split up and distributed appropriately among the different team tracks. I personally worked on improving the Spending dashboard and Bills, Auto Insurance, and Goals.
How might we improve the quality of transactions and the user’s ability to navigate it?
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.
This was the old transactions list without any interactivity.
We had loose feature requirements to implement a complete list of transactions and better interactivity.
I sketched out a lot of ideas. Here is proof.
I also went through a lot of exploration. Here is that proof.
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.
We worked closely with the UI engineers the entire process to ensure the logic and functionality of the interactions with the transactions list was smooth and made sense. The work spanned one sprint.
Scroll back up to the tabs to read the next case study about more enhancements
How might we provide users with a logical and enjoyable way to track their goals?
In Safety Net, we let the user add goals that could be used as accruals for a future bill or for an actual goal. The mechanism was simple: we divided the total amount of the goal by the number of months left until the goal’s due date. Then we added that amount to your Safety Net number each month.
Most personal finance apps use the "envelope" savings method, but we didn't. According to Cinch’s subject matter experts, the mental model around that type of money management was harmful. They believed that users should aim to have enough money in their accounts to cover everything without needing to earmark it. It was a contested theory.
There were multiple problems with the Safety Net.
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:
My main contribution to this project was the flow for the first scenario: achieving the goal. I sketched out 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. I quickly realized that getting to that congratulatory screen was the complicated part.
Users cannot effectively track their goals progress because there is no connection in the app between their transactions and their goals and no way to track when a goal is achieved or missed. This leads to abandonment of the app because savings goals are a critical aspect of personal finance management.
By creating a system that integrates user goals throughout the app and offers progress tracking, users will more effectively engage with the Safety Net/Savings section, reducing budget inaccuracies through goal-based transaction association.
Because Cinch did not believe in the enveloping method of saving money, the indication that the goal amount was reached was not clear. There were no special accounts where the money went. It was just an amount included in their Safety Net number.
Additionally, because Cinch’s value was in the proprietary AI that figured out recommendations and forecasted numbers, any irregular large transactions–such as the payment toward the goal–would throw the system. Kind of like when you let a friend use your music streaming account while in the passenger seat, your recommendation algorithm might be tainted for a while.
The user would have to go into their Pocket Money (budget), find the transaction, and ignore it completely. Not intuitive and didn’t paint an accurate picture of a user’s financial activity. We had tagging transactions with custom categories and goals on the roadmap. In the meantime, we had to include a workflow that associated transactions with completed goals in a smart way.
We also needed clear language for the different states of the goal.
That left me with four flows to design for:
The user is funded but has not completed the goal yet. Clicks "not yet."
The user is funded and made the purchase. The transactions were made from linked accounts, so they were already on the list. The amount spent on the goal was less than the saved amount. The user clicks "yes."
The user is funded and made the purchase. The transactions were made from linked accounts. The amount spent on the goal was more than the saved amount.
The transactions were made from unlinked accounts or with cash. The user clicks "yes" on the first screen.
Before Cinch closed, this project was in the last stages of design iteration before we would have handed it off to engineering.
Scroll back up to the tabs to read the next case study about more enhancements
How might we clean up the way we gather, store, and present user information so that our advice moves could handle more nuanced situations?
Cinch gave users comprehensive financial advice across major verticals of their lives. Each vertical had a “move”--flows with questions, bits of education, and action plans to improve. In the advice part of the app, the user clicked through different moves and decided whether or not to follow Cinch’s advice.
One of the verticals was auto insurance. We analyzed the user’s insurance plan and searched for cheaper ones to save them money. There was a basic flow for this with three main steps.
We uncovered some hiccups and edge cases that needed to be accounted for in each step of the flow.
To avoid user fatigue, we were careful to ask only required questions and in the right order. 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.
This was a problem with a solution in cleaner information architecture.
In the situation summary, we gave them our recommended action with an overview of the facts we considered for this advice. Sometimes, the user had the best deal, and we gave them the advice to stick with their current plan. Other times, we identified better options and presented them in the next step.
The original situation summary as its own page:
How might we tighten up the flow and give users more insight into our advice?
We encountered a classic case of too many steps. The situation summary and the following shop page could be combined to reduce clicks that were nothing but speed bumps slowing users from getting to the destination (car pun kind of): less expensive quotes for a new insurance plan.
Expanding on that decision, we combined the steps into one page because the “do nothing” advice on the situation summary didn’t add much value or give users context on why we gave that advice. The design for that page also looked like our designs for roadblocks (errors), signaling that there is something wrong to the user–which was not the case.
By merging the two pages and adding the quotes we found as evidence that they had the best deal, the page provided more value.
The new design for the two advice options:
Though we cleaned things up a lot by combining step 2: situation summary and step 3: provider page, the actual provider options still needed some tightening up.
When a user was eligible for quotes in our system, we showed them their options in cards. The old design inaccurately presented 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 old design:
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 would be able to scan the quote faster, too.
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.
The new design:
These changes spanned a couple sprints and were released to our users shortly before Cinch closed.
Scroll back up to the tabs to read the next case study about more enhancements
