Scan to
Insure.

CURE Auto Insurance is a direct-to-consumer auto insurance provider serving drivers in New Jersey and Pennsylvania. I was brought in to redesign their existing quote flow — the primary entry point for new customers seeking an insurance quote.

As part of that redesign, a recurring theme emerged: the biggest source of friction wasn't the flow structure alone — it was manual data entry. Users were expected to recall and type information directly from their driver's license across more than 20 screens. That insight drove a parallel workstream: designing a Driver's License Scan feature — an API-powered capability that automatically extracts a user's personal information, registered vehicles, and household members directly from their scanned license, eliminating manual input and dramatically reducing the steps required to reach a quote.

Before I joined the project, CURE's Customer Experience team had been monitoring the Quick Quote funnel through internal session analytics and inbound support data. What they found was consistent and costly: users were abandoning the flow at high rates, and those who did call support most often cited confusion and frustration during the information entry phase.

Their data established the following baseline across a 90-day sample period:

The support log analysis surfaced two recurring themes: users who didn't know what information was being asked of them, and users who had made an error mid-flow but couldn't correct it without restarting from the beginning. Nearly half of all users were walking away before ever seeing a quote.

The directive was clear: reduce friction, reduce screens, and give the scan feature the experience it deserved.

Before designing anything, I needed to understand exactly why the flow was failing — not just that it was. I walked the existing 20-screen experience against two lenses: a formal heuristic evaluation and a task-level field count.

I evaluated the existing flow against Nielsen's 10 Usability Heuristics and documented violations at each step. The three most critical failures:

I mapped every user action required across all 20 screens and counted each manual input field. The result: 24 total input fields, of which 16 were directly obtainable via the Driver's License Scan API — including name, date of birth, address, license number and status, registered vehicles, and household members.

That analysis made the case for the scan feature being the structural solution, not a surface-level enhancement. The majority of the form didn't need to be filled out by users at all — the API could do it for them.

Based on the CX team's baseline data and my flow audit, I aligned with stakeholders on three concrete goals before touching a single frame in Figma. This kept the work anchored to outcomes, not aesthetics.

This project had a clear creative tension at its center.

CURE's leadership was supportive of improvement but protective of their brand's visual language. Early prototypes pushed the design too far in a contemporary direction — cleaner layouts, bolder typography, more whitespace — and stakeholder feedback brought me back to center. They wanted the product to feel improved, not unrecognizable.

That constraint became a useful guardrail. Rather than chasing visual novelty, I focused on structural improvements: how information was grouped, how many decisions a user had to make per screen, and how clearly the interface communicated progress and next steps. The visual surface stayed familiar. The underlying experience got a complete overhaul.

The scan feature itself was powered by a third-party API — meaning my design contribution focused entirely on the surrounding experience: how we primed users to trust and use the feature, what the confirmation states looked like, and how we handled edge cases where the API data needed correction.

The redesign wasn't about new components or a new visual style. It was about reducing the number of things users had to do — and making every remaining step feel obvious.

The research on this project ran in two directions simultaneously: building the quantitative case for the redesign using existing data, and validating the design decisions through moderated usability testing before development began.

The 9% residual drop-off at vehicle confirmation reflects a real edge case: some users will see a vehicle or household member listed that doesn't match their current situation — a car they no longer own, a family member they don't want on the policy — and will exit to sort it out rather than proceed. That's not a design failure. That's the system surfacing accurate data that requires a real-world decision.

This project is currently paused in development following stakeholder approval. The design sprint reinforced how much structural UX work can be accomplished in a tight timeline when the problem is clearly defined upfront — and when the data to define it already exists.

Working within the constraint of CURE's visual language didn't limit the design. It forced me to find improvements that were structural and behavioral, not just aesthetic. The end result was something that genuinely served users better without requiring them to learn a new product.

If I were to continue iterating, the next design problem worth solving is one the usability sessions hinted at: trust in pre-populated data. Users paused at the vehicle confirmation screen not because the design was confusing, but because they were reading carefully before agreeing. That's healthy behavior — but it also raises a question worth testing: how might we design the confirmation experience to make users feel more confident that what they're seeing is accurate and up to date? Answering that question with a second round of testing would be the natural next step.