LifetimeAcquire Revamp
Fine tuning the Direct-to-Consumer purchasing experience.
Sureify
Sureify's mission is to modernize the life insurance industry by helping companies service, engage, and sell to their customers with our enterprise product suite.
As Staff Product Designer at Sureify, I led design for several important projects, including the direct-to-consumer quote and application product. During my time there, the company grew from 30 to 300 employees, the design team grew from 1 to 10 designers, and revenue increased from under 100k to over 15m.
LifetimeService
LifetimeAcquire is a configurable electronic insurance application allowing carriers to sell insurance products to consumers without an intermediary agent.
Mobile screens of the revamped quote and application.
Project Details
Problem
Two years after launch, flaws began to emerge in our LifetimeAcquire product. The application was limited in how it rendered questions on the front end, the application only being mapped to a single type of policy. There were also weak avenues for customization, higher-than-expected call center support, and unacceptable drop-off rates.
Objective
Increase conversion rates and enhance the user experience of our product based on usage data. We wanted to showcase the identity of carriers with more white-label branding options.
Overview
Background
In 2018, my colleague Jacob and I were tasked with creating an intuitive online quote engine for life insurance. The quote engine would gather personal information, recommend products, and pre-fill segments of an insurance application.
According to industry reports 74% of Life Insurance applicants wish to purchase a policy online. In conversations with carriers using our quote engine, we realized that many of them lacked an online Direct-to-Consumer application. This put them at a disadvantage compared to emerging startups which were able to forego traditional costly underwriting processes for certain types of policies.
Expanding on our quote engine, we found inspiration in tax preparation software for configuring question structures. We then created the first iteration of LifetimeAcquire, a life insurance application that uses two types of questions: basic and reflexive. To handle the potentially limitless follow-up questions of the latter, we developed a model capable of managing them.
Our initial release with 4 carriers generated over $5 million in billing. But the product had flaws which compromised it’s effectiveness, leading to incomplete submissions and higher call center support.
Initiation
With these issues in hand, our team was assigned a development squad, but with strict constraints. We were limited to only 2 weeks to resolve the problems and a maximum headcount of 12 developers. Nor could we make any significant changes to the backend or alter the structure of the product beyond the frontend.
To begin, we analyzed data gathered over the past 2 years across implementations of LifetimeAcquire. We discovered that approximately 70% of all users were accessing the forms through their mobile devices. Our initial assumption regarding "form fatigue" was confirmed when drop-off rates for longer applications reached as high as 53%. Armed with this valuable data, we set to work on improving our product.
Discovery
Application Complexity
Our first impression was that, for shorter applications, carriers preferred a question-by-question approach. But longer and more complex applications needed a more tailored solution. To address this, we decided to modify the original designs, giving carriers more control over the structure of each section. An added benefit was that this aligned with the industry's established pattern of applications. We also resolved to enhance the visual presentation of basic and reflexive questions within these sections. This would reduce the number of screens shown to users and improve our ability to estimate the percentage of completion. We then aimed to strengthen the mobile experience in areas with limited connectivity. This could done by prioritizing data and segmenting forms accordingly.
Original designs of the single-page acquire product.
This was a previous pass which showcased a split after the first encountered reflexive question and not the single-question per-page version of the application that was built.
Definition
Audience
Policyholders
Contemporary users expect online tools to manage much of their lives. Yet not all users are alike. Applicants can range from 21 to 85 years old, with differing levels of needed support. Many users might have visual or physical impairments or be largely unfamiliar with life insurance.
Carriers
Life insurance carriers have been slow to adapt to digital transformations. They lack the required expertise or internal structure to build out software teams to address changing market conditions.
Agents / Call Center Representatives
Agents can be a significant part of a customer's experience or play a minor role in purchasing a policy, depending on the product and avenue of purchase. Call Center Representatives, who may also be licensed agents, can assist with product selection, application support, and complex underwriting cases.
Underwriters
Underwriters evaluate policy risk and should be considered as part of the carrier user group. Although they may not use the application directly, they benefit from behavior data, such as when applicants modify their answers to adjust their premium or acceptance.
Earliest sketches of my ideas for the product revamp.We used half sheets of paper and sharpies to avoid getting too precious with the rough concepts.
Design
Updating Sections
To improve user experience of the application, we updated sections and questions. This was critical, for it showed drop-off rates and how efficiently applicants made it through the application.
A significant improvement was in cutting the number of pages. In the old version, excessive length made it difficult for users to navigate the application, and clearly understand how much of the application remained to be completed. With the new design, we streamlined the process by displaying each section as a single page as opposed to showing a single question per page refresh.
We explored possible variations of the application, considering different ways to structure the information and present it to applicants. We narrowed the options to identify the design that was structurally flexible and robust enough to support a variety of white labeling approaches. To test the strength and flexibility of the designs, Vivek applied fictitious branding to the application. This helped us understand how the designs would render with different branding elements and identified any areas where the design needed further refinement.
Improve Reflexive Question Rendering
Reflexive questions present unique challenges in navigating and interacting with the application. From a wayfinding perspective, applicants need to understand visually the relationship between questions. From a backend perspective we needed to keep track of previous answers for underwriting purposes when a user made changes to manipulate the application.
In the initial model, a potentially reflexive question would result in a fresh set of child questions based on the corresponding parent answer. Questions loaded in until the system reached another potentially reflexive question. Such an approach loaded as many questions as possible before a page break, but, on consultation with engineering, we had to scale back to one question per page.
The first implementation of LifetimeAcquire took into account the nesting issues arising from a expansive tree list display and question dependencies. Among the possibilities was that child questions would have multiple parents and generate additional child questions. To simplify matters, we created a model where each child question was associated with only one parent. We used breadcrumbs to show the previous question's association.
To interface with the updates to the sections, we had to reconsider how reflexive questions would render in the page. Since we had broken the sections into pages, the reflexive child questions would need to shift the UI content dynamically based on a user’s response.
Vivek and I built two distinct sets of wireframes. One had a user submitting their answer to pull questions from the system; the other was automatically loaded in upon de-focus. Engineering informed us that all answers were at least initially tracked and submitted on click. This greatly simplified the UI.
With these changes, all questions spawned inline in the page but had a different color background with cards to show their grouping. The cards would then expand during loading of additional questions. In effect, this process amounted to two tiers of question hierarchy.
Component-Driven Design
Supporting robust white labeling was crucial in an industry where many insurance products function in almost exactly same way to the end user. Separating products comes down to the cost and terms of the insurance.
Adhering to a principle I advocated across our products, Vivek and I decided to rely on a component-driven design model, akin to the way react functions for developers. Once we had established a clear design direction for the changes to LifetimeAcquire in a wireframe stage, we built component-first and assembled our created components into functional pages and flows.
As a result, we were able to make rapid adjustments across the design of the application and spend more time with developers in addressing how the front end would function.
This approach proved invaluable both in saving time building out screens and in how quickly we could apply a brand for carrier review during the sales process. It paved the way for rolling out component-driven design processes across the department and laid the groundwork for our design system, SureUI.
Prototype
As I juggled multiple projects, Vivek developed a functional prototype. This allowed us to showcase our ideas to carrier design partners and provide a concrete representation of how the final product would operate. Through the prototype, we conducted a heuristic analysis with potential applicants. The prototype proved to be highly effective in our conversations with engineering teams. By having a tangible model, we facilitated their understanding of the design specifications and encouraged them to propose any necessary modifications.
Updated UI
The updates to the quote flow focused on breaking up the key segments of the quote into different steps that could accomodate supplemental data to help prospective customers make sense of the unique nature of each policy type and select a price point that worked well for them.
The updates to the web application helped to keep the important forms front and center and provided clear wayfnding and a more modern looking UI. Inline adjustments and editting was maintained in order to make corrections easier on an applicant.
Impact
After we finalized the design, our engineering teams took over to bring it to life. Together, we scrutinized the designs, ensuring that it met all the necessary specifications and requirements. One of the key steps in this process was to use data from one of our trusted design partners, AAA, to ensure that our product would work correctly and adhere to our team’s updated standard of quality.
Addressing the problems in the application lead to a large reduction in customer drop off prior to application submission. It also enabled Sureify to offer a varitey of experiences for carriers to select from based on the unique needs of their business and application structure.
