Skip to main content
Lucas West
Lucas West
New Participant
September 17, 2026

Color Variable Alias + brightness, contrast, or hue offset

  • September 17, 2026
  • 2 replies
  • 15 views

Color variable aliases were recently given the ability to define a new transparency value without detaching the actual color from the source variable. However, only the opacity can be set and even that’s only if the source color is solid, instead of allowing existing opacities to be offset.

It would be really cool if that system could be extended to also allow modifying the other axes, not just the transparency. Since you can’t define a color with a hue and saturation but no lightness, adding this would also ripple out to the opacity by allowing offsets to the existing color’s opacity, instead of what currently happens where if the source is not solid, the feature gets disabled altogether.

The use case for this is absolutely massive, letting you far more deeply align your color palette to a single source of truth. It strongly fits the ideals expressed by the recent “Control opacity at scale” feature. It further reaffirms the vision that Figma can be the gold standard for creating actually deeply modular, fully dynamic and modern composed design systems. It would increase the ability for sharing components and design systems between different companies or even just sub-brands or products with distinct brand identities without having to do loads of upfront work creating all the variations of colors. Lastly, it would make it possible for companies that already posses a media brand book or style guidelines only focused on print and media applications to actually build a complete web/UI/UX design system without ever defining new static colors not reflected in the brand identity documents. For example, the main color for a button is likely already defined for print and media use, but the subtle variations of that color for hovering and pressing interaction states almost definitely are not.

For example, you could have one primary brand color set manually, and then have everything from hover/pressing interaction state colors to disabled colors to even the text or border colors determined dynamically by offsetting the HSL or HSB coordinate axes of the primary brand color, instead of having to rely on external programs or eyeballing to make sure the colors all change and all change by the right amount when adjusting that base color.

What I’m looking for:

  • Extend the recent color variable alias with different opacity system to also work when the source has an opacity, overriding it.
  • Extend that with a toggle to swap between overriding the existing opacity and offsetting it.
  • Extend it further the allow targeting not just the opacity, but also let you pick from the supported color models like RGB, HSL, HSB, and hopefully eventually OKLab variants of those, and then apply an offset or override on any of the three parameters the selected color model contains.
  • Just like how the color variable alias with different opacity feature was nicely given the ability to also link the new opacity to a number variable, it would also be great if the new color coordinate offset function could have it’s offset attached to a number variable
  • A sensible continuation of that would be letting number variable aliases also be defined with an offset from their source value, who’s offset could also be bound

Why it matters:

  • Color variables cannot have a single source of truth for small variations like button hover/pressing interaction as besides opacities, color variables cannot be defined relative to other colors
  • Companies who have never made UI/UX web design systems but do have brand identity documents must create a ton of new colors out of nowhere
  • Design systems cannot be easily shared between products or sub-brands with a different color pallet without having to update tons of potentially fractured hard-coded variations of just a few individual colors

2 replies

ksn
Figmate
ksn
Community Support
September 17, 2026

Hey ​@Lucas West - thanks for your feedback! I’ll pass it along to the teams that worked on variables.

As a super, super high level, you’d like to see:

  • Variables to be adjustable when aliased (brightness, hue, etc.)
  • Allow adjustments via number variables (for better parity)

Essentially, some quality-of-life adjustments that can be added that can lower the lift for teams so they can build upon a single color source as well.

That may have over-simplified your post, so please let me know if I missed the mark on this! I’m going to pass on your post in its entirety, but just making sure my thinking is aligned.

    Lucas West
    Lucas WestAuthor
    New Participant
    September 17, 2026

    Hey, thank you so much!! That sounds about right, though it might be good to also note specifically giving users the option between completely overriding the source’s value in the chosen axis/axes vs taking a relative offset from the source’s value. That’s important so you can both do things like interaction states with small relative offsets, while also allowing things like making a surface color that always has a fixed lightness and saturation, but pulls in the hue of the brand color, for instance.

    Other notes or ideas that might be useful to pass over that I didn’t include are:

    • Different color models do coordinates differently, some are integers, some are percentages like opacity, some are bounded, and some are unbounded and even signed like in OKLab which may eventually be supported. I have no clue exactly how it could be done, but the different number systems present and future may warrant some additional consideration to ensure users don’t get like locked into a specific color model just because they used this system.
    • When using relative offsets, for most bounded color model axes it would make sense to just clip the result value to the top or bottom if it overflows, but specifically for hue it would make more sense for it to wrap around. I don’t have an example, but letting people choose between those two behaviors could potentially be powerful, don’t know for sure though.
    • Since giving number variables the ability to also be bound as offsets from each other gives rudimentary addition and subtraction functionality, perhaps consider possibly addressing the previous two points in a manner that either as a side effect or in a direct manner, also expands the math abilities of the variables system. Doing that may potentially open up some much more advanced functionality like automatic contrast color calculation for example.

    For example, accounting for mismatched color coordinate systems and any desire to wrap axes besides hue (without increasing the complexity for surface level users), while expanding the power of variables as a side effect, you could make it possible for color variables to also have their coordinates extracted back out into number variables. If you are able to specify a different color model to be used in the extraction than the model the color is built from or is stored as under the hood, this would have an even greater effect. I could vaguely see just that small addition opening up some crazy stuff, you could make any value wrap around by just passing it through the hue channel of a temporary color, you could multiply and divide numbers using the discrepancy between the scale of the opacity axis and the other color axes, you could do quantization using the property of RGB coordinates only being integers, and I’m sure plenty other things. I would say that if this were to be introduced though, it definitely wouldn’t be a good idea to force everyone to extract color variables out into 3 or 4 number variables just to apply a small offset to one or two channels of an existing color, that would be incredibly inconvenient, more so that it could be cool in addition.

    Terms & ConditionsAccessibility statement