When people start thinking about purchasing life insurance, it tends to be in the context of buying a house, having a child, or starting a business. That’s because life insurance is about protecting the people who depend on you, which usually starts with a spouse or significant other. Since these couples are having the life insurance conversation together, it makes sense to facilitate this process in our user experience by getting both spouses covered.
Opportunity Space
Though a majority of Ladder life insurance policyholders are in a committed relationship, very few of their significant others are actually covered. And while there are many reasons the significant other tends to lack coverage, including what they see as sufficient coverage through work or not being the “bread winner,” I have found that most couples discuss acquiring a policy together before only one of them signs up. So why not utilize this opportunity to get both spouses signed up?
This would be a win-win; it would be amazing for the business because it could cut the customer acquisition cost in half, and it’s crucial for people in today’s economic climate to have a healthy financial portfolio for peace of mind. Seeing as many couples, especially when there is a child in the mix, are both working, it’s important to know that if anything happens to either of them, the other won’t struggle financially.
In Ladder’s case, we weren’t offering this as an option, talking about it, let alone creating a user flow that would allow for it intuitively.
Spouse Connections MVP(ish)
The goal of this project was to provide a way to get the spouses of our new policyholders covered. I did this by utilizing the beneficiary setup process for the policyholder to identify spouse relationships, then prompting the policyholder to see if their spouse would also like coverage. This not only creates a more intuitive user journey, directing users down an expected funnel, but it also facilitates the process for a single user to set up policies for both spouses.
1. Setting The Beneficiary
After the user completes their application, receives a term offer, and becomes a policyholder, they are directed to the Policy page within the account to set their beneficiaries.
In order to complete the beneficiary form, the policyholder must select a relationship. If any of the spousal relationships are chosen — Spouse, Wife, Husband, Fiancé, Fiancée, or Domestic Partner — the spouse connections modal is triggered.
2. Spouse Connections Modal
The modal takes the policyholder from the current account to the new application. It sets the expectation that the beneficiary was saved successfully, and if the spouse application is started, they’ll be logged out.
The modal language is framed in a way that only asks if the policyholder’s spouse wants to be covered, keeping the person who will complete the application ambiguous.
3. Starting The Spouse Application
If the policyholder clicks “Get Started” on the modal, s/he will land at the beginning of a new application in a logged out state. From a regulatory perspective, this is important because the person filling out the new application has to be the person applying for coverage. Therefore, no assumptions can be made as to who is filling it out.
In order to make the spouse application more efficient, the relevant beneficiary form fields have been pre-filled.
4. The Alternative Path
Alternatively, the policyholder can choose not to continue with a spouse application and close the modal. This could be because s/he wants to continue entering other beneficiaries or does not want to fill out another application at the moment.
In any case, the policyholder can access the spouse application on the beneficiary card at any time under the More Actions section.
Process
Frame
Focus on Couples. With a focus on bringing acquisition cost down, the product team decided to look into couples. It makes a lot of sense because we could spend marketing dollars on one person and, ideally, get two, cutting acquisition costs in half. Plus, being in a committed relationship is really the first time most people need to start thinking about life insurance.
What’s Happening Today. Policyholders that start a second application, thinking it would be for their significant other, end up getting stuck at the identity check. This happens because new applications on logged-in accounts automatically pre-fill personal data and lock specific PII for security reasons.
The Workaround. In order for a logged in user to get coverage for their significant other they would have to know to sign out and start a new application. And really, how would anyone instinctively know that? They wouldn’t.
Opportunity Size. With the help from my data counterpart, I evaluated our current policyholder population and their beneficiaries to understand what kind of impact this project could have on our monthly policy rate. Here’s what the data showed:
Up to this point, approx. 80% of policyholders have set at least one beneficiary.
Of this population, approx. 60% have set a beneficiary with a spouse relationship, which includes: “Spouse,” “Wife,” “Husband,” “Fiancé,” “Fiancée,” or “Domestic Partner.”
This translates to approx. 50% of all policyholders having what we consider a spouse.
Unfortunately, determining how many current policyholders are spouses to each other was inconclusive (based on factors like last name, address, and household income), due to complexity around how users enter information.
Based on the information we had, the data analyst and I believed the number of married policyholders to be low.
Therefore, the potential impact of targeting couples could be significant, even if we just focused on current policyholders.
Constrain
Digestible Problems. Knowing this could greatly decrease our acquisition cost, I completed an exercise to reframe our bigger problem into smaller, more actionable ones, which were then broken down into different concepts. (Problem Breakdown)
Big Problem: We are seeing lots of people with spouses come to Ladder and not get their spouses covered.
Key Sub-Problems:
Users consider life insurance a solo task.
Users want to sign up as a couple but don’t know they can.
Couples don’t consider the non-working spouse valuable enough to get covered.
Users don’t understand that life insurance through work isn’t enough, so they think they are already covered.
Users want to confirm with their spouse before moving forward with a policy, then they either never get it done or start shopping around again.
Brainstorming. In order to understand the breadth of possibility and get more perspectives on how we could address a couple’s experience, I held a brainstorm with the project team. Three major categories emerged, which were then broken down into concepts. With a goal of vetting each idea, I added relevant questions. (Brainstorm)
User Research. With such a wide array of options being considered, I wanted to better understand how users with spouses approached our application. This would help narrow down ideas that would likely be more successful. (Test Script)
I ran a user study to understand if users:
1) Considered getting their spouse covered,
2) Filled out their spouse’s application with their spouse or by themselves,
3) Wanted to be prompted to sign their spouse up, if they were to sign up online.
Research Findings. Having interviewed ten married individuals that filled out their own life insurance application, I found three main insights. (Analysis Spreadsheet)
Insight 1
All participants said they would consider signing their spouse up when signing up themselves.
For Ladder this meant: Users don’t know they can sign up sequentially, or they are not the type of person to fill it out for their spouse, or the spouse is “already covered,” or it’s still on their to do list, which will almost never get done.
Insight 2
Almost all participants would want to know if they could complete a spouse application at the top of the funnel.
For Ladder this meant: Letting users plan to complete a spouse application at the same time they sign up themselves, without interrupting their current application flow.
Insight 3
Couples are having the ‘life insurance’ conversation together, followed by one spouse filling out both applications.
For Ladder this meant: Focusing on the spouse that is signing up with us in order to get both applications completed. This will allow us to be part of the user conversation that is already taking place between the couple.
Initial Concepts. These insights led to an initial and robust set of ideas, which I mapped out to start the conversation with my stakeholders.
The Spouse Application
Sharing Calculator/Quote
The user starts an application, entering in a household income that differs from the annual income. Subsequently, we ask if they have a spouse and if they would like to start an application for them.
If users use the calculator or quote before the application, either the spouse inputs could be built in or an option could be added to share it. This way, the user is more confident in completing their application with us because we took part in facilitating the conversation they were already having.
Unified Experience
Both applications would have the same user experience, including the same experiments and final decision process. This would then list both policies on a joint account, allowing both emails to access the same account, but with different permissions. With a joint account, there only needs to be one form of payment, one address, amongst other efficiencies.
Moving Towards An Ideal
Ask for the user’s beneficiaries before the application. If a spouse or children are identified, we could ask if they would like the sign up their spouse or child.
An onboarding step, where we ask if they want to do a spouse application, could be added at the top of the application funnel.
Either the calculator or quote could be added to the application, where we could ask about the user’s marital status. If married, we could ask if they want to get their spouse covered.
Explore
Spouse Application. Focusing on the core concept first, I began exploring the spouse application. This directly related back to the research findings and would have the greatest impact on lowering user acquisition cost. Since something like this had never been attempted before online, the legal team provided a couple of constraints:
Digital Agreement
The spouse needs to agree to our Terms and Conditions, Pre MIB Notice, and Pre Authorization in order accept a policy.
Spouse Application
The policyholder cannot fill out their spouse’s application for them.
While I wasn’t worried about the digital agreement, figuring out how to get a spouse to fill out their own application presented a serious concern.
Spouse Pathways. Digging into the spouse application concept, I explored various means of identifying the spouse as well as how I might, intuitively, get the spouse to complete their own application. In my explorations, there seemed to be two main ways to identify a spouse.
Income Difference
If household and annual income are different, after a user accepts a policy, they are asked if they’d like to start a spouse application. Once the policyholder submits the spouse application, it is sent to their spouse to review and confirm, then submit the application.
This is similar to the flow on the left, but in this concept there is an added step asking the user if they want to start a spouse application, defining a more task-focused experience. This leaves room for targeted messaging and incentivization.
Beneficiary Relationship
Once a user accepts a policy, they will set their beneficiaries on the Confetti page. If a spouse relationship is identified, the next page prompts them to start their spouse application.
The user starts their application by filling out their beneficiaries. If a spouse relationship is identified, the user would be prompted to start a spouse application, after accepting a policy.
What If. Since legal was still up in the air about being able to do the spouse application, in a design feedback session, the design team posed a question: “What if a spouse application wouldn’t be possible?” In order to do my due diligence as a designer, I looked back to my concept list and began to explore how the quote tool could be shared with a spouse — this would avoid any issues regarding filling out a spouse’s application but still allow them to take part in facilitating the conversation.
The user sets their beneficiaries at the beginning of their application to identify a spouse. If there is a spouse, they’ll be asked for their email after app submission, in order to send them an email that shares the policyholder’s account info.
Once a user becomes a policyholder, they’ll save their beneficiaries. If a spouse relationship is identified, they’ll be asked if they want a spouse quote, which can then be shared with any email.
After the user accepts their term offer, they’ll be asked if they want to get a spouse quote on the Confetti page. If they agree, they can complete the quote and share with any email.
After the user accepts their term offer, a to-do list will display on the Confetti page, which links them to the next action that needs to be completed, including a spouse application.
Continued Exploration. With greater confidence in giving the user a directional task, leaning into the user’s expected mental model after having just accepted a policy themselves, I continued to explore the spouse application. I started by identifying four experiences that provided more context around how we might achieve a spouse application.
Straight To Spouse Review
This concept allowed the policyholder to complete the spouse’s application, then email their spouse to review, sign, and submit their own application.
Beneficiary On Confetti
This concept added the beneficiary form onto the celebration moment, the Confetti page, after the user accepts their policy. If a spouse relationship is identified, we would ask if they’d like to start a spouse application.
Beneficiary First
This concept brings the beneficiary input to the top of the applicational funnel, reminding users why they’re getting covered. If a spouse beneficiary is entered, the spouse application question is triggered after the user accepts their policy.
Directional Policyholder
After the user has accepted their offer, the user is guided through several steps asking for their beneficiaries, which then triggers the spouse application question.
Half Baked. Having reached an MVP of the spouse application user experience that I believed would be successful, I presented it to my stakeholders. (Concept Deck)
It consisted of two parts:
Planning Ahead. First, adding a question at the top of the application funnel, allowing users to plan for their spouse’s application, directly relates back to the study findings that users want to know that they can sign up their spouse.
Policyholder Experience. Second, utilizing the Directional Policyholder flow (shown above) to collect beneficiaries, identify the spouse relationship, and trigger the spouse application question seamlessly leads the user into the new application.
Focus
Redirecting The Experience. While the flow I presented addressed the core of the opportunity space, the head of engineering considered it a large effort. He suggested using a simpler version of one of my quote flows, the Post Beneficiary Spouse Quote flow, which used the current beneficiary infrastructure. This way, we could test the concept before increasing scope — even though it didn’t capture user intent in the same way, his suggestion made a lot of sense.
The Proposed MVP Flow. The user is prompted to start a spouse application when they have saved a beneficiary with a spouse relationship within the current beneficiary flow.
Outstanding Questions. Though the team agreed on how we would proceed, there were still some outstanding questions that needed to be answered before moving to build.
How would we handle the currently logged in account if the user starts the spouse application?
After discussing with engineering, the simplest action to take would be to log the current user out. While it’s not the most clear experience, it definitely makes for a seamless transition without getting in the way of the user.
More importantly, logging the user out, along with some copy on the modal, solved the legal concerns. By signing the user out, Ladder doesn’t know who is starting the application and we can’t assume the spouse isn’t at the computer, allowing the concept to finally be legally approved.
Do we want to pre-fill the spouse’s questions that we already have answers to?
Pre-filling the spouse application was something I definitely wanted to do, but after discussions with my project manager, we decided to leave it out of the MVP in order to test this in production as quickly as possible.
If the user closes the modal, how would they get back to the spouse’s application?
This was actually a flow problem. There was no way to re-access the spouse application from the policyholder’s account. But, since the priority was to test if people would actually use this functionality, the team decided to make this update post MVP, knowing that some users would ex-out in order to finish entering their beneficiaries.
Is this truly a better experience than sharing a quote to facilitate the conversation?
When having to choose between two MVPs, I truly believe that the spouse application is a better experience than focusing on the quote sharing functionality. This belief is backed by qualitative research that told us how only one spouse takes action, despite the fact that the life insurance conversation happens together. Furthermore, the prompt is approaching users that are already in the life insurance head space, having just successfully purchased their policy. There would be no better time to target these individuals.
Define
The MVP. With some tweaking and collaboration with my engineering counterpart, I finally landed on an MVP experience. The idea afforded policyholders who set a spouse beneficiary the ability to start an application for their spouse, so both users could potentially get covered in one sitting.
Good Results. The numbers didn’t lie. While there was a relatively small click-through-rate on the modal into the spouse application — approximately 10% of users — the percent of spouses that converted into policies was huge, hitting a conversion rate of more than 50%.
V2. The MVP performed well from the start, so we decided to update the experience a bit, adding the two pieces that we have previously left out: pre-filling the spouse application and fixing the closed modal problem.
Creating Scalability. After working through several rounds of feedback, I landed on adding a dynamic More Actions section to the beneficiary card that could house the spouse application after the modal is closed, as well as any other actions that we had or would have in the future.
Post Implementation
With such great success around the purposeful targeting defined in the spouse connections experience, I was able to utilize the Directional Policyholder flow that I had presented in the half baked meeting. This would further enhance the user experience and put more emphasis on our referrals program within the user journey.
Next Steps
When it comes to targeting user relationships, the possibilities are endless for a digital platform. Here are a couple of ideas that I thought could build an even better user experience.
Expanding to other targeted relationships, such as children.
Better utilization of incentivizations.
Showing the same experiments across both applications.
Joint accounts to connect family members
Introducing the planning question in the application, with educational pieces targeting incorrect social norms
Learnings
Targeted users are better users.
Sometimes when we are looking for the next new user, we forget to look at how we can utilize the network we have already built. From Ladder’s perspective, this meant looking at our policyholders, who have put a tremendous amount of trust in our product and, therefore, should be our biggest advocates, wanting to see us survive the test of time. Then, by signing families up together, we can create an even stronger connection between our policyholders and the brand, ultimately supporting retention and future growth.
Right place, right time is powerful.
Anything can be thrown onto a page, and, sadly, lots of times it happens that way. It’s when an opportunity presents itself that focuses on a targeted group of users, addressing a real need to achieve a purposeful outcome, where everything seems to fall in place; the user experience makes sense, users respond with planned behavior, and the metrics don’t lie. In the end, it’s always more powerful to make huge waves with a smaller population of users than no waves with anybody.
Prove it — then grow it.
I think it’s every designer’s dream to design something huge that just magically works. The truth is that we aren’t Jedis and implementing huge projects all at once isn’t a good idea. As it turns out, product development is about taking calculated steps towards a planned future state, even if it’s a moving target. It’s the reason we use MVPs and roll projects out over time, because something that is true today may not be true tomorrow, and we need to know that the core functionality is desirable to our users. It doesn’t have to be baby steps, but building something truly great rarely starts at 100%.