Here's my developer-targeted summary of layered design tokens for those that are skeptical of the value or think this is just obvious. The general idea is to maintain a set named constants that are built up in layers that web/UI designers use in their design apps (like Figma), AND the developer uses the same constants in their code when coding up the designs:
1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code.
2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast.
3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages.
Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices).
I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers!
UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before?
Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers.
The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.
1. You first have a "base" layer of constants e.g. constants for a small number of font sizes like text-base=18px and text-large=24px, and shades of gray/blue/red/green ranging from grades 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should not be used directly in designs or styling code.
2. You have a "semantic" layer of constants that can only reference the base layer e.g. color-success-foreground=green-7 and color-success-background=green-1, where you pick these colors knowing they will have readable contrast.
3. You then have a final "component" layer of constants for use in UI components that can only reference constants from the semantic layer. So my "alert" component that shows a success message inline on pages can use "color-success-foreground" for the text, and so can my "toast" component that shows pop-up messages.
Some of the benefits are visual consistency (e.g. you avoid having 20 slight variations of green spread between designs, implementations of those designs, and across different apps), accessibility (e.g. you can do accessibility checks at the semantic layer and all your components benefit), communication (e.g. gives designers and devs a shared language), ease of updates (e.g. update the colors in the base layer, and it spreads to all your designs and coded apps), and faster design + dev (because you're picking from a small number of predefined choices).
I agree if you're a developer, articles on this can look like way too much text, including the frequent elaborate discussions on how do you just name the constants but... this stuff is brand new to many dedicated designers!
UI design apps like Figma have only in the last couple of years started including ways to manage layers of variables like this, so many are just getting to grips with it because where else would they have seen elaborate layers of variables before?
Developers have been discussing and practicing for decades how to name variables and modules, how to architecture/layer stuff like this, and how we should use named constants over magic numbers, so the above is going to look more obvious to developers.
The base/semantic/component layering isn't completely obvious either, and really does help with organization as the number of constants do build up. The three layers is overkill for simpler apps, but just having the base and semantic layer is helpful for even basic UI/web designs with custom brands, especially for keeping accessibility in check.