Logo
The Bankrate wordmark appears in dark, light, and blue versions for use across different backgrounds.
The B monogram keeps the identity recognizable in smaller digital spaces and can shift into simple motion, like the paper plane shown here.









Migrating an existing design system to Tailwind.
When I joined Bankrate, the design system consisted of two parts: the frontend used a custom utility framework called Classy, while designers used a Figma library called The Vault.
The goal was design-to-code parity so the same visual language carried across the site. For example, gray values had aliases such as gray, slate, mid-gray, and light gray, while other hues were identified only by hex. This was one of several inconsistencies that made it difficult to match what was defined in Figma with what was implemented in code.
There was a desire for a more unified system, and the migration had to work across several teams and thousands of existing pages without interrupting production.
We brought Classy and The Vault together in a single system called Treasury. The frontend would move from Classy to Tailwind, a more established utility framework, while a new Treasury library in Figma, built around the same configuration, would replace The Vault.
I rebuilt the design foundations in Figma to align with our Tailwind config. I expanded each hue into a 50 to 900 scale using a perceptually uniform color space, simplified the typography system, and consolidated the icon set by standardizing icon names and combining duplicates.
Classy and Treasury handled CSS differently. Classy loaded the full utility set, including styles a page did not use. Tailwind’s JIT engine generated only the utilities it found in the code. Reducing unused CSS was one reason for moving to Treasury.
The migration could not happen all at once because thousands of pages and custom experiences still depended on Classy. While both frameworks ran on the same page, we prefixed Treasury utilities where names overlapped to prevent collisions. We also used tailwind-merge to resolve conflicting utilities when class strings were combined.
I created design mappings that identified deprecated colors and their Treasury replacements. Engineering built linting and conversion tools, and we ran side-by-side regression tests on converted pages. Once a page passed, its remaining Classy dependencies could be removed.
We created a Treasury documentation hub with everything teams needed to migrate pages on their own: design mappings, migration guidance, linting and conversion tools, and foundations and components in Figma and code. New components appeared there as they were ready.
We organized the rollout by template type. Mortgage, Banking, and Insurance teams each had their own versions of common templates, such as calculators, hubs, and review pages, alongside templates unique to their product area.
For each template type, we started by migrating lower-converting pages before moving to higher-traffic pages. This pragmatic approach gave design and engineering time to work through each template’s nuances and refine the process before we migrated pages with greater business impact, while production continued.
Design-to-code parity more than doubled with Treasury. More Figma components had direct counterparts in production, reducing the need to reinterpret or recreate patterns across teams.
[ DESIGN-TO-CODE PARITY ]
Replacing Classy with Treasury on the homepage reduced delivered CSS from 184 KB to 48 KB and improved Largest Contentful Paint (LCP) from 3.4 to 2.6 seconds. Instead of loading the full utility set, Tailwind generated only the styles used in production code, resulting in faster loading and a stronger technical foundation for SEO.
[ HOMEPAGE PERFORMANCE ]
The clearest workflow improvement was in calculator development. Previously, teams rebuilt inputs, sliders, dropdowns, and interaction states for each calculator, often repeating decisions that had already been made. Treasury consolidated those patterns into a robust calculator kit, allowing teams to assemble the interface and focus on the underlying calculations. A calculator that typically took 3–4 sprints to build could be completed in about 1 sprint.
[ CALCULATOR BUILD CYCLE ]
Metrics showed what happened, but not how Treasury was experienced. I surveyed designers and engineers quarterly after Treasury’s launch to determine whether they trusted what we built, made it part of their workflow, or quietly abandoned it. Participants rated five statements from 1 (strongly disagree) to 5 (strongly agree).
| Sentiment | Statement |
|---|---|
| Capability | I can confidently use Treasury to complete my work. |
| Leader support | My team’s priorities support using Treasury as intended. |
| Partnership | When I raise a Treasury issue, the design-system team helps me reach or understand the outcome. |
| Value | Treasury reduces effort to design, build, and maintain product work. |
| Consistency | Treasury enables consistent experiences across Bankrate. |
[ TREASURY SENTIMENT ]
Over 18 months, product teams migrated to Treasury without disrupting production, unifying the systems in Figma and code around a common language.
Treasury enabled consistency in design and reliability in code. Aligning the two helped designers and engineers work as one, so they could build with greater confidence across Bankrate.