Digital IUL
Insurance-Application

Digital IUL
Insurance-Application

A New Tool in a Trillion-Dollar Industry

Project Context

Project Context

Amplify Life Insurance set out to achieve its most ambitious goal: to sell its own product as an insurance "carrier". A massive undertaking in the insurance world, becoming a carrier would be the equivalent of a travel website becoming its own airline. In order for the new product to succeed, they needed to launch a 100% digital IUL application, something which had never been done. (IUL stands for "Indexed Universal Life" insurance. It is a form of permanent policy that can have special benefits while you are alive.)

Amplify Life Insurance set out to achieve its most ambitious goal: to sell its own product as an insurance "carrier". A massive undertaking in the insurance world, becoming a carrier would be the equivalent of a travel website becoming its own airline. In order for the new product to succeed, they needed to launch a 100% digital IUL application, something which had never been done. (IUL stands for "Indexed Universal Life" insurance. It is a form of permanent policy that can have special benefits while you are alive.)

Task & Constraints

Task & Constraints

I was tasked with designing the flagship application experience. The interface would need to be capable of displaying any conceivable underwriting question from a partner's API return, including an unknown number of reflexives (questions that dig deeper into previous responses). Additionally, it would be subject to approval from third-party corporate partners, as well as regulators from each US State.

I was tasked with designing the flagship application experience. The interface would need to be capable of displaying any conceivable underwriting question from a partner's API return, including an unknown number of reflexives (questions that dig deeper into previous responses). Additionally, it would be subject to approval from third-party corporate partners, as well as regulators from each US State.

My Role

My Role

I worked with PMs and engineers to dramatically expand the walkthrough that I had previously designed. I incorporated questions from underwriting partners, built in reflexive paths, designed for unpredictable API-call wait times, and created a split-path architecture for users who did and did not qualify.

I worked with PMs and engineers to dramatically expand the walkthrough that I had previously designed. I incorporated questions from underwriting partners, built in reflexive paths, designed for unpredictable API-call wait times, and created a split-path architecture for users who did and did not qualify.

Outcome

Outcome

My designs helped launch the world's first 100% digital IUL insurance application—with the final interface operating as an autonomous system, parsing and displaying any conceivable underwriting question from our parter's API returns. This project allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

My designs helped launch the world's first 100% digital IUL insurance application—with the final interface operating as an autonomous system, parsing and displaying any conceivable underwriting question from our parter's API returns. This project allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

major launch

A company-transforming, flagship project. Approved by legal departments of underwriting corporations, and life insurance regulators in all 50 states.

major launch

A company-transforming, flagship project. Approved by legal departments of underwriting corporations, and life insurance regulators in all 50 states.

Project Details

Project Details

Below you will find a detailed breakdown of the Digital IUL Application project, from beginning to end.

Research & Discovery

Research & Discovery

Our leadership team identified the ideal customer profile as "mass-affluent"—earning $100,000 or more—between ages 25-45, and skewing male (though we marketed to men and women). I also recorded and analyzed the flows of 10 market-adjacent term brokers, with special emphasis on Ethos, Ladder, and PolicyGenius. Additionally, our underwriting partner supplied their API guide, which I integrated into the foundation of the system as a whole.

Our leadership team identified the ideal customer profile as "mass-affluent"—earning $100,000 or more—between ages 25-45, and skewing male (though we marketed to men and women). I also recorded and analyzed the flows of 10 market-adjacent term brokers, with special emphasis on Ethos, Ladder, and PolicyGenius. Additionally, our underwriting partner supplied their API guide, which I integrated into the foundation of the system as a whole.

API Calls

Our partner supplied JSON returns from their API, which fed our system the necessary questions for an IUL application. The design system needed to account for all possible response types (boolean, date, free text input, multi-select, radio, etc.), as well as delays in response times (see below).

Product Vision

Product Vision

"Applied at lunch, covered by midnight"

I summarized the design vision for this product with the idea that a qualified user should be able to apply on their lunch break, and be covered under a new policy by midnight. The application is necessarily quite restrictive, but on average around 20% of users qualified for the fully digital experience with zero manual underwriting.

I summarized the design vision for this product with the idea that a qualified user should be able to apply on their lunch break, and be covered under a new policy by midnight. The application is necessarily quite restrictive, but on average around 20% of users qualified for the fully digital experience with zero manual underwriting.

Colloquial, Approachable

Insurance can be intimidating, so we needed to make the application as approachable as possible. We used colloquial language where we were not required to use specific, legally-approved phrasing. When we asked for sensitive information, we communicated about information security in order to build trust.

