Totally agree. This plugin should become an official part of Figma itself. Making sure that we don't become dependent on a plugin that might not be supported the next day.
This is beauty. The indept versioning and headless nature makes it scalable at ultimate level. Also the log files perfectly syncs the team to the changes. Very well drafted. Kudos to Esther Cheran for this indept knowledge sharing.
This is very helpful to organizations looking to modernize their design system and is looking at growth that the current legacy design system cannot reach. Thank you for sharing.
I’m struggling to see the value in this method, it’s looks over engineered, solving problems that don’t really exist and it doesn’t look like it speeds anything up. All this looks like it could be done with a tradition DS
It would have been useful before they added branching if you wanted different versions of components. But yeah prob not anymore other than it being somewhat more organized.
@@dotsona07 You can't use/reference components in branches. Although the previous versions are unpublished in this presentation, they could publish past versions in a library update for consumers who wish to remain on an older version of a component.
If you work with only one brand or product you are correct. However a lot of us work with multiple brands where the underlying components are the same but layouts and styles change. A situation like that makes design tokens invaluable, it also makes handing off to developers super easy with just a JSON file containing all your styles. Not to mention the fact you can control things like padding or border-radius globally which you can’t do in Figma natively.
When Figma, when are we getting design token support? And Dark Mode and the ability to create a design system and change the design tokens to support different sites.
We leave components specific tokens to the developer, who will implement them when needed on his end. Nathan Curtis gave the same advice in his Smashing mag workshop on engineering design systems.
This was really insightful, only just getting started with design tokens so very helpful, thank you Esther. Can anyone recommend further reading on this topic?
This is great! Thanks for sharing, there is any chance to get a copy of the semantic naming/labelling file? I'm a bit struggling with how to structure and name the tokens.
i think we shouldn't consider that we have to choose between one file & multiple file library as made on for different purposes. Multiple files for managing content (production), and one file for explorations or improvments (devlopment). As we have now headless systems solutions, both shoulds works together
Won't over organizing make the designers loose their tail when they want to update something in the DS? To change something in the button, for an example, the designer will have to go through an "Inception" type of route just to get to the value they want to change? button - token - token in token - etc...
This granular organisation is definitely not suitable for every kind of project, but when you're managing multiple brands in multiple themes from a single component library, IMO it soon pays off. Of course, this would only be used by library maintainers. Product designers would only consume the components, possibly 1 per brand and use a subset of tokens, possibly in the form of figma styles, to go about their day to day design work. Again, this project is partly experimental, and trying to address a really complex multi-brand DS environment. For a more basic DS I can imagine a different approach working better.
@@esthercheran1532 I completely disagree, having worked on Twitters and Github DS's management, your approach has many flaws and will tank productivity, looks like its intentionally overthought
Figma Tokens is nice, but it is not really handy to use. Please bring this feature in a way it is also implemented like text-styles and color-styles into figma.
Hello, thank you! Very insightful. I have a question regarding the versions: can you detail how you do this? Does the version just act as a copy / backup? What if you have to go back to an old version? How do you ensure that you don't loose the relation between the component and the products that are using it? Thank you!
I love the idea of this like everyone else but has anyone used it with a team? I'm wonder how it scales, how easy it is to use for the individual creating styles and designer that consumes components built with it. Any other pain points....
If I understand what you're asking, I think your question is answered at 42:00, where she shows which libraries she's enabled for that section of her demo. So yes, when you create a new file, you'd need to enable the individual library file for each component you plan to use. Then, they'll be available in the Assets panel.
Since you can only locally store tokens within the plugin for one file. How do you provide tokens for all, individual component files ? I love those demos, but it would be also a great topic to talk about how to setup your plugin in order to supply multiple files.
Thanks for the video and the good explanation. But I cannot find the option for automatic documenting the component tokens, shown at 31:30 min of the video. I'm using the Version 95 of the Figma Tokens plugin and the "Add an annotation" option is just missing in the Inspect tab. Can someone help with that?
How do You visually map those tokens? most of the documenting tools are not capable to show those in a intuitively view like that. It's been a challenge to keep the documentation updated with tables and "JSONish" views (like Zeroheight do)
Tokens are platform agnostic, and can be transformed to platform specific variables using a service like Amazon's Style Dictionary or Saleforce's Theo. Those services take tokens grouped in a JSON-file or YAML-file as an input, and generate platform specific variables. They also allow platform specific unit conversion like px to dp or pt depending on platform output. Surprised this video mentions nothing about the most valuable aspect of a design token.
I think the way the design system is organized is waaaaaaaaaaayyyyy overthought and engineered, classic example of being obsessed with process instead of output
Some semblance of this token plug-in should definitely be incorporated into Figma. Very powerful
Totally agree. This plugin should become an official part of Figma itself. Making sure that we don't become dependent on a plugin that might not be supported the next day.
This and any kind of logic in components would take Figma to the next level.
They are working on it; confirmed this on Twitter.
@@NaniNaniX it's open-source
By far one of the best design system demos i've seen! More of this please!
This is beauty. The indept versioning and headless nature makes it scalable at ultimate level. Also the log files perfectly syncs the team to the changes.
Very well drafted. Kudos to Esther Cheran for this indept knowledge sharing.
Thank you. Glad you liked it!
This is spectacular! Thank you Esther for sharing your knowledge!
My pleasure!
This is a giant move in design system. Thanks a lot.
This is very helpful to organizations looking to modernize their design system and is looking at growth that the current legacy design system cannot reach. Thank you for sharing.
You're welcome :-)
Thank you very much figma for the support. I hope more videos coming like this. very needed much
This was fantastic and really useful. Very clear explanations and examples.
Awesome plug-in loved it
Outstanding work! Thank you for sharing this video, this is an eye opener!
Any chance you could share a generic figma file so those who want to follow this example aren't starting from scratch ?
Impressive.
Thanks :-)
Thanks a lot!!!
Very powerful plugin, will be interested to have a lot of the functionalities moved to default Figma.
Love the themes feature.
I’m struggling to see the value in this method, it’s looks over engineered, solving problems that don’t really exist and it doesn’t look like it speeds anything up. All this looks like it could be done with a tradition DS
It would have been useful before they added branching if you wanted different versions of components. But yeah prob not anymore other than it being somewhat more organized.
@@dotsona07 You can't use/reference components in branches. Although the previous versions are unpublished in this presentation, they could publish past versions in a library update for consumers who wish to remain on an older version of a component.
If you work with only one brand or product you are correct. However a lot of us work with multiple brands where the underlying components are the same but layouts and styles change. A situation like that makes design tokens invaluable, it also makes handing off to developers super easy with just a JSON file containing all your styles.
Not to mention the fact you can control things like padding or border-radius globally which you can’t do in Figma natively.
When Figma, when are we getting design token support? And Dark Mode and the ability to create a design system and change the design tokens to support different sites.
We leave components specific tokens to the developer, who will implement them when needed on his end. Nathan Curtis gave the same advice in his Smashing mag workshop on engineering design systems.
do you have a link please?
Would you be open to sharing the repo to the visual mapping tool?
This was really insightful, only just getting started with design tokens so very helpful, thank you Esther. Can anyone recommend further reading on this topic?
This is great! Thanks for sharing, there is any chance to get a copy of the semantic naming/labelling file? I'm a bit struggling with how to structure and name the tokens.
i think we shouldn't consider that we have to choose between one file & multiple file library as made on for different purposes. Multiple files for managing content (production), and one file for explorations or improvments (devlopment). As we have now headless systems solutions, both shoulds works together
Cool stuff,
But I'm not happy with the new payment plan 🙁
Won't over organizing make the designers loose their tail when they want to update something in the DS?
To change something in the button, for an example, the designer will have to go through an "Inception" type of route just to get to the value they want to change?
button - token - token in token - etc...
This granular organisation is definitely not suitable for every kind of project, but when you're managing multiple brands in multiple themes from a single component library, IMO it soon pays off. Of course, this would only be used by library maintainers. Product designers would only consume the components, possibly 1 per brand and use a subset of tokens, possibly in the form of figma styles, to go about their day to day design work. Again, this project is partly experimental, and trying to address a really complex multi-brand DS environment. For a more basic DS I can imagine a different approach working better.
@@esthercheran1532 I completely disagree, having worked on Twitters and Github DS's management, your approach has many flaws and will tank productivity, looks like its intentionally overthought
Figma Tokens is nice, but it is not really handy to use. Please bring this feature in a way it is also implemented like text-styles and color-styles into figma.
Hello, thank you! Very insightful.
I have a question regarding the versions: can you detail how you do this? Does the version just act as a copy / backup? What if you have to go back to an old version? How do you ensure that you don't loose the relation between the component and the products that are using it? Thank you!
I love the idea of this like everyone else but has anyone used it with a team? I'm wonder how it scales, how easy it is to use for the individual creating styles and designer that consumes components built with it. Any other pain points....
If each component lives in a separate file, how do you use them when drawing? Do you have a Figma library per component?
If I understand what you're asking, I think your question is answered at 42:00, where she shows which libraries she's enabled for that section of her demo. So yes, when you create a new file, you'd need to enable the individual library file for each component you plan to use. Then, they'll be available in the Assets panel.
in creating different versions of pages, how are some pages avoided in publishing?
Is there a downloadable example?
Can't help but notice that the CTA's in Storybook are pill-shaped , but the buttons on the Figma component file are not?
Is it possible to purchase such the DS?
❤
Since you can only locally store tokens within the plugin for one file. How do you provide tokens for all, individual component files ? I love those demos, but it would be also a great topic to talk about how to setup your plugin in order to supply multiple files.
The tokens are stored on GitLab and not in the plugin itself.
@@creativeembargo I think tokens are stored locally by default, you can choose to connect and sync to a repository
What's the roadmap for the native token support ?
Thanks for the video and the good explanation. But I cannot find the option for automatic documenting the component tokens, shown at 31:30 min of the video. I'm using the Version 95 of the Figma Tokens plugin and the "Add an annotation" option is just missing in the Inspect tab. Can someone help with that?
What is the font used in this presentation?
Can you give me some info on this plugin? can someone please tell me
32:04 - what is the name of this visualization tool?
How do You visually map those tokens?
most of the documenting tools are not capable to show those in a intuitively view like that.
It's been a challenge to keep the documentation updated with tables and "JSONish" views (like Zeroheight do)
same question!
Tokens are essentially cascading style sheets, no?
In CSS you can have Custom Properties, example:
:root {
--blue-500: #0000FF;
--primary-color: var(--blue-500);
}
Sure looks like it.
If someone had explained it to me THAT way, I wouldn't have wasted so much time reading convoluted online articles.
Tokens are platform agnostic, and can be transformed to platform specific variables using a service like Amazon's Style Dictionary or Saleforce's Theo. Those services take tokens grouped in a JSON-file or YAML-file as an input, and generate platform specific variables. They also allow platform specific unit conversion like px to dp or pt depending on platform output. Surprised this video mentions nothing about the most valuable aspect of a design token.
I think the way the design system is organized is waaaaaaaaaaayyyyy overthought and engineered, classic example of being obsessed with process instead of output
save space, lol
Great content. Awful delivery. This demo could have been reduced to 30min with some structure and preparation.
It would be amazing if Figma introduced Dark Mode
Don't know why everyone wants dark mode so bad. Dark mode will literally just affect both sidebars and that's like 25% of the screen, tops.
@@oscardeee Thank you.
@@oscardeee You can always change the canvas background color to match the dark mode.