UX strategy case study of smartphone-based auto insurance

My role
User research, prototyping and UI design. Workshop facilitator.
Creation of a product concept to acquire seed investors.
header image
User's dashboard

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


  1. Workshops
  2. Exploratory Research
  3. Ideation
  4. Prototype
  5. Pitch to investors
Based in a Design Thinking approach

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.

All interviews were captured using a GoPro

What do we want to uncover

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

Sample of charts from the Context Inquiry report

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.


Context and behavior based 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.


UI Prototype

The main concept: Insurance pricing defined by driving behaviour
One way of make the initial data collection to get a quote easier would be just taking photos of documents

With these interfaces I tried to highlight:

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.


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.