Variables are brilliant. However, the approach you showed in the video is really hard for development. E.g. if you're creating a component with mapped variable you might likely forget what size that mapped variable has. So that you should trace a value from mapped collection to alias, then to the brand collection. Any ideas how that may be simplified?
The tokens in themselves reference the initial brand or primitive values. Are you using token studio to sync with your developers? It would be good to understand what issue your devs are having, maybe we can setup a call with one of our tech leads.
I'm a developer too. I had the same frustration when the team adopted design tokens for the first time in my company. It only happens in teams where the design tokens are improperly adopted (i.e. the designers don't properly assign the tokens in Figma or the naming is not consistent in the code and in Figma). I soon realised that the frustration only arises when you try to develop the UI thinking in raw pixels, colour codes, etc. The first step is to forget them! Always think in design tokens. For example, when you want to add border radius to a button, don't try to think in pixels first... so instead of "hmm this radius looks like 16px... now what the heck is the name of the token for 16px radius?" it should be something like "Figma states the corner radius is size/md so in the code it should be var(--size-md)". You should never know what raw pixel/colour value is for a Figma variable and for the corresponding CSS variable. Because, those values change depending on the device (desktop, tablet, mobile), colour themes (dark, light), etc.
As always, I appreciate your in-depth videos. I have a few questions: Regarding your Brand spacing/sizing, why not just make it the actual value if you’re going to point Alias tokens with t-shirt sizing at it? E.g., at the Brand level: spacing-4=4px, sizing-8=8px? Wouldn’t that achieve the same thing while also making the underlying values of the Brand tokens more easily understood when assigning/looking at the Alias tokens? OR, because you’ve abstracted it to another reference tier (Mapped) is my point moot? It seems to me as though the Mapped collection is being used as a component tier, as opposed to core/global or alias/semantic tier. If it’s NOT a component tier, why have a second alias tier at all? This seems like an extra layer of complexity to me. Thank you.
Think he was referring to the logic behind the brand values in the beginning, that numbers are more generic and easier to administrate in smaller increments in case you need that for one off instances, like he demoed at the last part, BUT what I struggled to understand is why those increments should be more "fine tuned" by property in general than the pre-defined t-shirt sizes. Cause if the Alias variables are set to identically represent the Brand values, then those Brand values could also be t-shirt sizes, making the system easier to administrate. Numbers are less restricted to the label formats so it kinda makes sense to base everything on that and then assign pre-defined size labels like S, M etc to Alias variables in different contexts. Just seems a bit double trouble to have different measurement concepts if it's all assigned to the same t-shirts anywho. Perhaps I've missed out on some logic here, wouldn't be the first time 😂
Great dialogue! So 100 scale in brand just offers flexibility if you do need to add others. Then t-shirt sizing in Mapped because this is generally clearer to every designer than 100 scale sizing. Sorry for the short response... on my phone at an airport :) @@Underhills
But I agree with @angyBrooksPersonal Why crypting the values for Spacing. All possible values can be added inbetween, also by just using the real values. There do not exist half pixels - Right? No need to blow up the adding possibilies.
@@UICollectiveDesign I think it would remove the need for modes and aliasing to the extent we must today. It must be near impossible to get relative units to work if they decide to go this long, painful direction first?
@@WePiphany Agreed on that. Will be interesting to see how Figma manages to support the more complex functionality, without sacrificing the basic needs of the everyday user.
When using a 4pt/8pt system: How to account for the border of elements? Either you have px less padding e.g. around the icon of and the buttons border or your button is px larger. Even if you choose the first option what if you have an outlined version and a filled version of that button. Either the content inside of the button does not has the same spacing to the button sides as the filled button or it has, meaning the buttons content is not vertically aligned with the other buttons content (that effect stacks when using multiple outlined/filled buttons next to each other and is a huge problem when an outlined button should become filled once hovered due to content jumps). Buttons are just one example, there are more. Does anyone know how to deal with that in real world projects? Saying the devs we use multiples of 4 but in reality there are odd numbers due to border usage.
Great question! The important thing to remember is that pt systems do not always need to be followed exactly. Especially when borders often have a 1px width. It's okay to violate it if your design calls for it, as long as it's clear in your documentation so both devs, and designers know to follow it.
This is a great video but I need to add one suggestion, please alert viewers that this tutorial needs a premium figma version, many freelance designers work like this, we can’t add more than one mode. Still nice to learn though….
Naming your tokens on a 100 scale kind of defeats the purpose of its flexibility. You'll end up with a mess of a system by having irregular increments going from 100, to 150, 160 then jumping to 200 (and their values aren't correlated to the actual pixel value, which is even more confusing and will require people to have a table of reference).... makes no sense. Just name your tokens to what the spacing value is...
I disagree - what happens if you need to change your spacing in the future - you will encounter breaking changes. What if in the future 4px changes to REMs? Then how will your system work?
Variables are brilliant. However, the approach you showed in the video is really hard for development. E.g. if you're creating a component with mapped variable you might likely forget what size that mapped variable has. So that you should trace a value from mapped collection to alias, then to the brand collection. Any ideas how that may be simplified?
The tokens in themselves reference the initial brand or primitive values. Are you using token studio to sync with your developers?
It would be good to understand what issue your devs are having, maybe we can setup a call with one of our tech leads.
I'm a developer too. I had the same frustration when the team adopted design tokens for the first time in my company. It only happens in teams where the design tokens are improperly adopted (i.e. the designers don't properly assign the tokens in Figma or the naming is not consistent in the code and in Figma).
I soon realised that the frustration only arises when you try to develop the UI thinking in raw pixels, colour codes, etc. The first step is to forget them! Always think in design tokens. For example, when you want to add border radius to a button, don't try to think in pixels first... so instead of "hmm this radius looks like 16px... now what the heck is the name of the token for 16px radius?" it should be something like "Figma states the corner radius is size/md so in the code it should be var(--size-md)".
You should never know what raw pixel/colour value is for a Figma variable and for the corresponding CSS variable. Because, those values change depending on the device (desktop, tablet, mobile), colour themes (dark, light), etc.
As always, I appreciate your in-depth videos. I have a few questions:
Regarding your Brand spacing/sizing, why not just make it the actual value if you’re going to point Alias tokens with t-shirt sizing at it? E.g., at the Brand level: spacing-4=4px, sizing-8=8px? Wouldn’t that achieve the same thing while also making the underlying values of the Brand tokens more easily understood when assigning/looking at the Alias tokens?
OR, because you’ve abstracted it to another reference tier (Mapped) is my point moot? It seems to me as though the Mapped collection is being used as a component tier, as opposed to core/global or alias/semantic tier. If it’s NOT a component tier, why have a second alias tier at all? This seems like an extra layer of complexity to me.
Thank you.
Think he was referring to the logic behind the brand values in the beginning, that numbers are more generic and easier to administrate in smaller increments in case you need that for one off instances, like he demoed at the last part, BUT what I struggled to understand is why those increments should be more "fine tuned" by property in general than the pre-defined t-shirt sizes. Cause if the Alias variables are set to identically represent the Brand values, then those Brand values could also be t-shirt sizes, making the system easier to administrate. Numbers are less restricted to the label formats so it kinda makes sense to base everything on that and then assign pre-defined size labels like S, M etc to Alias variables in different contexts. Just seems a bit double trouble to have different measurement concepts if it's all assigned to the same t-shirts anywho. Perhaps I've missed out on some logic here, wouldn't be the first time 😂
Great dialogue! So 100 scale in brand just offers flexibility if you do need to add others. Then t-shirt sizing in Mapped because this is generally clearer to every designer than 100 scale sizing. Sorry for the short response... on my phone at an airport :) @@Underhills
But I agree with @angyBrooksPersonal Why crypting the values for Spacing. All possible values can be added inbetween, also by just using the real values. There do not exist half pixels - Right? No need to blow up the adding possibilies.
4:50, is 56 right?
Sorry, should be 64. Typo while recording.
I have a question, why create alias collections for spacing and sizing? Don't they work well directly from primitive ones?
This is also a good approach!!
you said you use 100 scale to add something in between but then you matched them to a tee-shirt scale. What would happen then if you had to add 150?
Provided some examples at the end on how to squeeze those in. You also don't need to switch to t-shirt sizing. I just like to use it really :)
Really great question though!
I struggle to take the t-shirt sizing method seriously. Maybe it's the woodworker in me. Any real reasons why it's desirable?
Personally I use 100 scale more frequently but for sizing and spacing it's more descriptive
Looking forward to the day Figma supports relative units and calc().specifically for type and spacing.
I agree! Long overdue honestly
@@UICollectiveDesign I think it would remove the need for modes and aliasing to the extent we must today. It must be near impossible to get relative units to work if they decide to go this long, painful direction first?
@@WePiphany Agreed on that. Will be interesting to see how Figma manages to support the more complex functionality, without sacrificing the basic needs of the everyday user.
Hi! I wonder, why didn't you place desktop, tablet and mobile variations at the aliases level?
You can do this as well if you want them more global :)
When using a 4pt/8pt system: How to account for the border of elements? Either you have px less padding e.g. around the icon of and the buttons border or your button is px larger. Even if you choose the first option what if you have an outlined version and a filled version of that button. Either the content inside of the button does not has the same spacing to the button sides as the filled button or it has, meaning the buttons content is not vertically aligned with the other buttons content (that effect stacks when using multiple outlined/filled buttons next to each other and is a huge problem when an outlined button should become filled once hovered due to content jumps). Buttons are just one example, there are more.
Does anyone know how to deal with that in real world projects? Saying the devs we use multiples of 4 but in reality there are odd numbers due to border usage.
Great question! The important thing to remember is that pt systems do not always need to be followed exactly. Especially when borders often have a 1px width. It's okay to violate it if your design calls for it, as long as it's clear in your documentation so both devs, and designers know to follow it.
Hoping the day will eventually come when we can use clamp functions and REM values
Agreed! Really looking forward to REM values
Wait, but... should the sizing for mobile be larger than for desktop, right? For instance, when creating buttons with variables
Not for everything, but it depends on the brand
You didn't show the result effects of the sizing on the squares.
Sorry! Was an overlook when filming
Wy use a 100 scale and not the actual value of the "value"
Because if the value changes, the name won't. So to summarize, avoids downstream developer impacts.
This is a great video but I need to add one suggestion, please alert viewers that this tutorial needs a premium figma version, many freelance designers work like this, we can’t add more than one mode. Still nice to learn though….
That's a great call out. Thanks for the suggestion! Will do better
❤❤🎉
Please make tutorial on complete prototyping ❣️
Will do!@@mojito1216
Naming your tokens on a 100 scale kind of defeats the purpose of its flexibility. You'll end up with a mess of a system by having irregular increments going from 100, to 150, 160 then jumping to 200 (and their values aren't correlated to the actual pixel value, which is even more confusing and will require people to have a table of reference).... makes no sense. Just name your tokens to what the spacing value is...
I disagree - what happens if you need to change your spacing in the future - you will encounter breaking changes. What if in the future 4px changes to REMs? Then how will your system work?
@@UICollectiveDesign What if in the future spacing 200 is the exact same as spacing 100?
@@TrickyPasta That's fine, at least you have the flexibility to change