Optimizing Insurance Forms - A Video Workshop

Tips on improving the UX and conversion rate of insurance forms

In this short video workshop we run through Zuko's insurance report and look at some of the key elements you need to consider when you are experimenting on, and optimizing your insurance forms.

Things we cover include:

• Should you include a vehicle lookup and what is the best way to implement this
• Job pickers - why they are annoying and how to mitigate them
• How to ask for sensitive personal information
• Ways to break down questions like annual mileage which may confuse users
• Why progress bars are a good idea
• Should you try and manage user expectations
• Why dropdowns suck and what to do instead
• The optimal way to ask for dates
• Dodgy dark UX patterns

‍

Download the insurance form market report that is mentioned in the video here

‍

Optimising Insurance Forms: UX Lessons That Improve Conversion (Transcript)

Hello everyone and welcome to today’s session. As you can see from the slide, we’re focusing on optimising forms — specifically insurance forms.

We’ll be looking at the user experience of insurance forms, sharing research we’ve done on car insurance journeys in the UK, and giving practical tips you can apply to reduce friction and improve conversion rates.

I’m Alun from Zuko Analytics, and I’m joined by my colleague Adam.

Adam: Hi everyone.

Housekeeping

We’re live on LinkedIn, which means there’s a small delay. If you have any questions, please drop them in the comments as early as possible. We’ll answer them as we go or at the end.

What We’ll Cover Today

We’ll start with a quick introduction to who we are and why this topic matters. Then we’ll walk through:

• The research we carried out on UK insurance forms
• The methodology behind the audit
• Some examples of the best and worst-performing insurance form journeys
• The main optimisation lessons and UX pain points we discovered
• Practical recommendations for reducing abandonment

Why Listen to Us?

We’re from Zuko Analytics, a platform that tracks user behaviour on online forms.

Zuko helps identify:

• Which questions cause users to hesitate
• Where people abandon
• Which fields generate frustration and drop-off
• What changes are likely to increase completions

We’ve been doing this for over 10 years, and we’ve analysed thousands of forms across industries.

Although today’s examples focus on insurance, most of the lessons apply to any complex multi-step form.

Research: UK Car Insurance Form Audit

Recently, we carried out an audit of 27 UK car insurance forms.

We reviewed them against 42 different UX criteria, covering everything from usability fundamentals to specific friction patterns that commonly appear in insurance journeys.

Each form was scored using a matrix and algorithm so we could identify which forms offered the best overall user experience.

We’ll share the report link later, but most of today’s discussion is based on insights from this research.

The Best and Worst Insurance Forms (Quick Summary)

Naturally, everyone wants to know: who did best?

Top performers

1. By Miles
By Miles ranked number one overall. The standout feature was its simplicity — it asked only seven questions to reach a quote.

That’s a huge difference compared to the overall average of 40 questions, with some forms reaching as high as 48 questions.

By Miles also scored strongly on multiple UX fundamentals.

2. LV and Saga
LV and Saga also performed well. They didn’t necessarily reinvent anything, but they avoided common UX mistakes and got the basics right, such as:

• Live validation
• Correct HTML input types (email, phone etc.)
• Reduced unnecessary friction

Poor performers

Some brands scored significantly lower than others.

GoGirl ranked as the worst-performing form overall. It included some particularly frustrating patterns such as:

• Poor date picker implementation
• A finger slider for selecting values (e.g. trying to set an excess to £250 by dragging a slider)

John Lewis Insurance was also surprisingly poor. It appeared to have built a custom interaction pattern system from scratch rather than using established UX patterns that reduce friction.

AXA underperformed by failing to deliver on basic UX fundamentals.

Key UX Optimisation Lessons for Insurance Forms

Now we’ll move into the main part of the session: the key friction points we found and what good implementation looks like.

1. Vehicle Lookup (Registration-Based Autofill)

One of the most valuable features on car insurance forms is vehicle lookup using a registration number.

Alun: Adam, why is this important?

Adam: It drastically reduces the workload for the user. Without lookup, you may be asking six or seven questions tied to the vehicle — model, engine size, year of manufacture, and so on.

Not only does that take time, but it also creates abandonment risk because the user may not know the answers.

Most forms did this well, but the stronger implementations went further by also suggesting an estimated car value, which removes uncertainty.

Alun: I completely agree. “What is your car worth?” is a surprisingly difficult question unless it’s brand new.

If users have to leave the form to check the value on a third-party site, the chance of abandonment increases massively.

Key takeaway: Vehicle lookup is now a baseline requirement — but including an estimated car value makes it significantly stronger.

2. The Occupation Field (A Classic UX Minefield)

Occupation is one of the most frustrating fields in insurance forms.

In our audit, 93% of forms asked for occupation, while only two did not — which shows it’s not always essential for generating a quote.

But if you do ask it, it creates several risks:

• Users aren’t sure which option is “correct”
• People worry about invalidating their insurance if they choose wrong
• Job lists often feel outdated
• Users waste time scrolling or guessing

Adam: Even if a form includes guidance like “choose the closest match,” it’s still a minefield — especially if your job is modern or doesn’t fit neatly into a predefined list.

Alun: There’s also the frustration of asking essentially the same question twice — for example, “What is your job?” followed by “Which industry is this?”

Sometimes the logic is absurd. If someone selects “butcher,” the industry is obvious.

Best practice recommendations:

• Use a searchable dropdown (not a 200-item scroll list)
• Use conditional logic to avoid asking redundant follow-up questions
• Add clear fixed guidance beside the question (not hidden in a tooltip)
• If possible, reduce the number of occupation-related questions altogether

3. Sensitive Fields: Email and Phone Number

Insurance forms often require sensitive personal details like email and phone number — but the way this is handled has a major impact on trust and abandonment.

Adam: The worst examples were where email and phone number were both mandatory, with no supporting explanation. That immediately triggers suspicion: “I’m going to get spammed.”

Better examples either:

• Made phone number optional
• Explained clearly why the information was needed
• Used microcopy to reassure the user

One example we saw made phone number optional and added context such as “we may need to contact you in the event of a claim.”

Alun: The problem is that users are often still in the quote stage. They’re not committing yet — they’re comparing prices. Forcing contact details too early adds unnecessary friction.

We’ve also published data showing that email and phone number fields are consistently among the highest drop-off fields on forms. Phone number in particular creates strong resistance.

Best practice recommendations:

• Don’t ask for phone number unless you genuinely need it
• If you must ask, make it optional
• Always add microcopy explaining what you will and won’t do
• Avoid asking users to confirm email or phone unless absolutely necessary

4. Annual Mileage: A Question Most Users Can’t Answer

Annual mileage is a common insurance question — but most people don’t actually know the answer.

Adam: I can probably tell you weekly mileage, but annual mileage? No idea.

The best implementation we saw was a calculator that allows users to estimate mileage daily, weekly, or monthly and then converts it into an annual figure.

Other approaches included:

• Showing a “miles per week” reference value after the user enters a number
• Dropdown ranges (e.g. 1,000–2,000, 2,000–3,000)

But dropdown ranges don’t really help users estimate — they just force them to guess.

Alun: We’ve seen this personally too. When you break it down into “miles per day,” it becomes easier to sanity check.

Best practice recommendations:

• Offer a mileage calculator (daily/weekly/monthly)
• Provide reference points (e.g. average UK mileage)
• Explain why mileage matters (pricing logic)
• Avoid leaving the user with a blank field and no guidance

5. Progress Bars: Essential for Long Insurance Journeys

Progress bars are critical in multi-step insurance forms.

In our audit:

• 81% had a progress bar
• But only 52% allowed navigation between completed stages

Adam: The best progress bars clearly show:

• How many steps remain
• What each step relates to (labels like “Your details,” “Your vehicle,” “Drivers,” etc.)
• Allow users to navigate backwards easily

The weaker ones only display “Step 2 of 5,” which gives minimal reassurance.

