Pinnacol Assurance – 2019-2021

Building and scaling a design system from startup to enterprise

Overview

I saw a need for a design system in early 2019 at Cake Insure when our design speed and consistency struggled to keep pace with our product and engineering partners.

Below is the story of how I advocated for, and helped coordinate, the development and maintain of a cohesive design system at Cake Insure and then helped scale it for enterprise use at Pinnacol Assurance (Pinnacol acquired Cake in late 2020).

I want to skip to the Design System Figma File

Part 1: The lay of the land

I was the second product design hire when I joined Cake Insure in the summer of 2019, a mid-stage startup with great promise (and serious growing pains).

Up until then, the team had been moving at breakneck speed to demonstrate product-market fit in the burgeoning insure-tech market. The startup had created an innovative, no-touch, flow-based onboarding process coupled with self-service portals—a first for Workers’ Compensation insurance (a product and service historically agent-based, letter-based, morse-code based, etc.).

Once the fundamental business model was validated, the focus shifted. A lot. Our parent company, Pinnacol Assurance, took note of our early success and came knocking at our door for our expertise and time, including an ask to support their core-system replacement to Salesforce.

Meanwhile, we at Cake had an identity crisis. Backed by an impatient benefactor, and with hardly the revenue to match payroll, were we a fast-scaling startup or a temporary innovation lab for Pinnacol?

Part 2: Building trust

As much as I wanted to dive right into design debt austerity reforms, the first order of business was to meet my product and business stakeholders where they were at to build trust and demonstrate my own reliability.

From their perspective, the top priority was to get the designs out the door that had been languishing in the backlog and holding up development cycles prior to my arrival. I put my agency hat on from previous roles and got to work producing designs and making a point to provide clear visibility into my process and progress (view the outcome of this work here).

Part 3: The political campaign

Breathe. The first test of my mettle was behind me, and I was eager to spend my newly earned relational capital on buy-in for a design system that would support the consistency and growth of our disparate 10+ apps.

Josh, one of our senior developers, and Jules, our lead designer, understood the need and were immediately on board with my proposal. We began a series of conversations that would outline the time, effort, and stakeholder buy-in needed.

In addition to 1:1 conversations, I presented a slide deck and demo during our All Hands meeting explaining what a design system was and how it enables design teams, and organizations generally, to build and update products at a significantly faster rate without sacrificing quality. “By using a central library of components and styles that directly reflect the developers’ React repository, we’re able to design, build, and maintain as many Lego cities as we can imagine without buying all new Lego sets every time…”

With the right stakeholders invested, the design and dev teams lockstep, and the product teams busy implementing a raft of new designs, we were off to the races to fulfill a big promise.

Part 4: The full tax audit

The design language of Cake was initially born from the ideation of design consultants at Deloitte Digital. But once Cake graduated from Deloitte, and hired its first designer, the design language quickly stretched and strained well beyond the original intent in order to accommodate what had become 10+ apps by the time I arrived onto the scene.

For the next week or so Josh, Jules, and myself went line by line in every app, auditing every color, font, input, layout, component, pixel, and so on. We put all the variables into a google spreadsheet to get a birds eye view of the digital suburban sprawl (viewable here).

Part 5: Keep it simple

We ripped out the redundancies and highlighted one-off components that needed to be re-designed for consistency. After many discussions, we aligned on a brand new, end-to-end design system, built with accessibility in mind, white label theme-ing (a C-Suite desire), and, most importantly, the flexibility to accommodate future needs not yet known to us (for example, 10 shades of each system color when we were only using a a few of each at the time–see screenshots below).

Part 6: Brass tacks

We had championed, audited, and aligned; now we had to build, rebuild, and rebuild some more. Not only did we need to create a design library within our design ecosystem, but Josh also had his hands full updating all the styles and components in the React repository in Storybook. This would be an ongoing process, but on the design side we were able to complete our library within a couple weeks (though rebuilding all of the design files with the new library would take several months).

Fast forward to January of 2020 with the fundamentals in place, ‘Alexandria’, as it came to be known, was increasingly noticed and appreciated by various stakeholders. Josh would later tell me that he and Lonnie, the front-end lead at the time, had estimated that “Front end dev work was reduced by at least 40% and possibly up to 60”. (Note: Josh is available as a reference.)

Part 7: To the enterprise moon

Of greater consequence in January 2020, Pinnacol leadership decided to re-integrate the Cake team back into the Pinnacol parent company to focus efforts almost entirely on core system replacement. For the design system, this meant scaling to accommodate the new front end for agent portal, injured worker portal, healthcare provider portal, legal portal, and all flow-based apps. Luckily, this sort of scaling was exactly what Alexandria had been designed to accommodate all along.

Part 8: Learning and legacy

I learned so much from this experience. Most importantly, I learned that a sincere commitment to building and maintaining a design system can reap enormous long-term efficiency and consistency gains that have a meaningful impact for users.

Right before I left Pinnacol, we managed to successfully advocate for turning Alexandria from a side project to a full blown internal product with its own dedicated developer and product owner. I hope it will continute to scale and grow and provide value to Pinnacol in ways that we never even imagined at Cake in the summer of 2019.