
The existing library couldn't flex to client branding without breaking accessibility. Every new client meant manual contrast checking and one-off color decisions, a process that didn't scale.
The problem we were trying to scale for was that clients were given the option of having their logo and our company’s colors as the ‘Default’ option or they could choose to have their “Brand” color as the primary color.
Default

By assigning colors based on their tonal value rather than just their lightness, I ensured that any color in the system would maintain a predictable contrast ratio.

If a Neutral "Tone 80" passes accessibility against a Surface color, then a Brand "Tone 80" color will also pass.
We moved from "guessing at colors" to a logic-based taxonomy that ensures a cohesive user experience across all products.

Semantic naming system for core token library based on what a color DOES versus what it is.
“bkgd.brand.primary” vs “blue.500”
Used as a design tool or to validate with stakeholders. Carries 1:1 parity with code, so there is no change in what color would be generated.
Based on the color logic built in the plugin:
By shifting from measuring accessibility based only on HEX codes to a Perceptual Tonal Scale, and identifying breakpoints against our environment, I transformed our color system from a maintenance burden into a strategic asset. This architecture provides a repeatable framework for onboarding new clients and brands.
Contrast ratios are now "baked in" to the tonal scale, reducing manual QA time.
The decoupled Alias layer allows for instant "dark mode" or brand-swapping without touching the core component logic.

The existing library couldn't flex to client branding without breaking accessibility. Every new client meant manual contrast checking and one-off color decisions, a process that didn't scale.
The problem we were trying to scale for was that clients were given the option of having their logo and our company’s colors as the ‘Default’ option or they could choose to have their “Brand” color as the primary color.
Default

By assigning colors based on their tonal value rather than just their lightness, I ensured that any color in the system would maintain a predictable contrast ratio.

If a Neutral "Tone 80" passes accessibility against a Surface color, then a Brand "Tone 80" color will also pass.
We moved from "guessing at colors" to a logic-based taxonomy that ensures a cohesive user experience across all products.

Semantic naming system for core token library based on what a color DOES versus what it is.
“bkgd.brand.primary” vs “blue.500”
Used as a design tool or to validate with stakeholders. Carries 1:1 parity with code, so there is no change in what color would be generated.
Based on the color logic built in the plugin:
By shifting from measuring accessibility based only on HEX codes to a Perceptual Tonal Scale, and identifying breakpoints against our environment, I transformed our color system from a maintenance burden into a strategic asset. This architecture provides a repeatable framework for onboarding new clients and brands.
Contrast ratios are now "baked in" to the tonal scale, reducing manual QA time.
The decoupled Alias layer allows for instant "dark mode" or brand-swapping without touching the core component logic.

The existing library couldn't flex to client branding without breaking accessibility. Every new client meant manual contrast checking and one-off color decisions, a process that didn't scale.
The problem we were trying to scale for was that clients were given the option of having their logo and our company’s colors as the ‘Default’ option or they could choose to have their “Brand” color as the primary color.
Default

By assigning colors based on their tonal value rather than just their lightness, I ensured that any color in the system would maintain a predictable contrast ratio.

If a Neutral "Tone 80" passes accessibility against a Surface color, then a Brand "Tone 80" color will also pass.
We moved from "guessing at colors" to a logic-based taxonomy that ensures a cohesive user experience across all products.

Semantic naming system for core token library based on what a color DOES versus what it is.
“bkgd.brand.primary” vs “blue.500”
Used as a design tool or to validate with stakeholders. Carries 1:1 parity with code, so there is no change in what color would be generated.
Based on the color logic built in the plugin:
By shifting from measuring accessibility based only on HEX codes to a Perceptual Tonal Scale, and identifying breakpoints against our environment, I transformed our color system from a maintenance burden into a strategic asset. This architecture provides a repeatable framework for onboarding new clients and brands.
Contrast ratios are now "baked in" to the tonal scale, reducing manual QA time.
The decoupled Alias layer allows for instant "dark mode" or brand-swapping without touching the core component logic.