Insurance can be intimidating, so we needed to make the application as approachable as possible. We used colloquial language where we were not required to use specific, legally-approved phrasing. When we asked for sensitive information, we communicated about information security in order to build trust.

#Goals

I designed this entry point for the application, and it tested well. It used a combination of rounded type, thin-line illustrations, and offset highlights to convey an approachable-professional aesthetic.

Sensitive Data

We often needed to ask for sensitive data. The team came up with a "green box" notification to assist in trust-building (I did not design these in particular). The boxes tested well and we used them throughout.

Split Path

Split Path

Qualified vs. Non-Qualified Applicants

The system needed to account for two types of user: those who qualified for the Prosper product, and those who did not. We needed to dynamically route each type of user, providing a seamless experience for both. Thus was born the split-path architecture underlying the Prosper application.

Final form: If any applicant responds to a question in a way that requires extra attention, the system takes two steps. First, it asks one or more "reflexive" questions, digging deeper into key details. Example: a user sees the question "Have you used any tobacco products in the past 5 years?" and responds "Yes". The system then displays reflexive questions regarding product types and frequency of use. If the user's subsequent answers still allow them to qualify for the Prosper product, then they continue with the digital application. They can still sign paperwork and gain coverage by midnight.

The system needed to account for two types of user: those who qualified for the Prosper product, and those who did not. We needed to dynamically route each type of user, providing a seamless experience for both. Thus was born the split-path architecture underlying the Prosper application.

In its final form, if any applicant responded to a question in a way that required extra attention, the system would take two steps. First, it would ask one or more "reflexive" questions, digging deeper into key details. Example: a user saw the question "Have you used any tobacco products in the past 5 years?" and responded "Yes". The system would then display reflexive questions regarding product types and frequency of use. If the user's subsequent answers still allowed them to qualify for the Prosper product, then they would continue with the digital application. They would still be able to sign paperwork and gain coverage by midnight.

The system needed to account for two types of user: those who qualified for the Prosper product, and those who did not. We needed to dynamically route each type of user, providing a seamless experience for both. Thus was born the split-path architecture underlying the Prosper application.

Final form: If any applicant responds to a question in a way that requires extra attention, the system takes two steps. First, it asks one or more "reflexive" questions, digging deeper into key details. Example: a user sees the question "Have you used any tobacco products in the past 5 years?" and responds "Yes". The system then displays reflexive questions regarding product types and frequency of use. If the user's subsequent answers still allow them to qualify for the Prosper product, then they continue with the digital application. They can still sign paperwork and gain coverage by midnight.

Qualified vs. Non-Qualified Applicants

However, if their responses require a human to assess their situation, then the system flags them for "manual underwriting". That user is unable to complete the full digital application, but may still answer several more questions to help find their best fit. Over time we determined that around 20% of applicants qualified for the full digital application, while 80% were still eligible for other products.

However, if their responses required a human to assess their situation, then the system would flag them for "manual underwriting". That user would be unable to complete the full digital application, but could still answer several more questions to find their best fit. Over time we determined that around 20% of applicants qualified for the full digital application, while 80% were still eligible for other products.

However, if their responses require a human to assess their situation, then the system flags them for "manual underwriting". That user is unable to complete the full digital application, but may still answer several more questions to help find their best fit. Over time we determined that around 20% of applicants qualified for the full digital application, while 80% were still eligible for other products.

Convergence and Divergence

Periodically, the user flow would converge into segments that were universal to all users (such as designating beneficiaries), and then diverge again into separate "Prosper" and "Non-Prosper" flows.

Unique Question Sets

Prosper-qualified users saw a unique set of questions that allowed them to complete the application 100% online.

Simple Experience, Vast Flow

Displaying the full flow here conveys the scope of the project. It asks questions regarding demographic, finances, health, and much more. Those who qualify can designate beneficiaries and sign all required documents completely online. In order to allow both users who did and did not qualify, I needed to create a split-path workflow that allowed everyone to complete some form of application.

access for all

From within heavy constraints and a complex workflow, our team and I designed an application so simple that anyone could use it.

access for all

From within heavy constraints and a complex workflow, our team and I designed an application so simple that anyone could use it.

An Exciting Design Challenge

An Exciting Design Challenge

Reflexives: Flying Blind

All Prosper-qualified users needed to answer a set of underwriting questions regarding things like health history, substance use and more. Our underwriting partner supplied those questions via API calls, which were themselves based on user responses. So each new question could be different depending on how the user answered the last one. Therefore I needed to design a system that could "fly blind" with no way of knowing what the questions would be, how many there would be, or how long the session would take to complete. That ruled out several patterns that can help with long processes: i.e. previewing the next question, or showing any form of progress indicator.

