Content
View differences
Updated by Marc Alcobé about 3 years ago
# WORK IN PROGRESS
##
## Description
There is the possibility to transform our Figma "foundations" into **Deign Tokens** tokens that are directly used in the code library and even 100% synchronised dependant using GitHub or even used in other design/code softwares (soon PenPot hopefully). GitHub. There is some explanation videos/links videos of what **Design Tokens** are, its the functions and how do they work in Figma-Github: that Figma Design Tokens offers:
* Tokens presentation: [https://www.youtube.com/watch?v=ssOdzxZdg58&ab\_channel=Figma](https://www.youtube.com/watch?v=ssOdzxZdg58&ab_channel=Figma)
* Generic video: [https://www.youtube.com/watch?v=xEIZeFYoVtY&t=2s&ab\_channel=AMDesign](https://www.youtube.com/watch?v=xEIZeFYoVtY&t=2s&ab_channel=AMDesign)
* Easy tokens explains: https://youtu.be/wtTstdiBuUk
* Tokens in Github: [https://www.youtube.com/watch?v=KB05F7-8BHA&ab\_channel=AMDesign](https://www.youtube.com/watch?v=KB05F7-8BHA&ab_channel=AMDesign)
* Future with design tokens: https://www.youtube.com/watch?v=Ots630OxRwE&ab\_channel=IntoDesignSystems
* Design tokens community group: [https://www.w3.org/community/design-tokens/](https://www.w3.org/community/design-tokens/)
* Quickstart on how to set up a multi-layer token system: https://youtu.be/7utmznIOWLU
## Motivation
* Definition from W3C Design Token Community Group: _**"The single source of truth to name and store a design decision, distributed so teams can use it across design tools and coding languages."**_
* Common and reusable tokens that can be used also outside of Figma. These can then be reused in case at some point we want to switch to another design software.
* More Figma styles can be transformed into variables (tokens) than what Figma allows by itself (borders, radius, spacer units, breakpoints, z-index...). Allowing higher consistency across product UI.
* W3C compliant so you could take your JSON and move to another tool when needed.
* Manage Design Systems with multiple themes (dark mode, custom themes...) easier and from a single place. No need to have a library for each theme and you can switch between one and the other in a single file without nearly any loading time.
* Much better and easier to translate from design to development as there can be an automatic synchronisation between libraries through Github.
* Full and functional slot system for not needing to detach components when creating variations.
* Automatic LCH colour modifiers for tokens in order to comply with text contrast readability if you change the colours.
* Possibility to create a detailed and differentiated level of tokens (**this doesn't mean we need to follow this**):
* **"Option/foundation" tokens:** all "options" that could ever be useful in all imaginable cases in the DS (for all themes or "brands"). For example font sizes, spacings, x-y-z sixes/index or even colours (eg. token is: _foundation.color.mainblue.dark_).
* **"Semantic/base" tokens:** all those that come from a foundation design decision. This ones uses the "option" tokens but already solving design "questions" (eg. Q: What is the hover colour of your main/primary components? / A: token is: _base.color.component.primary.hover-bg_).
* **"Component" tokens:** are those that define exclusively components. This are useful in order to keep your "semantic" tokens clean and free of associations to real components. Maybe even, if developer agree, for developer hand-off and re-engineering. (eg. token is: _comp.button.color.primary-unselected.hover-bg_).
## Challenges
## Interesting visuals
<img class="op-uc-image op-uc-image_inline" style="width:352px;" src="/api/v3/attachments/55455/content"><img class="op-uc-image op-uc-image_inline" style="width:335px;" src="/api/v3/attachments/55456/content"><img class="op-uc-image op-uc-image_inline" style="width:334px;" src="/api/v3/attachments/55457/content">
##
## Description
There is the possibility to transform our Figma "foundations" into **Deign Tokens**
* Tokens presentation: [https://www.youtube.com/watch?v=ssOdzxZdg58&ab\_channel=Figma](https://www.youtube.com/watch?v=ssOdzxZdg58&ab_channel=Figma)
* Generic video: [https://www.youtube.com/watch?v=xEIZeFYoVtY&t=2s&ab\_channel=AMDesign](https://www.youtube.com/watch?v=xEIZeFYoVtY&t=2s&ab_channel=AMDesign)
* Easy tokens explains: https://youtu.be/wtTstdiBuUk
* Tokens in Github: [https://www.youtube.com/watch?v=KB05F7-8BHA&ab\_channel=AMDesign](https://www.youtube.com/watch?v=KB05F7-8BHA&ab_channel=AMDesign)
* Future with design tokens: https://www.youtube.com/watch?v=Ots630OxRwE&ab\_channel=IntoDesignSystems
* Design tokens community group: [https://www.w3.org/community/design-tokens/](https://www.w3.org/community/design-tokens/)
* Quickstart on how to set up a multi-layer token system: https://youtu.be/7utmznIOWLU
## Motivation
* Definition from W3C Design Token Community Group: _**"The single source of truth to name and store a design decision, distributed so teams can use it across design tools and coding languages."**_
* Common and reusable tokens that can be used also outside of Figma. These can then be reused in case at some point we want to switch to another design software.
* More Figma styles can be transformed into variables (tokens) than what Figma allows by itself (borders, radius, spacer units, breakpoints, z-index...). Allowing higher consistency across product UI.
* W3C compliant so you could take your JSON and move to another tool when needed.
* Manage Design Systems with multiple themes (dark mode, custom themes...) easier and from a single place. No need to have a library for each theme and you can switch between one and the other in a single file without nearly any loading time.
* Much better and easier to translate from design to development as there can be an automatic synchronisation between libraries through Github.
* Full and functional slot system for not needing to detach components when creating variations.
* Automatic LCH colour modifiers for tokens in order to comply with text contrast readability if you change the colours.
* Possibility to create a detailed and differentiated level of tokens (**this doesn't mean we need to follow this**):
* **"Option/foundation" tokens:** all "options" that could ever be useful in all imaginable cases in the DS (for all themes or "brands"). For example font sizes, spacings, x-y-z sixes/index or even colours (eg. token is: _foundation.color.mainblue.dark_).
* **"Semantic/base" tokens:** all those that come from a foundation design decision. This ones uses the "option" tokens but already solving design "questions" (eg. Q: What is the hover colour of your main/primary components? / A: token is: _base.color.component.primary.hover-bg_).
* **"Component" tokens:** are those that define exclusively components. This are useful in order to keep your "semantic" tokens clean and free of associations to real components. Maybe even, if developer agree, for developer hand-off and re-engineering. (eg. token is: _comp.button.color.primary-unselected.hover-bg_).
## Challenges
## Interesting visuals
<img class="op-uc-image op-uc-image_inline" style="width:352px;" src="/api/v3/attachments/55455/content"><img class="op-uc-image op-uc-image_inline" style="width:335px;" src="/api/v3/attachments/55456/content"><img class="op-uc-image op-uc-image_inline" style="width:334px;" src="/api/v3/attachments/55457/content">