Alun: Insurance users often want to go back and check answers. They may deliberately enter an estimate to see the quote, then revisit earlier steps to refine details.

If your progress bar doesn’t support that behaviour, you’re adding unnecessary frustration.

Best practice recommendations:

• Always include a progress bar in long forms
• Label the stages clearly
• Allow navigation back to completed steps

6. Upfront Warnings: What Users Need to Have Ready

One of the most common reasons users abandon long forms is reaching a question that requires information they don’t have to hand.

For example:

• Driving licence details
• Passport info
• Claims history
• Additional driver information (DOB, contact details etc.)

Tesco provided a strong example of preparing users by listing what they would need before starting.

Only 15% of forms in our audit did this.

Adam: If users aren’t warned, they have to leave mid-process, and many won’t return — or worse, they return and find the session timed out.

Tesco also did something else well: they included an eligibility checklist upfront (e.g. age requirements, licence status), which prevented users wasting time completing a long form only to be rejected at the end.

Best practice recommendations:

• Tell users upfront what information they’ll need
• Include eligibility criteria early
• Avoid forcing users to discover blockers late in the journey

7. Dropdowns (Our Biggest UX Pet Hate)

Dropdowns are everywhere, and often unnecessary.

Adam: Many forms used dropdowns by default even when there were fewer than six options — where radio buttons would have been far better.

Radio buttons are:

• Faster
• Easier to scan
• Better for mobile
• Less cognitively demanding

When dropdowns are unavoidable (long lists), they should be searchable.

In our audit:

• About two-thirds used radio buttons correctly for short lists
• But only 11% made long dropdowns searchable

Alun: Poor dropdown UX is one of the biggest causes of mobile abandonment. Users don’t want to scroll through 50 options on a phone.

Best practice recommendations:

• Use radio buttons for small option sets
• If dropdowns are long, make them searchable
• Design dropdown behaviour specifically for mobile

8. Save and Resume (Only One Form Had It)

Shockingly, only one form in our audit offered a save-and-resume feature.

This allows users to exit safely and return later without losing progress.

Adam: It’s incredibly valuable for long, complex forms. Users often need to pause due to time constraints or missing information. Save-and-resume prevents them losing 20 minutes of work.

Best practice recommendation:
If your form is long, save-and-resume should be standard, not rare.

9. Date Pickers (Especially for Date of Birth)

Date pickers can be useful — but for date of birth, they are a terrible experience.

Adam: They’re inherently ageist. The older the user is, the more scrolling they have to do.

For DOB, the best implementation is three simple text fields (day/month/year). It’s faster, simpler, and less error-prone.

Date pickers are only useful when selecting a date near the present — such as “when do you want cover to start?”

Best practice recommendations:

• Never use a calendar picker for DOB
• Use three input boxes
• Reserve date pickers for near-future or near-present date selection

10. Sneaky Account Creation (A Dark UX Pattern)

The worst pattern we saw was forcing account creation at the end of the quote journey.

Only two insurers did this: Admiral and Elephant (likely the same parent group).

Users completed the entire form and then were told:

“To secure your quote, you must create an account.”

Adam: This was extremely sneaky. It’s clearly designed to exploit sunk cost psychology — the user has already invested time, so they’re pressured into creating an account.

But users want quotes to compare providers. Creating an account feels like commitment, and it adds a password field — one of the biggest abandonment triggers of all.

Alun: If you want account creation, do it after the user has received the quote — not as a barrier to getting what they came for.

Best practice recommendations:

• Never block quotes behind account creation
• Avoid adding password creation to quote journeys
• If an account is needed later, request it after value has been delivered

Wrap-Up and Report Link

That’s a practical overview of the main UX issues we found in insurance forms.

If you’d like the full report, we can share the link — either via LinkedIn message or in the post.

If you want to know more about Zuko, form tracking, or optimisation, feel free to reach out to either me or Adam. LinkedIn is usually the easiest way to contact us, or you can email us directly.

Thanks for watching — and if you have questions, drop them in the comments and we’ll respond as soon as we can.

Cheers everyone.

‍