ABOUT
Delaware Life sells annuities in most U.S. states through agents (producers) who market and sell contracts. The company follows a B2B2C business model, deals with businesses, and works with many agencies or agents who receive commissions upon successfully selling the products. Selling a product involves several steps, including completing documentation, accepting payments, activating policies, and paying commissions to the agencies and agents.
TEAM
Product Designer: Shuchi Sharma | Product Analyst: Dawn Murphy | Scrum Master: Brian McQueen| Front End Developer: Brannon Darby, Hareesh Devulupali | Back End Developer: Noel Hahn, Raymond Pressly | Quality Assurance: Devin Bates
| ROLE | TIME |
|---|---|
| Research, Design Strategy, Product Design, Product Analytics | 4 months for initial MVP |
PROCESS
I apply the double diamond process for a design solution in the product design process.
Discover – understand the issue
Define – Define what we are going to solve
Develop – Work on the solution through ideation, wireframing, prototyping
Delivery – which is launching and monitoring
RESEARCH
DISCOVER
We did user research with the different departments to understand the process. Different meetings were held with the operations, and systems were analyzed. We discovered that Delaware Life had acquired businesses over a period of time. Different product applications are handled in different departments. There was no efficient way to track the contract activation from application received to activation. An annuity application could take 3 weeks to a month to process, going through different operation stages. It was difficult to track which department or what stage the application was in. Different departments handled different processes in different software. These led to the following problems:
- Escalated costs with reduced efficiency
- Miscommunication and processing delays
DEFINE
The business was interviewed to explain what worked well and what they wanted improvement on. Based on different discussions, these requirements were finalized.
1
A centralized system for the applications: All the applications should be tracked in one platform, and work should be done together on the application.
2
A software application for external users: Clients or agents should be able to track the application’s status and help resolve any issues.
3
Assist customer service agents: Provide accurate information on customer applications to enable the CSA to assist customers.
4
Communication capabilities between clients and internal application managers: The portal should have a chat portal to enable users to communicate between two user personas.
User Persona and Requirements
This was the summary of requirements for Agents / Agencies / Producers.
Agent / Agencies (Producers)
1
Agent eligibility: The agent has access to the information that they pass the qualification to sell the product
2
Application issues: Promptly be informed if the application needs additional documents and be able to communicate with the internal teams and resolve issues
3
Premium status: To know if payment or fund transfer on the applications was complete.
4
Contract activation: To know when the contract is active and document tracking of contract papers.
User Persona and design brief
DESIGN
At this stage, we had refined requirements. Now, we worked on the design. We tackled every requirement and looked for design solutions for the users. We designed wireframes and reviewed them. We revised designs, talked to operations and developers, and further refined designs.
DEVELOP
IDEATION
This stage was refining the ideas together.
The requirement was – A centralized system for the applications:
A central database with a search page was created where all applications can be viewed. Application stages were defined as the stages of the application case we had worked on. But we initially defined it as open, in progress, on hold, and canceled. Filters were added to search through the applications.
A software application for external users: Clients or agents should be able to track the application’s status and help resolve any issues.
We identified six main stages of the application and three states within the stage.
These were the six categories the application went through
- Can Sell
- Application
- Payment
- Policy Activation
- Commissions
- Post Activation
But the process was not linear. An application could become active before all the payments were received, or commissions could be paid in advance. It would be difficult to make a tracker that worked in a linear way.
To tackle this, we decided to have a layout with all the stage tiles on a page. Each tile would have a progress bar. If the producer/agent required some information, the tiles would have tasks for the producer to complete.
As we discussed further, we noticed that we needed a central status for the agents to see the application status. It did not indicate what the agent or client was required to do.
We removed the progress bars from each tile and decided to have an SLA bar on the top clearing indicating the status.
The other requirement was – Communication capabilities between clients and internal application managers:
For this, we added a task section with a chat, the ability to upload documents, and the ability to send messages. This would enable faster communication between the customer and clients.
REVIEW
The designs were shared with different departments—operations, marketing, and management—to get feedback on the applications.
We walked through the flows and planned how the user would move through the application. On further discussion, the tiles were reduced to 3 stages.
- Application (which would account for eligibility and documents)
- Payment (Tracking premium payments and transfers)
- Activation (Indication of application activation and document transfer)
the following two things were dropped.
Commissions dropped from MVP: After many discussions around different stages of applications and SLA, we decided not to include commission payments in the portal. The agencies had a different requirement, as they did not want the agents working in their business to disclose the information, which would require more time and complexity.
Agent eligibility combined with application verification: The next change was agent verification – which is a background check of the agent who brings in the application. This step works almost in parallel with the application verification. It was decided to combine the two steps – application and agent verification.
New designs were prepared, and we progressed to the next stage.
PROTOTYPE
User Flows
With this direction finalized, I worked on the user flows for the producer portal.
The status of contracts was refined further.
- Assigned – when tasks are assigned to the user.
- In-Progress – the contract is in progress
- Pending Review – Action has been taken by the agent, and the internal user needs to review
- Completed – the application process is completed
- Canceled – the application was canceled.
Service Level Agreement, or another word for Estimated Time of Arrival (ETA) for the application, was added to show when the application would reach the next step. We worked out SLA statuses and charted out different stages.
These are the summaries of SLA for different stages of the application.
Task Tiles were reduced to three stages.
- Application – that would track the agent background check, the application documents. Incase anything would be missing a task will get added on the tile. The status of the contract and tile would become assigned. That would help the user know they have an action item.
- Premium – This would track premiums payments and transfers. Tasks would get added in the tile for any missing information or document. The state of the application would change to assigned again. This would help producer know they have tasks.
- Contract Activation – this could be completed on first premium or last premium. Based on the application the step would be complete. A tracking number of mail would be added on the tile.
- Each tile would have five stages – In Progress, Assigned, Pending Review, Complete, and Cancelled.
MOCKUPS
I prepared mockups and added them on the the user flows showing the user journey of the user at different stages of the application.
TASK FLOWS
There were certain detailed tasks that had to be done on the pages. For that I prepared task flow. This task flow was created for communication.
FINAL REVIEW
After discussing the designs with business, marketing, and operations, we handed over the designs for development. We use Figma files in the project, and with the dev mode, it was easy to hand over the files to the Dev team.
DELIVER
Development
The development team worked on different areas of the project. As the project progressed, we reworked some designs based on technical challenges.
The video below shows the dev environment stage of the project.
Release Monitoring
We tracked the users on full story and observed how the users were interacting with the pages.
An average of 1200 users visited DOT, but only 300 users used the task section. This was quite a low number. It was discovered that many users were not able to identify which status to go for to look for the assigned task.
To resolve this a section on the dashboard landing page was created to provide links to assigned tasks. A message saying you have some assigned tasks. The number of visitors to the section increased. Past 30 days we have had 533 users on the pages. Increase by 53.2%.
The status chip design. We noticed in the session recordings that may users were clicking on the status chips. We read the heat maps and noticed the 3rd most clicked area on the page was the status chip. It was causing users frustration as there were no results.
Instead of redesigning the chips, we decided to have a hover information message on each chip, enabling the users to know the different stages of the status.
This project is ongoing, and we continue to make improvements as we progress further.