Claims Remapping
The challenge
With the increase in frequency of natural disasters as an effect of climate change the insurance claims reporting process is more important than ever. After Hurricane Ian, Kin Insurance faced an overwhelming number of misfiled claims resulting in losses in the hundreds of thousands. I optimized the claims reporting process by utilizing more customer-friendly language and adjusting the flow of questions to get more accurate mapping on the back end.
The team
Product Designer (me), Product Manager, Engineering Manager
The outcome
Optimized peril selection process resulting in 40% more accurate claims reporting.
Background
In the wake of Hurricane Ian, Kin Insurance’s Claims Reporting customer funnel faced the highest volume of claims on record. Of those claims, 40% were tagged with the wrong code which mapped to our automated vendor assignment process. That code dictates what type of Insurance Adjustor would need to be assigned to which customer. Having those out of sync causes the process of getting paid out in some cases to take an extra several months. These hiccups resulted in Kin paying a significant amount of money to reassign them to the proper person and culminated in a negative reflection on our overall NPS score.
"Lets face it, you really only need your home insurance when you really need it."
- Anyone with a bad claims experience
Let's dig in
What was causing such a high volume of inaccurate claims?
.png)
Wind > Water
With that question in mind, it was time to connect with the rest of the team to cast a wide net of discovery research, starting with the data points we could easily pull form. We realized via a Looker dashboard that the vast majority of the issue came from users selecting water damage as opposed to wind damage.
Your house looks like a glass half empty and the couch is now a floatation device, so its obviously water damage, right?

Yes and no.
TL/DR: The source of the water determines what peril this would fall under and ultimately which policy covers which portion of the damage
You see although you may have damage from water, hurricanes and named storms can cause a variety of types of damages such as storm surge, wind-driven rain, etc., and depending on the coverage you have across your homeowners and flood insurance policies, will determine which one you need to file a claim under. If its for your homeowners insurance policy, then the cause of the damage determines which Insurance Adjustor needs to be assigned to your particular case. The faster we can make this process for our users, the sooner they can get their claims settled and in some cases, can finally start to repair their lives.
Current state and where might the confusion lie

System matched our system's experience and not our customers
The experience had every option a customer could need, however, the terms were 1:1 with Snapsheet, which is the program its mapped to on the backend. So although comprehensive, it had limited options and the information wasn't presented in a way that reflected how our customers experience these things in real life.

Categorizing by Weather and Non-Weather events
It became increasingly clear that we needed to add more steps in the process so that we could further refine the data entry. This would in turn lead to a faster claims process and allow us to curate the subsequent series of questions in a way to get precise detailing of the damage. Usually you want to remove friction and steps in a funnel/flow but in this case we predicted that the more steps would actually increase confidence in their selection.
Our theory...

Let's solve some problems
We have a good sense of whats causing the confusion and we've started to formulate ways to solve for this. We knew we needed new copy, so I brought in our Insurance Claims Specialists to review our initial set of terms, which would eventually have to go through legal and compliance. Once the terms were approved I mocked up the solution and prototyped it for usability testing.
.png)
It's cross-collaboration time!
Since insurance is a highly-regulated industry was time to sync with experts on the insurance side of things to see what wiggle room we have on the copy. Once we agreed on a list of terms we of course had to check with our pals over in legal.
Design
With an idea for a testable solution and a series of legal approved terms and tooltips, it was time to put fingertips to keyboards and push some pixels! I quickly realized that the solution wouldn't require any net new components or functionality, so I was able to quickly mock up and prototype things utilizing the Kinetic Design System's variable Figma components I made previously. Making the only contribution I'd have to make to the Design System would be a few new tile illustrations.

Vertical slice of immediate value - tooltips
Due to timeline and technical constraints, they weren't able to release tooltips on their initial launch or subsequent releases. We knew we couldn't rely on tooltips solving the entirety of the problem but it was a great candidate for a vertical slice of value we could add while we finalize our answers to the main question. Since this is a component that's already been built the functionality would be easy to implement and would serve as a vehicle to collect data while I was cracking away on the usability test.

Testing, 1, 2. Testing 1, 2.
In an effort to measure thrice and cut once and since I bought us a bit more time to perfect the solution, I wanted the make sure that we tested the new copy through a moderated usability testing. In summary, I had a 100% completion rate with our 8 participants we screened using the criteria you'll find below. In addition to successfully identifying an initial damage that ultimately mapped to the right code in Snapsheet, most of them also felt very strongly that they selected the right answer.
What our participants looked like on paper
Utilizing Usertesting.com I was able to rapidly collect insights via a moderated usability test. We focused a lot of our research efforts in Florida as that was their biggest target market at the time of the research and historically a great benchmark for our general customer base. It was important that they had the claims process fresh in their minds so we made sure they identified the last time they filed a home insurance claim.
.png)
Key takeaways
We knew that we had a solution that could accomplish what we needed but there were a couple things worth calling out and iterating on to ensure our solution could weather the next major storm.
.png)
Weather vs. Non-Weather = ☑️
Initially there was concern over adding more questions into the funnel, but the data showed that the additional friction allowed us to get people through faster because they felt more confident in their selections.
.png)
Fine tune the language
Although all the participants selected an option that ultimately mapped to wind damage on the backend, they didn't select the exact answer we hoped for. This indicated we needed to tweak the language slightly to match the users expectations. Luckily I planned for this in the usability test by going over every statement with the user to ask if they made sense and if not, have them put them in their own words. I used this to inform the rewrites by using the most confusing terms and most used verbiage they used to describe their thoughts about said terms. Once stamped for approval by legal again, we're ready for takeoff... I mean hand off!
Where do we go from here?
- Look at the entirety of the claims funnel to see if we could apply the same learning process to in other sections of the process
- Connect with real Kin Customers - Insurance is highly-regulated and so we had to go through proxy users, however, since then, the legal team has eased up on our access to actual Kin customers.
- The true test of any claims experience is the next large scale weather event and I'd like to utilize that time to learn, iterate and improve the experience