Finding Friction in a Long-Requested Feature

Why research mattered

Policy Connection is a third-party account connection feature. It finds a user's existing insurance policy and brings it into Experian's insurance flow, so they can compare new quotes against what they have now.

Users had asked for this for four years, nearly as long as Experian had offered an auto insurance product. It came up in every study I ran on the product. Importing a policy was an easier way to keep coverage the same, so users could compare prices without worrying that a cheaper price meant weaker coverage.

The feature had finally gone live, and my product manager's funnel data showed roughly 30% drop-off. We both expected trouble at the connection step. The question was how it felt to connect a real policy, and where it broke.

Research approach

I ran two moderated usability studies, five users each.

• Prototype test (October 2025). A happy-path prototype, with nothing built to go wrong. I wanted to learn what users thought of the idea and to test the explanation page and content.
• Live test (May 2026). A happy-path prototype can't show how a live experience will perform, so I tested the live feature as soon as it launched. My product manager and I agreed on research goals first. It took about two weeks from kickoff to readout.
• Participants. Experian users from our panel. For the live study I screened for car owners who shop for auto insurance every one to three years, since users who never switch have little reason to use a comparison tool.
• Tradeoff. Moderated sessions let me observe each connection attempt closely. The findings show the kinds of failures users hit, not how often. However, we already had the quantitative drop off data from the Analytics team.

Key findings

1. Users valued linking, and most trusted Experian to do it

In the prototype test, users were receptive. They expected it to make shopping easier and wanted proof that any savings kept their coverage the same. In the live test, they reached quotes and rate monitoring and described the feature as useful.

2. Insurer logins were a real barrier

One participant normally used their insurer's phone app and couldn't recall the password on a laptop. They tried several guesses, worried about getting locked out, didn't want to reset a password just to shop, and never connected a policy.

3. Long waits eroded trust

Connection times ranged from one to more than five minutes. A progress message saying it could take seconds or up to a minute reassured one participant at first, then lost credibility as the wait outran it. After more than five minutes, they pressed Back and didn't want to move forward. Users asked for realistic timing in minutes and guidance on whether to refresh or leave the page.

4. Linking an account did not pre-fill much data

Connecting filled in vehicles, drivers, and coverage in parts of the experience, but users asked why they were still typing information the system seemed to have. They wanted editable suggestions they could confirm, not locked fields.

5. The payoff was uneven

One participant completed the flow, but the quotes were well above their current policy, and a familiar carrier required another website visit without showing a price.

Together, the five users hit four different problems: an access barrier, uncertainty during processing, unmet expectations about automation, and disappointing results.

Influence and outcomes

The delay happened during the connection step, which runs on the provider's experience inside Experian's interface. At the readout, I played several videos of users waiting and let them run in full. The room went quiet, and stakeholders could see the frustration build with each passing minute.

• What I delivered: the readout, the unedited delays in video form, and recorded connection times.
• What was implemented: the team treated the delay as a technical issue. My product manager worked with the provider on a fix, and the delays were corrected. The product team also worked to carry imported data through the rest of the experience.
• What was measured: I don't have post-fix results to share.

Reflection

What I learned. A prototype confirmed the idea was wanted. Only the live product showed that logins, waits, and pre-filling would decide whether it worked.

What I'd do differently. Sharing findings and moving on to the next team and project is the usual pace of the work, but I wish I had set aside time a month later to revisit the experience and confirm the technical issues were resolved. For any team launching an account-connection feature, I'd recommend research over a longer period, so problems surface as soon as they appear and fixes are checked.

What remained unresolved. The pre-filling gaps had not been corrected.

Appendix: methods and supporting detail

The full method notes and the rest of the findings, for a deeper read.