UX strategy case study of smartphone-based auto insurance

Iza seguros is a service that uses the geolocation and smartphone sensors to measure driving behavior and gives discounts to insurance monthly.

Building an insurance company is hard because the requirements of the regulation can only be achieved with external investments and a mature company. In this project, I dived in the insurance routines, researched motivations, users context and investigated how people behave with smartphones while driving. In the end, I built the user interface of an app to be showcased to investors.

My role:

• UX Strategy
• Workshop facilitator
• User Research and Analysis
• Persona Creation
• Wireframes / UI and Prototyping

Process

Before starting the process we did a Assumptions and Questions workshop as team to have a reality check about the product, the expectations and the outcomes of the project.

As a result, we decided to do research to understand the user’s context and to answer some questions about the technology involved in the service.

The Research canvas was a great tool to frame the questions and plan the research in a objective way.

Exploratory Research

We need to better understand driver’s behavior and motivations regarding insurance companies, smartphones a driving monitoring and security practices.

The chosen methodology was a Contextual Inquiry. During this type of study, the researcher talks with the subject between 30 minutes and 1 hour. The goal is to analyze past attitudes, beliefs, desires, and experiences to understand the motivations, difficulties and predict how the user could use our product.

Then the researcher observes and hears the users in their standard environment. The goal is to collect data on behavior, triggers and step-by-step activities. Also, it is possible to observe limitations or problems to perform some task in the product.

What do we want to uncover

• Past relation with insurance companies and brokers
• Motivations to get new insurance (or not)
• How the smartphone was used while driving
• Common behaviors before and after any driving
• Data collection suspicion
• Limitations of the smartphones, cars and connected devices
• Limitations in the attention, perception, and cognition of the user while driving

The Sample

I interviewed and observed 16 participants while they drive through São Paulo city in familiar routes. All the participants live in the city, own the car, could afford insurance for the vehicle and have a smartphone equipped with, at least, GPS and an accelerometer sensor.

The sample was divided in people that:

1. Have insurance and a bluetooth radio
2. Only have insurance
3. Only have a bluetooth radio
4. Doesn’t have insurance or a bluetooth radio

Results Summary

All survey data and insights gattered in the research could be understood as part of any of these categories:

Past Behaviour

Users’s background, tickets, accidents, smartphone usage and Insurances usage, etc.

Mental models

Knowledge about insurance, how gps apps works, how bluetooth works, etc.

Day to day insights

Security behaviour, what is considered good driving, insurance brokers relationship, buying a new car, etc.

Key Insights

The users have some knowledge about insurance

We don’t need to over-explain the main concepts but a lot of people misunderstand insurance details.

The user opinion about insurances change over time.

People who have insurance now could discard it soon and people who haven’t insurance are planning to get one in the short or medium term.

Dynamic pricing could bring greater value to the product.

Everybody got excited about the possibility of getting discounts for good driving behavior.

Everybody is a good driver and should be rewarded.

We should be careful when addressing driving skills because almost everyone believes they’re driving safely.

The insurance could own the data to protect the user.

Initially, we had some concerns about the user sending data every time they drive to the company server. But in general, everyone feels protected imagining that the company knows their location.

Bluetooth technology constraint was validated

Almost all drivers with a Bluetooth radio connect the smartphone automatically before starting to drive. This is a key component for this business model.

Great customer support is the baseline of the market.

Everybody mentions competitors in a good way and remembered the last time they needed support. In this industry, good support is the minimum for any new competitor.

Personas

Based on the user research we set up five personas. I referred to them throughout the entire product development process.

The personas were developed to represent groups of people with similar contexts regarding mental model and concepts about insurance, vehicle care, expectations, and behaviors while driving.

Ideation and Definitions

To design a solution we decided to _focus on the acquisition process _. It is the simplest user flow mapped. A lot of competitors have difficulty improving their acquisition flow and investors are particularly interested in how we could delight the users from the beginning.

One complex side of our solution would be the subscription referral. Two personas had a history of a family member choosing the right insurance and we tried to include this characteristic in the process. The initial user flow for a new client was reviewed to accommodate use cases where the person who decides to hire is not the person who will pay for the insurance.

Besides, some user flows required a inexistent set rules at the time (like defining pricing, client acceptance, and auto assistance model) which would be only defined later.

Constraints:

• The prototype will be used for a pitch
• Should be in high fidelity
• Should focus on acquisition first
• We will design the app first

UI Prototype

With these interfaces I tried to highlight:

• The hire of new insurance could be easy, fast and trivial
• The price is transparent
• The car audit and document collection would be done via the app
• All the hiring would be done seamlessly. From the download to the policy emission. Without the need to talk to a human.

Note: Since we didn’t had much information about the platform (Android or iOS) at the time, I choosed not to use Material or Apple Human Interface Guidelines as reference for this interfece. Obviously the team will need to choose a path (or both) when the need to refine this interface arrive before the product launch.

Learnings

As I stated before, building an insurance company is hard. It takes time, investment a lot of work to get the service running correctly. That’s why a lot of insurance companies don’t put too much effort into building great experiences.

In this project, I just scratched the surface of all the possibilities in creating an attractive product and a big constraint was that this time, it should impress investors and not necessarily the end-user. With that in mind, I could only do small guerrilla usability testing with some screens at the end of the project. When the time comes to build actual prototyping with the pricing rules, the user’s test probably would bring even more insights into how people actually could use it.

But my main learning in this project was the power that prototyping could have when discussing ideas. We iterated a lot of ideas from paper scratches to coded interfaces. Discussing the ideas seeing and interacting with the product was important for the team agreement or revisit a lot of concepts of the product.