Insurance cancellation service
Overview
Switching insurance is not as simple as switching a telecom subscription, but most users expect it to be. When someone buys a new policy, they expect the old one to end automatically. In practice, each insurance follows its own legal process, and that gap creates friction for users and for the business.
This UX research case study shows how I tested a late-stage cancellation flow before the business built it. The project ran on a waterfall model. Requirements were fixed, contracts were in negotiation, and experts had already agreed on the solution. No customer had been asked yet. Early research changed the direction of the whole project.
My role
UX design
UX Research
Date
Client
Independer
The challenge
The cancellation flow came with three challenges.
Users expected automation. Telecom providers set the standard: you switch, and the old subscription ends. People brought the same expectation to insurance.
No two insurances worked the same way. Each type of insurance has a different legal structure, so each one had its own cancellation process. That made the flow complex to build and complex to understand.
The project was already set. Requirements were defined, contracts were in negotiation, and experts had voiced the solution. The team had invested a lot of effort without asking a single customer.
I was asked to design the solution for the moment after a user completes a purchase. The design was close to moving into refinement. I had a hunch that we needed to test it with users first.
The result
The project pivoted. The new approach produced a product that is easier to maintain and easier for customers to understand. It also reduced customer support tickets.
Early research kept the business from building a solution that would have caused a spike in contact after launch. I’m Nathan, a UX designer and researcher in Rotterdam, and I use research to test ideas before they become expensive to build.
The process
Push for research before refinement.
I pushed for qualitative research while the design could still change. In a waterfall setting, that meant making the case that the effort already spent was a reason to validate, not a reason to skip it.
User interviews with a realistic cognitive load
I interviewed 5 users. To make the sessions realistic, I created a synthetic cognitive load test. It mimicked the mental load people carry in the real flow, right after buying insurance. Participants worked through a clickable prototype that I built for the interviews.
Theme analysis with weighted scores
After the interviews, I ran a theme analysis and gave each theme a weighted score from 1 to 5. The results showed that the user experience of the flow worked as intended. People could follow the steps. One bigger issue stood out.
What the research revealed
The flow asked users to cancel manually. Many still believed it would happen automatically. Three more findings explained why this was a risk:
Users disliked that the company was not transparent about the collaboration behind the process. The contracts were already signed.
Users did not trust the process or know what would happen with their data.
Customer contact would have dropped at first, then spiked. There is a delay between starting a cancellation and realising that it is not finished.
Confirm the findings with surveys
We pushed back on the idea. To check that the interview findings held at scale, we ran 3 quantitative surveys. They confirmed the findings.
Validate the new approach with A/B testing
We iterated on a new approach and formed a new hypothesis. We validated it with an A/B test. The test was positive and led to a shift in the overall project.
Insurance cancellation service
Overview
Switching insurance is not as simple as switching a telecom subscription, but most users expect it to be. When someone buys a new policy, they expect the old one to end automatically. In practice, each insurance follows its own legal process, and that gap creates friction for users and for the business.
This UX research case study shows how I tested a late-stage cancellation flow before the business built it. The project ran on a waterfall model. Requirements were fixed, contracts were in negotiation, and experts had already agreed on the solution. No customer had been asked yet. Early research changed the direction of the whole project.
My role
UX design
UX Research
Date
Client
Independer
The challenge
The cancellation flow came with three challenges.
Users expected automation. Telecom providers set the standard: you switch, and the old subscription ends. People brought the same expectation to insurance.
No two insurances worked the same way. Each type of insurance has a different legal structure, so each one had its own cancellation process. That made the flow complex to build and complex to understand.
The project was already set. Requirements were defined, contracts were in negotiation, and experts had voiced the solution. The team had invested a lot of effort without asking a single customer.
I was asked to design the solution for the moment after a user completes a purchase. The design was close to moving into refinement. I had a hunch that we needed to test it with users first.
The result
The project pivoted. The new approach produced a product that is easier to maintain and easier for customers to understand. It also reduced customer support tickets.
Early research kept the business from building a solution that would have caused a spike in contact after launch. I’m Nathan, a UX designer and researcher in Rotterdam, and I use research to test ideas before they become expensive to build.
The process
Push for research before refinement.
I pushed for qualitative research while the design could still change. In a waterfall setting, that meant making the case that the effort already spent was a reason to validate, not a reason to skip it.
User interviews with a realistic cognitive load
I interviewed 5 users. To make the sessions realistic, I created a synthetic cognitive load test. It mimicked the mental load people carry in the real flow, right after buying insurance. Participants worked through a clickable prototype that I built for the interviews.
Theme analysis with weighted scores
After the interviews, I ran a theme analysis and gave each theme a weighted score from 1 to 5. The results showed that the user experience of the flow worked as intended. People could follow the steps. One bigger issue stood out.
What the research revealed
The flow asked users to cancel manually. Many still believed it would happen automatically. Three more findings explained why this was a risk:
Users disliked that the company was not transparent about the collaboration behind the process. The contracts were already signed.
Users did not trust the process or know what would happen with their data.
Customer contact would have dropped at first, then spiked. There is a delay between starting a cancellation and realising that it is not finished.
Confirm the findings with surveys
We pushed back on the idea. To check that the interview findings held at scale, we ran 3 quantitative surveys. They confirmed the findings.
Validate the new approach with A/B testing
We iterated on a new approach and formed a new hypothesis. We validated it with an A/B test. The test was positive and led to a shift in the overall project.
More works
Project
©Nathan Boomsma 2026. All rights reserved.
Project
©Nathan Boomsma 2026. All rights reserved.
Project
©Nathan Boomsma 2026. All rights reserved.