All Prosper-qualified users needed to answer a set of underwriting questions regarding things like health history, substance use and more. Our underwriting partner supplied those questions via API calls, which were themselves based on user responses. So each new question could be different depending on how the user answered the last one. Therefore I needed to design a system that could "fly blind" with no way of knowing what the questions would be, how many there would be, or how long the session would take to complete. That ruled out several patterns that can help with long processes: i.e. previewing the next question, or showing any form of progress indicator.

Pattern: Page Progression

To build such a design system, I used example JSON returns supplied in our partner's API guide, accounting for all response and input types: booleans, multi-select (checkboxes), free-text input, numerical input, drop downs, and more. Engineering appreciated the straightforward, plug-and-play approach which did not require them to combine or restructure any text. This also allowed for a cleaner legal review process, with required language represented 1:1 from our partner's database through to our front end.

To build such a design system, I used example JSON returns supplied in our partner's API guide, accounting for all response and input types: booleans, multi-select (checkboxes), free-text input, numerical input, drop downs, and more. Engineering appreciated the straightforward, plug-and-play approach which did not require them to combine or restructure any text. This also allowed for a cleaner legal review process, with required language represented 1:1 from our partner's database through to our front end.

On-Page Reflexive

Some pages would pre-load and display reflexive questions,on the same page. This was one useful pattern for making a long process feel moderately shorter.

The System at Work

Above is an example of the complex underlying design structure providing a simple front-end experience. Title and drop downs are populated. One answer has been selected.

Reflexive Example #1

These are some of the reflexive questions that a user could see when they provide information about their alcohol usage.

Reflexive Example #2

These are some of the reflexive questions that a user could see when they provide information about their THC usage.

Wait Time: A Crucial Bottleneck

Wait Time: A Crucial Bottleneck

Unpredictable API Calls

Third-party API calls could take time, and we had no way of controlling that. We could, however predict several points in the flow when those wait times would occur. A wait time of longer than 10 seconds is dangerous in internet-years, so we needed a way to keep people in the experience even when things took a while. The team and I arrived at three "wait-time masking" strategies based on the shortest, middle, and longest predicted wait times.

Third-party API calls could take time, and we had no way of controlling that. We could, however predict several points in the flow when those wait times would occur. A wait time of longer than 10 seconds is dangerous in internet-years, so we needed a way to keep people in the experience even when things took a while. The team and I arrived at three "wait-time masking" strategies based on the shortest, middle, and longest predicted wait times.

Successful Strategies

For ultra-short short wait times (2-seconds or less), we simply displayed a spinner. For short wait times we displayed a testimonial carousel, using the delay as an opportunity for trust-building. During medium-length wait times we invited interactivity, displaying a "How did you hear about us?" question. For longer wait times, we considered displaying a video, but ultimately decided to take the interactivity further–displaying additional questions from our own servers. All three strategies tested well. Not only did they keep users in the flow, they created additional value for Amplify through building trust and acquiring valuable user data.

For ultra-short short wait times (2-seconds or less), we simply displayed a spinner. For short wait times we displayed a testimonial carousel, using the delay as an opportunity for trust-building. During medium-length wait times we invited interactivity, displaying a "How did you hear about us?" question. For longer wait times, we considered displaying a video, but ultimately decided to take the interactivity further–displaying additional questions from our own servers. All three strategies tested well. Not only did they keep users in the flow, they created additional value for Amplify through building trust and acquiring valuable user data.

Wait Time Flow Chart

This deliverable outlines the path for engineering during the longest expected wait time of the flow.

Ultra-Short Wait Time

For ultra-short wait times we used a simple spinner.

Medium Wait Time: Invite Interactivity

For wait times in the 10+ second range, we invited interactivity and gathered user data.

Short Wait Times: Build Trust

During short wait times (10 seconds or less) we displayed a testimonial carousel to build trust.

Long Wait Times: Gather Data

For long wait times we inserted questions from our own servers, seamlessly transitioning back to the API-supplied questions when they had loaded.

breakthrough

Designing patterns that preserved engagement through unpredictable API response times was one of the most crucial successes of the project.

breakthrough

Designing patterns that preserved engagement through unpredictable API response times was one of the most crucial successes of the project.

Collaboration

Collaboration

Partner and Legal Feedback

The interface was subject to review from several parties, including our own legal team, the legal teams of multiple partners, and government regulators in each US state. I made adjustments as needed.

The most difficult part of the legal review process was the tension between "legal-ese" language and my desire to keep the application approachable, and to some degree colloquial. I was able to get a few especially opaque phrases officially updated, a process that took weeks and required dozens of worker hours on various teams. It was worth that effort, in order for users to understand what they were being asked.

