Three mobile version screenshots side by side of different states of financial health: purple is healthy, yellow is warning, and red is unhealthy
Auto Insurance

Features Summary

Duration

Each took 1 sprint in August 2018

process

discover
define
develop
deliver

Level of Work

Auto Insurance

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.

Information Architecture: user flows for the auto insurance move

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

Problems

  • 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.
a move for car insurance

Solutions

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

Information Architecture: user flows for the auto insurance move

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

Problems

  • 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.
a move for car insurance

Solutions

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

Quote cards on the 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.
before

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


Do we even need the situation summary on its own?

No.

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

After seeing that this was more efficient, we decided to do this with all scenarios, see next tab.

Cleaning up inefficiencies

before

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.

after

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.

User Profile

After our track started work on auto, we caught a few issues with the way we collect ands store user info.

Where to put the auto insurance information we collect?

before

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.

after

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?

before

The Problems

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.

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

after


Individual Projects and Features

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.