The challenge

We experienced low conversion rates during the process in which users would get a home insurance quote through the bank's app. The challenge was to increase user engagement, and therefore, increase conversion rates, and as a bonus, tailor the product according to our users' needs.

Context

My team was in charge of overseeing all the insurance products the bank had to offer. The most important product available was their home insurance, MyBox Hogar (MBH), which was the best selling product at that moment. However, this product was not performing as expected, and we were tasked with improving user engagement and user experience. As a team, we also took the opportunity to take a deep dive into the product and learn about our users, so that we could give them a product that would speak to their specific needs.

Getting a quote

Users could purchase one of our insurances by going on the bank’s app and browsing in the insurance section. Once they have found an insurance, users go through a simulation process, where they answer a few questions and get a price. Immediately after this, if users agree on the price, they go through the process of actually buying that insurance.

Low conversion rates

Our CRO, our data specialist, analysed the app simulation to buy MBH and realised that we were experiencing low conversion rates at specific moments during the simulation. He identified which parts of the flow were underperforming, and this gave us a tangible starting point.

There were three main moments with low conversion rates:
1. The first screen of the process, where users would get to know MBH benefits.
2. The screen where users were asked about the size (square meters) of the house to be insured.
3. The screen where users were asked about their postal code.

In the meantime, I was tasked with conducting a competitive analysis of the identified screens to see how our competitors were handling them.

Out of these three, the postal code screen was for us the most enigmatic. What we knew about this particular screen was that the conversion rates were significantly low, around 6-7%. We already knew that given the industry and the broad target audience (users using the app ranged from house owners, landlords, and tenants), conversion rates can be low, but we wanted to understand why out of the three, this was the screen that had the lowest conversion rates.

With the analysis I conducted, other competitors treated the postal code the same way we did: We simply asked this piece of information. There were some variations, such as whether we used a text field, a drop down or an autofill; however, there was nothing significantly different, and we wanted to know what the issue really was.

Action plan

My team was our CRO, and the product owner. So together we created a strategy to tackle each screen. For this, we discussed the possible causes for the low conversion rates on each screen.

Our hypothesis for each screen were:
1. People were not sure about starting a quote, or the product's benefits didn't resonate with them.
2. People don't know exactly how big their property was, or had to reach documents to find this data, which could have led to getting an expired session (the cause of the "leaving the app").
3. People didn't know how to continue with the process because of usability issues. There is also the possibility they didn't know their postal code, but we thought this was very unlikely (and we later on found out and confirmed this when interviewing users).

So, based on these hypothesis we decided that the most effective way to find insights that would lead us to solutions was user interviews. It would help us understand what people are looking for in a home insurance and it would also give us clues to why some of these screens were underperforming.

At the same time, I also prepared a workshop for the team to get everyone aligned with our objectives, and also get feedback from them in terms of technical and legal constraints that I had to take into account when designing possible solutions.

Technical and legal constrains

The bank had its own design system that worked for two different technologies. Our simulation process had been implemented on one of the older technologies, meaning that we could not make structural changes to the screens, leaving us with only being able to apply changes with CMS.
‍
Additionally, there were some legal aspects that limited how we asked our users for information in order to give them a quote. Particularly, the information regarding square meters had specific parameters which required the data to be exact and unambiguous.

Interviews

We talked to the research department to collaborate with us in conducting interviews based on data available from traffic about our users. Our objective was to be able to identify behavioural patterns about our users and discover why these users would leave in specific moments during the flow (as the data previously showed).

The interview was broken down in two groups: 6 users that had used the app and successfully purchased a home insurance, and 11 users that had used the app, but had left during the process. As a product designer, I participated in these interviews, both as a interviewer and note taker.

What we learnt about the interviews

After the interviews, we could identify the following behavioural patterns (starting from green, going clockwise):
‍
1. Trusting: This profile feels like they are paying an accurate fee for their insurance because they trust the bank’s credibility and reputation.

2. Demanding: This profile feels like they are paying an excessive fee for an insurance they rarely use, so they expect a fast service that is also stress-free.

3. Responsible: This profile feels like they are paying an accurate fee for a basic insurance that covers damages to others and water leaks.

4. Hunter: This profile feels like they are paying an excessive fee for their insurance, so they are always on the lookout for a cheaper option.

These patterns were incredibly helpful in understanding our users' motivations and pains, what they look for in an insurance, and it gave us an insight on how to make our product more appealing.

Some insights about each of our screens

Besides identifying behavioural patterns, we also learnt some extremely helpful insights about our app and the screens that had low conversion rates. We asked our users whether these presented any issues or if given the chance would make them hesitate or doubt the information we were asking on the app.

1. Benefits:
People leave the simulation because they’d rather talk to their agent to answer their questions and learn more about the insurance coverage.

2. Square meters:
Users know this or have it in hand, but they don’t feel confident in the price of the insurance if they write an approximation.

3. Postal code:
Users seem to know this, but they leave out of distrust and prefer going to an office.

Sketching out solutions

For this part of the design process, I had to take everything we had gathered at that moment: Data we had collected, insights from our user interviews, and also the technical and legal constrains that narrowed my scope of work significantly. Nevertheless, this made it possible to have longer discussions about the possible solutions.

In the end, the changes that we could apply included changes in copy, adjustments on the placement of the design system components, and adding extra small features to either make information clearer or make the process more intuitive and easier to use.

Wireframes benefits and square meters

3. Postal code:
Users seem to know this, but they leave out of distrust and prefer going to an office.

Wireframes postal code

The solution

Having these insights to guide my design decisions, and some back and forth with the Product Owner and CRO, I could prepare a design proposal.

1. Benefits
‍
I decided to modify the text to better align with the needs and preferences of our users, making MBH more appealing. Additionally, since users feel more comfortable with their agents, I changed the approach to emphasise that we are with them throughout the process.

Final thoughts

This was a long project. Between the start of the project and the end of the interviews, six months had pasted. The interview process was the most interesting aspect of this project, but it was the part that took the longest due to unexpected obstacles regarding other teams and different work flows among other departments. Dependencies were definitely the cause of these obstacles, but it helped us strengthen our bond to other teams and it made it smoother to work with them in other projects.

The changes that we applied did have a significant impact on user engagement and conversion rates, which overall set the project off to a great start.