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….
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.
@@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.
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
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
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.
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.
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.
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
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 :)
You didn't show the result effects of the sizing on the squares.
Sorry! Was an overlook when filming
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!
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
4:50, is 56 right?
Sorry, should be 64. Typo while recording.
❤❤🎉
Please make tutorial on complete prototyping ❣️
Will do!@@mojito1216