Taking a Loan From Life Insurance
A time-saving workflow for insurance servicing web app
Overview
Sureify is developing a white label all-in-one web app for life insurance policyholders, allowing them to seamlessly view and manage their policies. In this project, our goal was to design a workflow to assist policyholders in taking a loan from their policy online, thereby simplifying the process and avoiding the need for paper forms and office visits.
My Role
Product designer
(Worked through the entire design process and artifacts of this project.)
Team
Design strategist
Product manager (PM)
Duration
1 month (2021)
Design Process
Research
Understanding industry knowledge
To understand the use cases,  I conducted in-depth sessions with our subject matter expert (SME) at Sureify, learning how loans, withdrawals, and surrenders function in life insurance, as well as the processes of submitting these requests.
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.

Pain point 2: For a lot of people, the loan request form can be confusing and hard to process with insurance jargons and tax complications everywhere.
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?
Deconstruct the paper form
Collaborating with our SME, we examined the paper form policyholders have to fill out for taking a loan and explored ways to translate that into a digital user flow. I explored solutions and decided to break down the complex flow into small steps for users to deal with one at a time. We also pinpointed confusing elements on the paper form from user’s perspective and discussed solutions for enhancing the digital process. Our focus was on creating a self-explanatory experience, and offering assistance for policyholders encountering difficulties.
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. This map 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 only work for the basic types of life insurance policies.
• We decided to not include the Surrender action for now, as terminating a policy could pose a potential loss for insurance companies, thus deserved a different treatment.
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 back-end 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 previous research, I designed versions of LoFi wireframes and sought functionality and design feedback from our and design strategist, then made iterations.
Component-driven HiFi design
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.
In a life insurance policy, policyholders can initiate various actions, also known as transactions, such as changing an address or making a payment.
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).
• 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 have a final review of the request.
• The progress of a user’s current step is saved if the user goes to a previous step for edits.
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 input and edit any of previous steps.
• 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 the flow 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 active policies.
• 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
Reflections
• 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.
Want to check out more projects?