chore: add files from master-wiki repo

_master_wiki/void/Readwise/A guide to design tokens.md

@@ -0,0 +1,35 @@
+# A guide to design tokens
+
+![rw-book-cover](https://s3.amazonaws.com/www-inside-design/uploads/2021/06/design-tokens-7-1-810x810.png)
+
+## Metadata
+- Author: [[invisionapp.com]]
+- Full Title: A guide to design tokens
+- Category: #articles
+- Document Tags: [[design]] [[dev]] 
+- URL: https://www.invisionapp.com/inside-design/design-tokens/
+- Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=A%20guide%20to%20design%20tokens
+> [!tldr]
+> Design tokens help ensure consistency across different platforms by managing design properties from a single source. They are defined pairs of code and visual properties, like colors and spacing, that can be easily deployed. By using design tokens, teams can streamline updates and maintain a cohesive brand identity without confusion.
+
+## Highlights
+if you established a new data layer on top of your existing design elements ... and managed them from a single place, you could use a system to consistently scale it to all platforms.
+
+Essentially, a design token is a design decision: a pairing of the same code and visual properties—design elements you use over and over again in your products—packaged in a format that’s deployable across all platforms. [View Highlight](https://read.readwise.io/read/01j7gb6cqqmf343z3g33y56jkb))
+
+Each token will be given **a name** that corresponds to a certain design decision/option and the defined **value.** [View Highlight](https://read.readwise.io/read/01j7gbesf4pcyz7va8f288kq2j))
+
+are an abstraction layer that makes them **platform-agnostic**. [View Highlight](https://read.readwise.io/read/01j7gbf531ycxc49212f6p6f1r))
+
+Before any coding is implemented in DSM or your SSoT, designers and developers must agree on:
+• What should be a token
+• How those tokens will be used
+• How those tokens will be named [View Highlight](https://read.readwise.io/read/01j7gbjas3kb8h0szhxkkj6rss))
+
+For ease of use, it’s recommended to use Category/Type/Item (CTI) naming conventions to define tokens in a hierarchical tree structure of options and decisions. [View Highlight](https://read.readwise.io/read/01j7gbmfh2rzgrx74f36r0f8s6))
+> [!note]
+> This seems like a good way to categorize pretty much anything
+
+Alias tokens create a hierarchy of options and decisions to control the scope, or intent, of changes. So let’s say you wanted to just change the background color on the buttons. You can create an alias token that reads as an inheritance from the global token as such:
+Using the earlier alias example – color.background.button.primary – the ‘category’ would be ‘color’. Moving down the tree the ‘type’ would be ‘background,’ followed by ‘button’ as the ‘item.’ [View Highlight](https://read.readwise.io/read/01j7gbshpy8mqhasnve88440mw))
+