Taking a Loan From Life Insurance
A time-saving workflow for insurance servicing web app
About LifetimeSERVICE
LifetimeSERVICE is a comprehensive digital self-service web app designed for life insurance policyholders. It provides an all-in-one platform to view policy information, update personal details, modify policies, make payments, and more.
The problem
One of the common requests that policyholders initiate is a loan or withdrawal from life insurance, and sometimes surrender. In this project, our goal was to design a workflow to assist policyholders in obtaining a loan from their policy online, thereby avoiding the need for paper forms and office visits.
My Role
Product designer
(Worked through the entire design process and artifacts of this project.)
Design strategist
Product manager (PM)
1 month (2021)
Design Process
1. Research
Understanding insurance loan, withdrawal and surrender
To understand the issues faced by users, identify their needs, and streamline the servicing process, I started by learning how loans, withdrawals, and surrenders function in life insurance, as well as the processes and use cases of submitting these requests. I conducted secondary research to familiarize myself with relevant terms and definitions and had in-depth sessions with our subject matter expert (SME) at Sureify.
Understanding users
Pain point 1: The traditional way of taking a loan or getting withdrawal from a policy is daunting and time consuming, often stretching over a month. Shifting the entire process online, rather than relying on agent calls, waiting for paper forms, and mailing files, offers a significant time-saving advantage.
Pain point 2: We also went through a loan request paper form together to figure out how to transfer it to an easy online experience. For a lot of people, the forms can be confusing and hard to process with insurance terms and rules everywhere.
2. Problem solving
How might we create a digital experience that shortens the processing time for taking a loan and makes the process easy to understand for policyholders?
Information architecture
Collaborated with our design strategist, we mapped out the information architecture and the flow using loan request forms from various carriers and life insurance types. We then determined the scope of digitization for our product. This mapped worked as a checklist guided me through sketching low-fi drafts, ensuring all fields and requirements are covered.

Decisions on scope:
• As we wanted to get the most basic flow right first, the flow would work only for the basic types of whole life & universal life insurance policies. Annuity is not included either.
• We decided to not include Surrender for now, as terminating a policy could pose a potential loss for insurance companies, thus deserved a different treatment.
Deconstruct the paper form
Collaborating with our SME, we pinpointed confusing elements on the paper form and discussed solutions for enhancing the digital process. Our focus was on creating a self-explanatory experience, and offering assistance for policyholders encountering difficulties.
3. Design & Iterations
Interaction design
The goal in designing the workflow was not to replicate the paper form exactly but to adjust and simplify each step, ensuring an easy process for users. Leveraging our database capabilities, certain fields can be pre-filled or removed as we already have that information on record, significantly reducing the time required for users to complete the form.

Drawing on my understanding gained from prior insights into insurance and use cases, as well as the information architecture, I developed the initial version of the LoFi wireframes and sought functionality input from our SME and design insights from our design strategist. I then refined the wireframes based on their valuable feedback.
Component-driven HiFi design
In a life insurance policy, policyholders can initiate various common servicing actions, also known as transactions, including legal name changes and beneficiary edits. To maintain UI consistency across all transactions, we developed a workflow model with reusable components. Applying this model, I adapted the components for the loan and withdrawal use case in this particular flow.

(See final designs for taking a loan below. Withdrawal process is the same with change of wording, hence not showing here.)
Entry point:
• Because the interest rate changes from policy to policy, the loan flow has to start under the specific policy page. The entry point starts under All Actions (page to be designed).
• Each time the user can only request a loan from one policy.
• When user’s policy does not have enough cash value, they cannot take a loan from the policy. In this case the Loan tile will be disabled.
Loan request:
• Users need to enter loan amount, tax withholding, and review the summary.
• Users can go back to a previous step to make changes, while the progress of their current step is saved.
Delivery of payment:
• Users have two options for payment - direct deposit or a check mailed to their addresses.
Confirm and sign:
• Users can review their policy information, loan request summary, and the payment delivery method they chose. They can make changes to any of these sections.
• After e-signing the loan request, depending on the policy, the request could be instantly approved, or take 48 hours to process. If it is approved, we offer user a redirection to set up loan repayment under Billing & Payments tab of the app.
Agent support:
• Ensuring agent access throughout allows for a) user support at any step, and b) timely notification to agents of changes from their clients, enabling the opportunity to proactively maintain the policy in force.
• Currently this function is not included in final design because it could be a platform-wide solution that we will explore in the future.
Reflections & Next Steps
• Designing a flow, such as taking a loan, requires a clear understanding of the industry and related information. Research and collaboration with SME can be invaluable for clarifying industry knowledge.
• Mapping out information architecture is essential for organizing and visualizing the scope and requirements of a feature I’m creating. It also helps to remove distractions of unrelated information.
• When making designs, simplify, then simplify again. Having the user focus on one task at a time can make a complex flow easier to process.
Next steps
• The current flow is for “submitting a loan request”, future designs should include pending or loan/withdrawal active status display.
• Loan repayment flow with entry point under Billing & Payments.