The interface was subject to review from several parties, including our own legal team, the legal teams of multiple partners, and government regulators in each US state. I made adjustments as needed.

The most difficult part of the legal review process was the tension between "legal-ese" language and my desire to keep the application approachable, and to some degree colloquial. I was able to get a few especially opaque phrases officially updated, a process that took weeks and required dozens of worker hours on various teams. It was worth that effort, in order for users to understand what they were being asked.

Sanity Checks

I had regular meetings with the PMs to course-correct on product direction and details. We ran new ideas past engineering, through meetings and Slack, in the form of both static Figma-mocks and prototypes.

I had regular meetings with the PMs to course-correct on product direction and details. We ran new ideas past engineering, through meetings and Slack, in the form of both static Figma-mocks and prototypes.

Feedback Example #1

Instructions to update the copy for a draft of the "declined" page, after which we would refer a user to another provider.

Feedback Example #2

Instructions to update the copy for a draft of the final page, after a user had accepted and signed their policy.

Sanity Check: Prototypes

I created prototypes as a way to help engineers understand certain crucial flows, and to check for blind spots before handoff.

Delivery & Meta

Delivery & Meta

Delivery

Deliverable Format: Figma


Structure: I designed the interface largely using the Style and Component library that I created and maintained for the Product team (pulling in many contributions from others), which is based on the atomic framework. Engineering maintains a copy on their end.

Deliverable Format: Figma link.

Structure: I designed the interface largely using the Style and Component library that I created and maintained for the Product team (pulling in many contributions from others), which is based on the atomic framework. Engineering maintains a copy on their end.

Specs and Instructions

Reducing engineering lift and helping with clean execution means not just designing with modularity, but leaving clear instructions. I left annotations throughout the deliverable to assist engineers in execution. The metric of success here is to have as few questions as possible after delivery. Where necessary, I mocked up animations to demo behavior.

Edge Case Examples:

  • Notes in the "Beneficiary" section cover an edge case in which a user indicates their relationship with the beneficiary is "Other".

  • Instructions in an early form of the "Wait Time" section cover flows that include unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Reducing engineering lift and helping with clean execution means not just designing with modularity, but leaving clear instructions. I left annotations throughout the deliverable to assist engineers in execution. The metric of success here is to have as few questions as possible after delivery. Where necessary, I mocked up animations to demo behavior.

Edge Case Examples:

  • Notes in the "Beneficiary" section cover an edge case in which a user indicates their relationship with the beneficiary is "Other".

  • Instructions in an early form of the "Wait Time" section cover flows that include unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Beneficiary Edge Case

Accounts for an edge case in which a user indicates their relationship with the beneficiary is "Other".

Early Wait-Time Masking

The screenshot above displays in an early form of the "Wait Time" section. It details a flow to account for unreasonably long wait times, in which we would send an email when the user had received an approval decision.

Final Outcome

Final Outcome

My designs helped launch the first 100% digital IUL insurance application. The final interface operated as an autonomous system, using our parter's API guide to ensure it could parse and display any conceivable underwriting question. This allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

My designs helped launch the first 100% digital IUL insurance application. The final interface operated as an autonomous system, using our parter's API guide to ensure it could parse and display any conceivable underwriting question. This allowed Amplify to become an insurance carrier, and to launch its new product, "Prosper IUL". It was approved by the legal departments of all corporate partners, and government regulators in all 50 states.

Yahoo Finance

An article from Yahoo Finance announcing the new product.

Global FIntech

An article from Global Fintech announcing the new product.

PR Newswire

An article from PR Newswire announcing the new product.

Future Opportunities

Future Opportunities

Different Policy Types

Having built the infrastructure for one policy type, it would be much easier to add new products, including Term, VUL, and Combination policies. In fact, I created designs for these early on, anticipating that we would expand the product line one day.

Having built the infrastructure for one policy type, it would be much easier to add new products, including Term, VUL, and Combination policies. In fact, I created designs for these early on, anticipating that we would expand the product line one day.

© 2026 Devon Latzen

Portfolio

Flagship Insurance Application
Sales Admin Portal
Consumer Debt Dashboard
Life Insurance Calculator
Partner Referral System

BOnus material

Photography
Calligraphy
© 2026 Devon Latzen

Portfolio

Flagship Insurance Application
Sales Admin Portal
Consumer Debt Dashboard
Life Insurance Calculator
Partner Referral System

BOnus material

Photography
Calligraphy
© 2026 Devon Latzen

Portfolio

Flagship Insurance Application

Sales Admin Portal

Consumer Debt Dashboard

Life Insurance Calculator

Partner Referral System

BOnus material

Photography

Calligraphy