This work looks to be rather excellent, apart from their deciding to coin their own term "token" for what I take to be a "design element".
Here is my slightly edited comment from below:
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.
“Design token” is an accepted and widely used term (see Amazon’s Style Dictionary, Adobe’s Spectrum, etc.) that might even be standardized[0] by W3C at some point soon. Unlike “design element”, it refers to a more general concept; there is less confusion when you refer to a color, or to a measure, as “token” rather than “element”.
(The term “variable” may be more fitting, but it is on the other hand too generic and conflicting with a different idea in implementation domain: CSS or JS variables can mean the same thing, but not always.)
As an old-school designer, I didn’t like the term at first, but to be honest it is winning me.
I was taught design in terms of design models and design systems, so there was not much of a leap to “design token” as referring to a building block.
I am not 100% sure how I feel about it in general. If I was a designer who was only given freedom to operate within a set of tokens, I would certainly feel like my hands are tied. At the same time, I can see how even while using tokens it is entirely possible to design a bad interface. However, I also see value of them when it comes to maintaining consistent and intuitive UIs.
> I also see value of them when it comes to maintaining consistent and intuitive UIs
Absolutely. It's like the proper legacy of the GoF's "Design Patterns" book, whose lack of importance and acceptance has bewildered me for close on 30yrs now. Of course, it also means I have rich fields to till for my own work, so bwahaha :-)
[Note that the actual design patterns described in their book are not the important part; their understanding that we must implement software using patterns is their most important concept.]
You can already imagine OS vendors publishing their design tokens to let you "easily" integrate your applications even if not using their UI libraries.
I think the term token had been used in some UI products for quite a while now. The first time I heard it felt a little awkward but it is really quite natural now.
Here is my slightly edited comment from below:
What they are calling "tokens" are just their design elements.
They have abstracted the design elements into their 'tokens' so that they are defined parameters/variables/model-elements that can then be reified at some point before deployment.
This is a fancy (but seemingly excellent) way of encompassing a system's design decisions into a model, which can then be used either abstractly or concretely to proliferate them throughout the entire system, as needed, at the latest possible point the actual values are needed.
It really looks like top-shelf work, but I think their deciding to use the word "token" was an unnecessary mistake of nomenclature.