Back to home

Prefill: designing around sensitive data

Gabi's biggest drop-off point was the manual flow for entering auto policy details. It was slow, and most people did not have their VIN or carrier details ready. Competitors had a feature that filled in most of this information from a phone number, and Gabi had just got access to the same technology. On paper, it looked like an easy win.

TL;DR

The magic broke trust. So I redesigned the moment.

Prefill could autofill insurance data from a phone number, but it was often wrong, and people distrusted a product that revealed their personal details as "magic." So I designed it to assume it would sometimes be wrong: a step-by-step flow starting with the least sensitive data, a question instead of a claim ("Are these your cars?"), and pre-selection limited to confident matches, so no one had to correct false positives about themselves. Profile-verified-to-sold rose 25% against a 10% target.

TL;DR

The magic broke trust. So I redesigned the moment.

Prefill could autofill insurance data from a phone number, but it was often wrong, and people distrusted a product that revealed their personal details as "magic." So I designed it to assume it would sometimes be wrong: a step-by-step flow starting with the least sensitive data, a question instead of a claim ("Are these your cars?"), and pre-selection limited to confident matches, so no one had to correct false positives about themselves. Profile-verified-to-sold rose 25% against a 10% target.

TL;DR

The magic broke trust. So I redesigned the moment.

Prefill could autofill insurance data from a phone number, but it was often wrong, and people distrusted a product that revealed their personal details as "magic." So I designed it to assume it would sometimes be wrong: a step-by-step flow starting with the least sensitive data, a question instead of a claim ("Are these your cars?"), and pre-selection limited to confident matches, so no one had to correct false positives about themselves. Profile-verified-to-sold rose 25% against a 10% target.

Problem

Data was often wrong, and people distrusted a product that revealed their personal details as "magic."

In competitor testing, almost every user reacted negatively when they saw their data prefilled without explanation. Instead of feeling helpful, it made them stop and question how the product knew so much about them. What we expected to feel effortless created discomfort and eroded trust.

Process

I designed for data I knew would sometimes be wrong.

Start gentle.

Split the flow into steps, beginning with the least sensitive data: vehicles.

Ask, don't claim.

"Are these your cars?" instead of "We found your policy."

Pre-select only confident matches.

So no one hast to correct wrong data about themselves.

Solution

A prefill that assumes it can be wrong, and keeps the user in control.

The key interaction decision was how to handle selection when some prefilled results would inevitably be false positives. I considered three approaches:

Pre-select everything

and make users remove wrong matches.

Pre-select nothing

and leave all the work to the user.

Pre-select only confident matches

and leave uncertain results untouched.

I chose the third approach. It turned prefill into a lightweight filtering step: users could confirm the obvious matches, ignore false positives, and stay in control without having to clean up the system’s mistakes.

Impact

+25% profile-verified-to-sold, against a 10% target.

Beyond conversion, Prefill improved quote accuracy by surfacing details drivers often forgot to mention, bringing initial estimates closer to final carrier prices. Once the flow reached full adoption, we also reused it as a fallback for “Link Account” failures, turning a dead end into a recovery path.

Looking for a Senior Product Designer?

Looking for a Senior Product Designer?

Let's talk

Kraków · Poland · UTC+2 · Open to remote

Kraków · Poland · UTC+2 · Open to remote

15:20:44