0%
Bankrate Design System: Treasury

Bankrate Design System: Treasury

Treasury unified Bankrate’s design library and custom utility framework into one Tailwind-based system.

Bankrate logo usage
Bankrate brand colors
Bankrate color icon row with offset alignment
Bankrate alert component specification
Bankrate credit card comparison specification
Bankrate pagination specification
Bankrate button and input form documentation
Bankrate budgeting interface

CASE STUDY SALEENA BEHARRY

Bankrate Design System: Treasury

Migrating an existing design system to Tailwind.

The existing system

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.

Rebuild the foundations

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.

Support the transition

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.

Migrating in stages

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.

Results

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.

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.

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.

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.

Conclusion

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.

Other work