Sureify Service Redesign
Building a stand-alone application for servicing policies.
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 developing the product vision for the standalone version of the LifetimeService Application. 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
LifetimeService encompasses a comprehensive suite of self-service features, allowing policyholders to review and modify their life insurance policy information.
Collection of updated service screens across multiple devices.
Project Details
Problem
Historically, service transactions rely on agents and paper forms, leading to significant problems in efficiency and user experience. As experts in risk management, carriers are often ill-suited to build software, which requires an iterative process. For this reason, carriers rely on third-party software to address the needs of a growing, technically savvy base of customers.
Objective
To revamp our existing self-service functions within LifetimeEngage into a white-label standalone application, with the aim of expanding product offerings and streamlining service transactions for carriers and policyholders.
Overview
Background
Sureify's initial offering was an engagement app (LifetimeEngage) that amalgamated educational resources, gamified health tracking, and facilitated interaction between carriers and policyholders.
Sureify's policy servicing functionality (LifetimeService) was born out of a need to allow policyholders to view and modify information digitally. However, a lack of APIs into the carrier's book of buisness at the launch of this functionality meant that we had to scale back our initial goals.
The first implementation of service features within LifetimeEngage sought to minimize complexity. In particular, a dedicated subsection with read-only policy data helped to streamline user experience by consolidating policy data and insurance education. But as our team integrated into the carrier's core systems and the display of data expanded, the team saw a need for even more restructuring.
Initiation
Life insurance carriers were delighted by the opportunity to engage directly with policyholders, but not all carriers desires took the same shape. Larger insurance partners wanted gamified health tracking and insurance education features; smaller carriers expressed an interest in a standalone servicing product.
The pandemic presented a unique opportunity for LifetimeService. Grappling with high demand, driven in no small part by social distancing, carriers required a clearer focus on the digital management of policies. This requirement forced us to reexamine our service product and its development.
To that end, I spearheaded a tactical project to revamp the service section of the application. The aim was to create a standalone application that could run separately or in conjunction with our engagement application.
Discovery
Process diagram to present to stakeholders how we would approach fleshing out a perspective for the standalone service functionality.
Establishing a Feature Matrix
My primary objective was to understand customer needs, benchmark them against industry standards in servicing policies, and use our team's insights and skills to create a comprehensive product. Collaborating closely with our CEO and a dedicated product manager, my team crafted a feature matrix of functionalities that could be incorporated into LifetimeService. This approach gave us an overview of specific features and their development status at any time.
Research Initiative
I enlisted the collaboration of two designers, Ruping and Patrick, to research competing interfaces and products. Together, the three of us identified products for review, examined user experiences across various policyholder UIs, and completed a comprehensive assessment in alignment with our feature matrix.
Our product had a number of expected functions, but it also had flaws. At best, it offered 1/4 of the functionality of a fully fledged servicing product, having roughly 12 of the 60 key transactions that our system needed.
Distilling Research into Patterns
We first compiled screenshots from each product under review and extracted their prevalent patterns. This helped to ascertain industry standards for different functionalities. It also grounded our assumptions about how to structure workflows for a policyholder and displays of policy information. A clear benefit was that we could now detect deviation between industry-specific patterns and UX norms, helping us to align with, or to challenge, prevailing standards.
Definition
Audience
Prioritizing Workload
Armed with this research, we conducted expert interviews. These validated hypotheses pertaining to how we handled user access while discounting others, such as our initial vision for document management. A straightforward scoring system gave us insight into how to balance complexity versus time-to-build and priorities for our workload.
Our research informed two key takeaways: clarity of the functionality we needed to build, and a push standardize our design language across all our products.
Design
Concept UI to Elicit Feedback
Having established our priorities, Ruping and I created low-fidelity designs of the servicing features. We refined the designs and our understanding of how the carrier systems operate through multiple review cycles with subject matter experts.
Modularity
Our team focused on the modularity of how we stitched together the required components within our designs, in order to account for varying needs of carriers and their policyholders. Enabling a custom built experience to be assembled from a variety of content, section or workflow combinations to reduce engineering effort per implementation.
Highlights
Document Center
A place for policyholders to access policy documents, standard insurance forms, and track both uploaded and carrier-delivered documents.
Policy display
Our goal was to enhance the organization of information, making it clearer and more contemporary. We chose to incorporate more visual elements such as graphs and charts to present policy data. We updated the UI to maintain a consistent styling throughout all our products.
Transactions
In rolling out an updated LifetimeService to our existing customers, we discovered that each carrier had unique transaction needs based on user type and context. We needed a dynamic model that could adapt to these differences.
Patrick and I undertook a comprehensive analysis of agent and policyholder servicing flows with the help of our CTO, Ben. This quickly identified areas of overlap and divergence. Through iterative whiteboard sessions, we developed a foundational transaction model, which we dubbed "Journeys."
Journeys were not monolithic entities. Their structure, composed of modular sections, needed to be flexible and adapt to the unique context of each policyholder, state, policy type, date, and a multitude of other variables. This was made possible by utilizing a ‘block’ model to create complex workflows from simpler ones so that we could reuse components to customize or develop new or complex flows much faster than before.
Our outreach revealed further nuance. Carriers wanted to weave multiple transactions into unified Journeys, eliminating the need for form submission between steps.
Impact
Standalone Service Application Developed
By establishing a feature matrix complete with design assets, the product team established a backlog of features to build. Our team of engineers initiated the development of this standalone version of the service application. This not only laid the groundwork for a functional product but allowed our sales teams to offer carriers a 'sneak peek' into our upcoming product development.
The ability for our sales teams to present a carefully considered, strategic vision for our servicing product proved instrumental in securing several carrier design partnerships, showcasing the tangible progress and potential of our evolving service offering. It also reduced the time it took our professional services teams to gather requirements from customers. Most servicing functionality was in place, giving our teams the ability to determine each carrier’s requirements and tailor our response to them from the outset.
Using a modular approach and component-driven design, we were able to build the first pass from ideation to a stable build in less than twelve months. LifetimeService was successful and quickly eclipsed the original product, LifetimeEngage. The number of carriers who were using Sureify’s products increased over 300%, greatly aided by the improvements to our implementations of LifetimeService.
Reflections
Although we have established a standard set of features, many carriers still require custom adjustments for their unique flows. Minor adjustments are necessary for each carrier, and we must also track design pattern variances between policyholder and agent users. As we move forward, we will reorganize our files and continuously evaluate our servicing flows. By using a "user agnostic" styling for our service flows and housing designs, we can ensure smooth access to our LifetimeService and LifetimeAgent products as part of a shared team.
