So excited about Variables. I know it was asked at ConFig whether or not Styles would be deprecated, and the answer was, “No”. I have a design system that leverages styles, but I want to migrate to Variables. Something I’m wondering about though, is how useful are Styles for colors now that Variables are in play?
This is where my thinking is at. Is there any reason to have a Style that inherits its color value from a Variable, that I then use to define the color of a component? Or is it better to cut out the middle guy (the Style) and have the component inherit its color directly from the variable?
It may entirely be a preference thing, but I’m not seeing a scenario where I’d want to go the variable → style → component route, and instead just go variable → component. So yea, just curious to the community’s thoughts on this.
Update: I rewatched the Deep Dive on Variables and I’m wrapping my head around the Primitive → Semantic convention, and I think I see the value there (… I think ), but now that structure is:
I had the same problem finding a value in the coexistence of variables and ‘old’ styles
To me, styles could still have an application if they could hold multiple var types (color, font style, size) like it is used in CSS. That would allow building a more ‘atomic’ structure of a design system where the variables are the smallest chunks of information and styles are sth more of an organism collecting at least a set of values that could be applied to a certain element (text, frame, shape, image).
Even though that happens already when creating components, it’s sometimes a very repetitive task to apply all various styles when just adding additional texts, frames, and shapes. To speed up the process or make it more structured, you’re either forced to define components beforehand or manually click a few times to always represent the same sets of values.
I would personally appreciate revealing a vision of styles and variables in Figma as I don’t have a clear answer in which direction I should develop my design system.
I really like that idea of utilizing styles in the next chain of an atomic structure, holding multiple variables like you said. I think that could be really cool to see. Cause yea, at this point, and I’m just thinking in terms of colors, choosing between a style and a variable seems either redundant (if you do both) or just a matter of preference. Though I do think that it’s only variables that can leverage the “modes” layer of functionality, which is a solid justification for their use. I also feel like variables align more with a programming mentality, which I think could have added benefits in ‘handoff’ or even in just forming a mental model of a design system.
Use styles to combine multiple color fills. For single color values that respond to modes (e.g. light and dark), use color variables.
Interesting. Multiple color fills are the way to mix few colors, however it does not seem very useful as there is no way to override opacity for each color fill in a style. Would be nice to be able to grab several solid paints and mix them together by stacking colors with different alpha channels
@Nick_M I found it quite logical to think of it like this:
define a primitive color Variable, say brand-primary with value #AAAAAA
define a semantic style and make it reference the primitive color Variable
This would work quite well for a scenario where you have let’s say Design system X and product A.
Designsystem X exports the style “primary color” referencing variable “brand-primary”.
But if product A is a brand product within another domain and other constraints, it might be the case that for that domain, the primary color instead needs to be the secondary brand color (maybe for contrast reasons). In that case, Product A might export it’s own semantic style for “primary color” that instead references the variable “brand-secondary”.
This at least feels logical to me, but i’d also be interested in how others interpret and use the styles vs variables relationship.
We’re kind of confused in our team, too. I’m very happy about variables as it introduces tokenization, but I’m having a hard time wrapping my head around the use of styles if I’m migrating all my design system to variables. Especially if you don’t use multiple fills in your styles, what’s the point in keeping them? But I feel like I’m missing something here.
In this video they do indeed show how to “back” your styles with variables (using plugin to avoid doing it manually), but that seems to complicate the process as shown in your first screenshot
Our team is also confused, especially since it appears you cannot have a variable reference a style. So we had to re-do our styles as variables in one collection and then also create another collection for the tokens, because that’s how the video explained to do it. It would almost be better to only have the tokens collection and be able to reference different style sets that are in the file. I also feel like we’re missing something, because it seems like this method could potentially add more maintenance to upkeep the design system.
I wish they would just made colour styles into one of the variable types. I.e. all the “colour styles” would have already become “variables” after the update and gave us the ability to add an extra mode for them. Instead of two entities, we would have had just one.
I do not see the need to have a colour variable to store only one hex code as a valid argument. It would not be that hard to allow it to store multiple colours.
The approach they’ve chosen so far seems to be “developer first” where the developers would get clean separated variables, which is not optimal for design needs.
), but now that structure is:
