Saving $1.5M/year with insurance pricing tools for actuaries

I architected and established the design direction for an internal tool that would replace several tools that actuaries cobbled together and relied on every week.

The challenge

Root Insurance was losing $1.5M/year in revenue because of a slow, inefficient process for changing insurance prices.

I joined the Payments team during my second year at Root Insurance. Our goal was to improve retention rates and our starting point was an unprioritized backlog of ideas around payment flexibility.

Insurance Pricing 101

The price you see from an auto insurance company is calculated from a formula. That formula is made from hundreds of factors such as your age, your accident history, and how many drivers are on your policy.

To create price changes, actuaries update those formulas by rebalancing, adding, and removing factors.

Understanding actuaries' process challenges

Mark, my Product Manager, already knew from working with Root’s actuaries that they often used and struggled with tools traditionally used by software engineers.

With the help of our UX Research partner, we interviewed five actuaries to validate, rank, and better understand their challenges. They shared their screens and showed us how they navigated Github, Amazon S3, and the occasional command line.

Sharing our opportunities

After mapping the technical process in detail, we condensed our insights and opportunities into a journey map.

The vision: a self-service web app for Actuaries

We estimated that Actuaries would finish projects 5 days faster if they were freed from having to rely on engineers and an engineering-oriented toolchain.

Building a web app would help Actuaries test pricing changes faster and also create an auditable reference for all of Root's pricing formulas.

Object-first design

I started our design process by working with Mark to map the new app's objects, their relationships, and their data properties.

That map-in all four of its iterations-helped us formalize new language as we shared ideas with the team.

As we iterated on our object model, I engaged our Staff Engineers in conversations about data types and validation. Working as a developer in a past life helped me speak their language.

Sitemaps before screens

Once we refined the core objects, I began to build and iterate the new app’s sitemap.

Working at this fidelity encouraged the team focus on information architecture. We iterated quickly by saving discussions about layout and interaction design until we were only making minor edits to the app structure.

Tackling the biggest source of delays

We saw in our research that actuaries had to run a tedious process to test pricing formula changes, which often happens dozens of times in each project.

1. Convert a CSV file into an Excel spreadsheet
2. Edit the spreadsheet
3. Convert the spreadsheet back into a CSV, using command line scripts
4. Commit their changes to git
5. Wait a success/failure message in Slack
6. Navigate Amazon S3 to find results, or to begin debugging a workflow error

The process was not just tedious but also unforgiving. A single typo or formatting error would create a workflow error that, more often than not, would require an engineer's help to debug.

We reimagined the actuary’s experience as a web UI that took care of version control for them while catching errors early.

Eliminating wasteful dataset generation

Actuaries’ second biggest delay involved wasteful dataset generation, which cost them 30 to 40 minutes each every time they ran a workflow to test pricing changes.

I sketched a concept that let actuaries generate datasets only as needed—usually two or three times during the entire project—and allowing them to reuse datasets to reduce their formula test time by 2 days per project.

Pivoting away before high-fidelity designs

Our project ended when the company deprioritized the entire Pricing Tooling roadmap, refocusing teams to fees and verifications for short-term revenue.

At that point we had sketched and gotten positive feedback on a complete MVP for a self-service web app, which had features including progress indicators and a review system.

The value of showing incomplete ideas

Despite the project’s early end, I learned a valuable approach to avoid getting stuck when designing for complex domains.

Sketches aren’t just for turning abstract ideas into artifacts you can discuss—they help you build your domain understanding, one chunk at a time.

It felt unnerving at first, but once I learned to share incomplete sketches with my teammates, the project progressed more smoothly despite the complex subject matter.