Cinch Financial
↖︎ back to the project
Each took 1 sprint in August 2018
.png)
The Cinch team on the tech side organized ourselves into different "tracks", which were cross-functional teams tackling a specific "vertical." We called the different parts of the product "verticals." I was part of three tracks: auto insurance, spending, and a track we called “Pyewacket.” Pyewacket 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.
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.
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. 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.
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.
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. 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.
No.
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.
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.”
After seeing that this was more efficient, we decided to do this with all scenarios, see next tab.
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.
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.
After our track started work on auto, we caught a few issues with the way we collect ands store user info.
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.
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.
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.
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.
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.
