
Revitalizing Policy Management
Rapid iteration on a legacy product and a reimagined workflow for schedules and coverages to lead the direction in a major rebrand.
Breathing New Life Into a Legacy Product
In July 2025, Veruna, a leading insurance agency management application built on Salesforce, reached out to me with a redesign project due to my previous experience with the platform. The project would have a rapid turnaround time of one week and was intended to help guide the direction of a major rebrand Veruna was in the process of undergoing.
The initial ask for this project was to build an updated view of their Policy page using the newly improved Salesforce Lightning Design System 2 (SLDS 2), but as the redesign effort progressed it became apparent that the old workflow for schedules and coverages was a serious pain point for users who accessed the Policy page.
I was ultimately tasked with two major deliverables; a mockup of the new and improved Policy Page using SLDS 2 and a blue sky exploration of a new workflow for Schedules and Coverages. The final result would help guide Veruna’s leadership on the next steps of their rebrand.
Desired Outcome
Veruna’s leadership team intended to use my design exploration to aid in decision making regarding their company’s efforts towards a major rebrand. The final deliverable would be a detailed mockup of a future vision for Veruna’s flagship product, the Policy page.
The project was also meant to explore user experience design as a potential option for Veruna’s Product department. It was imperative that I archive and explain my design process to the team in great detail to help development better understand the decisions I made.
Challenges
Tight Deadline
The turnaround time for the project was only one week. In that amount of time I needed to complete competitor analysis, research customer needs, analyze the product in its current state, and design well thought out wireframes and mockups.
No Research
Due to the time crunch I wouldn’t be able to conduct any of my own user research; I needed to make design decisions informed by available customer feedback and my own experience working in B2B software development.
Lack of Patterns
Veruna’s products had never been developed with design in mind before. The entire application had been built piecemeal, so there wasn’t much of a through line regarding patterns or workflows to work with.
Taking the First Steps
The first step I needed to take was to analyze the product in its current state, taking note of all available features, functionality, actions, and workflows.
I also needed to gather any user insights Veruna had readily available. I reached out to Product for any documentation or recordings from previous user interviews since I wasn’t able to conduct research of my own.
Finally, I needed to complete competitor analysis on more mature, industry-standard products to better understand the current trends and see what we could improve upon in our experience.
Analysis; Policy Page
The Policy page had a pretty standard layout for a Salesforce object. It was also highly customizable, and customers made heavy use of its modular capabilities.
Users could customize their Policy pages with widgets that were better catered to their workflows. I would need to account for customization.
The majority of the page body was wasted by a large read-only form. Most of the information displayed was rarely relevant to the user, and most of the fields were not editable despite the edit pencil icons present in each field.
Pivoting to Schedules & Coverages
As I dug deeper into analyzing the Policy page and previous user feedback, it became apparent that a major upgrade to the workflow for Schedules & Coverages was necessary
Schedules are the pieces of property that are being insured by the policy. Coverages are the liabilities property is insured against. They are directly related and insurance agents need to be able to view them together.
The real-life workflow for insurance agents was not reflected in Veruna’s experience. Instead of allowing users to view Schedules and their Coverages side by side, they were forced to enter separate pages for each object.
I was tasked with doing a blue sky exploration of a new approach to the Schedules & Coverages workflow, immediately accessible from the main Policy Page.
Analysis; Schedules
Schedules referred to the insured property. Lists of schedules could often extend into the hundreds.
The existing pattern for Schedules was a data table housed in a filtered tab view. Each category of schedule was a tab, and each tab had individual data tables.
Every Schedule linked to its own object page in the data model. A major problem with Schedules was their lack of visibility into the Coverages associated with them.
Analysis; Coverages
Coverages are the liabilities property is insured against. Each Coverage is associated with a Schedule.
Coverages had an even more confusing experience. Filtered tabs, nested accordion sections, and a complete lack of visibility into the Schedules each Coverage was associated with.
Each accordion section opened into several more accordion sections, making it very difficult for a user to locate what they need.
Competitor Analysis; Progressive Policy Page
I was able to gain access to a view of Progressive’s insurance agent experience through the user interview archive.
Progressive’s experience was significantly cleaner and easier to follow, but I found a lot of room for improvement. All of the slick white space meant that the dense policy information extended far down the page and forced the user to scroll for a while to get to the bottom.
Competitor Analysis; Progressive Schedules & Coverages
Progressive’s Schedules and Coverages experience was a bit of an improvement in that they were both visible together. However, they were still shown separately, without a direct association between them.
I was interested in the simplicity of both the expandable card and list views and made a note to experiment with those concepts in my own workflow.
Ideation
I began by designing a bit too closely to the data model, trying to get a feel for how much we wanted to deviate from the Salesforce experience.
Wireframes; Policy Page, First Pass
I knew I would need to spend most of the project timeline ideating layout concepts so I jumped right in and started putting together some new ideas for the Policy page.
I used the initial pass as a touchpoint to get some early feedback from PM on the direction we wanted to head in.
Solution Proposal
Working together closely with my PM and engineering, we decided on workflows for the three major use cases; enabling a feature, implementing available updates, and accessing feature pages.
The experience would consist of the main Feature Management hub page with individual offshoot pages for each feature. Most of the major actions would only be accessible through the Feature Pages due to technical limitations.
The new Available Updates and Activity Log functionality would live in tabs alongside the main feature list for easy access.
An easy design decision was to truncate the Policy Details section, showing only the most relevant information on the Policy page and allowing the user a more detailed view from an overlay. This immediately opened up a lot of space.
Wireframes; Policy Page, Second Pass
As I continued ideating on the Policy page, the overall direction of the project began to shift. Schedules and Coverages became a major focus of the project, I needed to explore ways to add that workflow to the main Policy page.
For a modal I could have used a stepper workflow for adding Schedules or Coverages, but it still lacked the side-by-side view.
The overlay concept was too simple for the necessary information architecture.
I also attempted to build a Schedules and Coverages workspace using the Salesforce drawer component. The drawer component is sticky in the footer and would allow the user to access Schedules and Coverages for any policy throughout the application.
This wasn’t quite right either, though I used a similar layout for the final solution.
Wireframes; Schedules & Coverages
My first explorations for Schedules and Coverages made use of overlays and modals to try and save space on the main Policy page.
The workspace was still designed too closely to the data model, and didn’t offer the desired combined view.
Illuminating the Path Forward
Using SLDS 2 components, I built an updated and more modern approach to Veruna’s Policy page to present to the leadership team.
I also drew up final wireframes for my combined Schedules and Coverages workflow concept, guiding the user through multiple view modes based on the density of information they were working with and simplifying the filter options.
Policy Page Mockup
I audited the page level actions and decided on these three with Product. All the other page actions were irrelevant.
Forms and Activities were the most heavily accessed features of the Policy page, and needed primary real estate on the main page.
A space just below the fold was assigned for various widgets to accommodate users’ customizations.
Schedules & Coverages Final Wireframes
I ended up keeping Schedules & Coverages in its own tab on the Policy page due to the density of information.
Toggle between the card and list views for available schedules depending on the density of the table.
Simplified filtering centers the Schedules, considering the relative association between them and Coverages.
I changed the Add New Schedule workflow to a modal with a stepper, also allowing a user to add Coverages directly to Schedules in the process.
Impact
Veruna is currently still in the process of their rebrand, and it will be a while before their products reach full design maturity. I believe they’re off to a great start by allowing themselves to open their product to blue sky design possibilities.
This was my first contract job as a product designer after a 7-year career working as a staff designer on full design teams. I learned a lot about leading a design project start to finish and became more confident in my process and design decisions.
Working with Veruna was an inspiring experience for me, it was heartening to work with a group of people who took their product so seriously and wanted to improve their customers’ experience out of a desire to deliver quality.