I will briefly introduce their history, explain the concept and its application to design and code, the role they play in streamlining the design-development collaboration, and how that transfers to organizations managing their branding at scale. <\/p>\n\n\n\n
If you still have no idea what I am talking about, no worries; this article will give you the basics to get started. Ready? Let\u2019s begin.<\/p>\n\n\n\n
But why design tokens at all?<\/strong><\/h2>\n\n\n\nAs designers, we work towards answering user needs, as well as meeting certain business goals. Therefore, before we jump to explaining the article\u2019s subject, I would like to focus first on the business matter design tokens tackle.<\/strong><\/p>\n\n\n\nLooking at the world\u2019s organizations, we can determine one thing they all have in common \u2013 branding. Developed at higher or lower levels, it is the visual language that differentiates one from another and allows them to communicate with their target audience in a particular manner.<\/p>\n\n\n\n
In modern times, when industries rely on far more diverse channels than they used to in the past, considering not only printed media but a myriad of screen devices, design systems \u2013 codified brand languages \u2013 come to the aid of everybody involved in the process of creating communication to help maintain branding usage consistency.<\/p>\n\n\n\n
We can safely say that your organisation\u2019s branding is the pillar of its communication and a key factor in building your audience\u2019s trust.<\/p>\n\n\n\n
Let’s look at tokens as an example<\/strong><\/h3>\n\n\n\nHow would one react to mailing or a website of an institution they trust their funds with, if they saw an outdated logo or interface colours not matching the visual language of the brand. Would it not seem odd and rather suspicious?<\/p>\n\n\n\n
Now, to illustrate the importance of being able to apply branding decisions at scale, I am going to draw on a story that Louis Chenais once used<\/a>.<\/p>\n\n\n\nLet\u2019s imagine you are a designer at a large corporation. As the Head of Design, your new rebranding task is simple \u2013 it requires updating the main brand colour with a new one.<\/p>\n\n\n\n
The rebranding is finalized, and you \u2018only\u2019 need to apply it across all the corporation\u2019s product interfaces, which include:<\/p>\n\n\n\n
\n- company’s website,<\/li>\n\n\n\n
- a web app,<\/li>\n\n\n\n
- an Android app,<\/li>\n\n\n\n
- an iOS app.<\/li>\n<\/ul>\n\n\n\n
\u2018No biggie,\u2019 you think, excited about reaching the goal, and ask the managers of the relevant engineering teams responsible for each product to update the colour from X (the old one) to Y (the new one), providing them with RGB (colour space) values.<\/p>\n\n\n\n
That is where it gets a little wild<\/strong>. You start receiving questions about other colour formats to work on different platforms, and people trying to determine if the update should affect all the UI components. Some managers are not even responding, which makes the update implementation in their areas doubtful.<\/p>\n\n\n\nEnsuring the correct application of this one change proves to be a daunting challenge without a common \u2018design language\u2019 both designers and developers could use.<\/p>\n\n\n\n
So, what business problem do tokens solve?<\/strong><\/h3>\n\n\n\nBack in the day, large organizations wasted months on propagating branding changes to their digital products, which now provide products based on design tokens, taking minutes. What is the business issue that design tokens solve, then? <\/p>\n\n\n\n
Long story short, design token implementation saves your organization\u2019s money as you no longer need months and often hundreds of people\u2019s work to implement simple design decisions into code across various platforms, risking inconsistency and <\/strong>negatively affecting your brand\u2019s image.<\/p>\n\n\n\nAlright, design tokens… what?<\/strong><\/h2>\n\n\n\nLet\u2019s take a step back to the birth of the concept of design tokens at Salesforce around 2015. Jina Anne on the design systems team, accompanied by Jon Levine on the engineering side, coordinated the conceptual, agnostic solution \u2013 a one-location design definition (the \u2018Single Source of Truth\u2019) propagated to all platforms \u2013 coining the term \u2018design tokens.\u2019<\/p>\n\n\n\n
Design tokens are the names that are used to convey design decisions, such as:<\/p>\n\n\n\n
\n- a colour,<\/li>\n\n\n\n
- iconography,<\/li>\n\n\n\n
- a typeface or a font size,<\/li>\n<\/ul>\n\n\n\n
in the design language of your organization. To be used and understood by everyone, those names should be a result of common decisions made by designers and developers with consideration of their workflows.<\/p>\n\n\n\n
We can describe design tokens as<\/p>\n\n\n\n
\n(…) the visual design atoms of the design system \u2014 specifically, they are named entities that store visual design attributes.<\/em><\/p>\nSalesforce Lightning Design System<\/cite><\/blockquote>\n\n\n\nIf you are not familiar with the Atomic Design Methodology, the following illustration depicts the concept on the example of the Instagram interface piece broken down from a page to actual atoms, placing design tokens as subatomic particles, meaning the values that atoms consist of.<\/p>\n\n\n\n![\"Atomic](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image1-3.png\")
<\/a>Fig. 1 Atomic Design Methodology<\/a><\/figcaption><\/figure>\n\n\n\n\nDesign tokens are a language for communicating intent between disparate parts of a system<\/em><\/em>.<\/p>\nEthan Marcotte, “Design-ish systems<\/a>“<\/cite><\/blockquote>\n\n\n\nAnd more clearly?<\/strong><\/h3>\n\n\n\nTo better illustrate the concept, let me use a metaphor.<\/p>\n\n\n\n
Imagine you have a dog. Your dog\u2019s name is \u201cCharlie,\u201d but you also call him \u201cLittle Rascal\u201d and \u201cMuffin,\u201d depending on the circumstance.<\/p>\n\n\n\n![\"Metafora](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image2-2.png\")
<\/a>Fig. 2 Design token concept metaphor<\/figcaption><\/figure>\n\n\n\nRegardless of what you call your dog, it\u2019s still the same pet (contrary to what you may think when it has just destroyed your favorite piece of furniture). Design tokens work the same. In place of using hard-coded values \u2013 like hex for colour, pixel for spacing, etc. \u2013 you name those values. It is like giving nicknames to your design decisions. Let\u2019s have a look at the colour analogy below.<\/p>\n\n\n\n![\"Design](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image3-1.png\")
<\/a>Fig. 3 Design token concept analogy on a colour example<\/a><\/figcaption><\/figure>\n\n\n\nDesign tokens are intended to be used in your design system and across your products. To enable that, you need to transform them for use on various platforms (Web, iOS, or Android) by different teams.<\/p>\n\n\n\n![\"How](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image4-1.png\")
<\/a>Fig. 4 How design decisions are transformed into design tokens to be used in specific platforms<\/a><\/figcaption><\/figure>\n\n\n\nW3C Design Tokens Standard<\/strong><\/h3>\n\n\n\nIf we want to ensure successful design token adoption in multiple apps, we need a standard securing consistency. The World Wide Web Consortium (W3C), led by Tim Berners-Lee and Jeffrey Jaffe, in cooperation with a plethora of organizations and individuals, works to provide the W3C Design Tokens Standard.<\/p>\n\n\n\n
It would allow other tools to communicate in the same \u2018language,\u2019 for example, enabling tokens from Figma to be taken and used in Adobe Illustrator. Imagine how it would speed up the workflow between marketing and product design departments!<\/p>\n\n\n\n
To learn more about the standard, please explore the Official Design Tokens Community Group<\/a> and the W3C Design Tokens Community Group<\/a>.<\/p>\n\n\n\nHow do we build with design tokens?<\/strong><\/strong><\/h2>\n\n\n\nNow that I have covered the absolute basics of the design tokens concept, why don\u2019t we move further and dive a little bit deeper into different types of tokens and how they serve us to build designs?<\/p>\n\n\n\n
Each digital product is a structure of features that consist of interfaces. Every interface is built of components and composed of design tokens.<\/p>\n\n\n\n![\"Product](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image5.png\")
<\/a>Fig. 5 Product structure diagram<\/figcaption><\/figure>\n\n\n\nLet\u2019s break down a button component. You can see all the elements that we would translate to design tokens.<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image6.png\")
<\/a>Fig. 6 The anatomy of a button component showing design tokens composing it<\/figcaption><\/figure>\n\n\n\nSome examples of design tokens<\/strong><\/strong><\/h2>\n\n\n\nHere are some examples of common design tokens used in industry-standard design systems that you could encounter:<\/p>\n\n\n\n
\n- Colour Tokens<\/strong>\n
\n- Primary Colour \u2013 used for primary branding elements and calls to action.<\/span><\/li>\n\n\n\n
- Secondary Colour \u2013 complementary colour for accents and secondary elements.Neutral Colours \u2013 shades of grey used for backgrounds, borders, and text.<\/span><\/li>\n\n\n\n
- Error\/Warning Colours \u2013 distinct colours for indicating errors or warnings in the UI.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Typography Tokens<\/strong>\n
\n- Font Family \u2013 primary and secondary typefaces used for headings and body text.<\/span><\/li>\n\n\n\n
- Font Size \u2013 different sizes for headings, subheadings, body text, etc.Font Weight \u2013 variations in font weight for emphasis and hierarchy.<\/span><\/li>\n\n\n\n
- Line Height \u2013 consistent spacing between lines of text for readability.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Spacing Tokens<\/strong>\n
\n- Padding \u2013 standard padding values for buttons, cards, and containers.<\/span><\/li>\n\n\n\n
- Margin \u2013 standard margin values for spacing between elements.<\/span><\/li>\n\n\n\n
- Grid Spacing \u2013 a grid layout system’s spacing between columns and rows.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Border Tokens<\/strong>\n
\n- Border Radius \u2013 standard border-radius values for rounded corners on elements.<\/span><\/li>\n\n\n\n
- Border Width \u2013 thickness of borders around elements.<\/span><\/li>\n\n\n\n
- Border Colour \u2013 standard colours for borders around elements.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Shadow Tokens<\/strong>\n
\n- Box Shadow \u2013 standard shadow values for adding depth and dimension to elements.<\/span><\/li>\n\n\n\n
- Text Shadow \u2013 shadow values for enhancing readability and contrast of text.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Icon Tokens<\/strong>\n
\n- Icon Size \u2013 standard sizes for icons used throughout the UI.<\/span><\/li>\n\n\n\n
- Icon Colour \u2013 default colour for icons or variations for different states (active, inactive, etc.).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Animation Tokens<\/strong>\n
\n- Transition Duration \u2013 duration of transitions between different states or interactions.<\/span><\/li>\n\n\n\n
- Animation Timing Function \u2013 easing functions for smooth animation effects.<\/span><\/li>\n\n\n\n
- Animation Keyframes \u2013 keyframes for more complex animation sequences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Accessibility Tokens<\/strong>\n
\n- Contrast Ratio \u2013 minimum contrast ratio between text and background colours for readability.<\/span><\/li>\n\n\n\n
- Focus Indicator \u2013 styles indicating focus on interactive elements for keyboard navigation.<\/span><\/li>\n\n\n\n
- Screen Reader Text \u2013 hidden text for screen readers to convey information to visually impaired users.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Types of tokens<\/strong><\/h2>\n\n\n\nWe divide tokens into three categories (types). Each token type signifies a level of assigned context.<\/p>\n\n\n\n![\"Token](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image7.png\")
<\/a>Fig. 7 Token types on examples<\/figcaption><\/figure>\n\n\n\nGlobal tokens<\/strong><\/h3>\n\n\n\nTier 1 (global) tokens \u2013 primitive values <\/strong>\u2013 are basic, contextless units of a Design Token System.<\/strong><\/p>\n\n\n\nWhether you are a designer, a developer, or a project manager, you probably work with the brand colours of your organization, and there is a high chance that you operate on the hex (or any other) values in communication regarding those colours.<\/p>\n\n\n\n![\"Hex](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image8.png\")
<\/a>Fig. 8 Hex applied directly to UI elements<\/figcaption><\/figure>\n\n\n\nWhy is it not the most comfortable solution?<\/strong> Let’s see:<\/p>\n\n\n\n\n- unless you know your hexes by heart (and let’s be honest \u2013 you might be the only one in the organization), the hex code does not describe the actual colour<\/strong>, making it unrecognizable,<\/li>\n\n\n\n
- it does not give any information about the design decision behind this colour<\/strong> (where it is supposed to be used, etc.),<\/li>\n\n\n\n
- it is easy to misspell the hex<\/strong>, leading to visual inconsistencies within the product.<\/li>\n<\/ul>\n\n\n\n
Global tokens<\/strong> are names you give, for example, to hex values, to give an initial, consistent, and contextless description of those values that would be understandable to everybody working with them. This allows avoiding any ‘fifty-shades-of-grey’ situations \u2013 accidentally ending up with several shades of your brand colour used in your product.<\/p>\n\n\n\n![\"Global](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image9.png\")
<\/a>Fig. 9 Global (core) token example<\/figcaption><\/figure>\n\n\n\nAccording to the scheme above, naming your hex value ‘colour.blue.600’ instead of using the hex value benefits you in several manners:<\/p>\n\n\n\n
\n- colour is easily recognizable now,<\/li>\n\n\n\n
- tokenized value is now defined as a variable in code, so any misspelling will be signaled as a code error.<\/li>\n<\/ul>\n\n\n\n
![\"Example](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image10.png\")
<\/a>Fig 10 Example of global tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\nDespite the obvious advantages<\/strong> of using global tokens, this is still not the perfect solution<\/strong>, and relying only on this type of token does not convey information about use cases of the colour nor allows automated, narrowed-down colour changes, affecting only particular groups of components. Instead, the dev team would have to look for suitable use cases and change the colour manually. What a waste of time, right?<\/p>\n\n\n\nAlias tokens<\/strong><\/strong><\/h3>\n\n\n\nHere comes the next design token type. Tier 2 (alias or system) tokens <\/strong>\u2013 context-specific names referring to design decisions behind values (what they ‘do\u2019). <\/p>\n\n\n\n#0E6EE0, now called \u2018colour.blue.600′, will also exist in the system under different aliases, depicting its use cases. For example, \u2018colour.interactive.primary.background\u2019 would mean this colour is supposed to be used for the background of primary, interactive UI elements.<\/p>\n\n\n\n![\"System](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image11.png\")
<\/a>Fig. 11 System (alias) token example<\/figcaption><\/figure>\n\n\n\nAs you can see in the example above, in case of any colour change, this operation would only affect the background of the primary interactive elements of the user interface, eliminating those without a blue background.<\/p>\n\n\n\n
Introducing alias tokens to code results positively in:<\/strong><\/p>\n\n\n\n\n- elimination of possible mistakes when copying to code (just like global, alias tokens are variables in code as well),<\/li>\n\n\n\n
- making the token\u2019s purpose clear to both design and dev teams,<\/li>\n\n\n\n
- speeding up the update process significantly, enabling devs to update component properties at a large scale easily,<\/li>\n\n\n\n
- empowering developers and designers, allowing detection of potential incorrect use of properties (like text colour applied to icons) and correcting such errors by developers themselves or in communication with design,<\/li>\n\n\n\n
- making designers rethink the need for additional values, such as colours, in the design system, reducing potential clutter and unnecessary system complexity.<\/li>\n<\/ul>\n\n\n\n
![\"Example](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image12.png\")
<\/a>Fig 12 Example of alias tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\nWhen should you reach for alias tokens?<\/strong><\/p>\n\n\n\n\n- For example, tokenizing every colour across your design system would result in a giant global token set to maintain.<\/li>\n\n\n\n
- If global tokens apply to text, icon, background, or border across multiple pages.<\/li>\n\n\n\n
- If you have a multi-brand\/theme\/mode design system.<\/li>\n<\/ul>\n\n\n\n
Example:<\/p>\n\n\n\n![\"Multi-theme](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image13.png\")
<\/a>Fig. 13 Multi-theme design system alias tokens example<\/a><\/figcaption><\/figure>\n\n\n\nOf course, using alias tokens comes with the responsibility of maintaining a larger set of colours and requires thorough and thoughtful system planning; however, in the long term, the perks prove to be worth the additional effort.<\/p>\n\n\n\n
There are cases when it is not advisable to rely on alias tokens. For example, if there is a colour that you need to use in your product, but it is not part of your brand’s visual language, or it would be used only once or for one particular UI element that should not be affected by global design decision changes.<\/p>\n\n\n\n
Component specific tokens<\/strong><\/strong><\/h3>\n\n\n\nFor unique UI elements, it is appropriate to use Tier 3 (component-specific) tokens dedicated to distinct components and their properties<\/strong>.<\/p>\n\n\n\n![\"Component](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image14.png\")
<\/a>Fig. 14 Component tokens example<\/figcaption><\/figure>\n\n\n\nAll of the above names (design tokens) mean the same hex value but in different contexts or regarding a different design system component \u2013 when you apply component-specific tokens, any possible design decision changes \u2013 e.g., colour updates \u2013 applied to it will affect only this component and the property the token refers to. In our case, it would be only the background colour of the primary button in its default state.<\/p>\n\n\n\n
As you can see on the diagram below, where I switch blue to pink, this is how tokens allow me to be specific about design decision modifications. You can apply particular changes (like colour) to selected tokens, affecting only particular UI elements.<\/p>\n\n\n\n![\"Exemplary](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image15.png\")
<\/a>Fig. 15 Exemplary design token structure \u2013 from a core token to components<\/figcaption><\/figure>\n\n\n\n![\"Exemplary](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image16.png\")
<\/a>Fig. 16 Exemplary design token structure \u2013 colour change<\/figcaption><\/figure>\n\n\n\nOkay, but how do we come up with token names?<\/strong><\/h2>\n\n\n\nI will not tell you exactly what naming convention to aim for when establishing a tokens system for your product, as it should be tailored to your product’s specifics and team preferences. Naming takes time, as teams need to invest effort into finding the perfect logic for them. Although looking for inspiration in open design systems is good, you need to remember that what works for one product does not necessarily have to be an ideal solution for yours.<\/p>\n\n\n\n
I will not elaborate too extensively on token naming, as it is a vast topic, worth in-depth exploration once you embark on a design token system building journey. However, let me share some good practices to consider while developing a design token naming system that would serve an organization well.<\/p>\n\n\n\n
Token names \u2013 best practices<\/strong><\/h3>\n\n\n\nMost importantly, token names should be:<\/p>\n\n\n\n
\n- as short as possible \u2013 to not overcomplicate the system,<\/li>\n\n\n\n
- meaningful \u2013 to communicate design decisions clearly,<\/li>\n\n\n\n
- easy to understand \u2013 for easy orientation and potential onboarding to the system,<\/li>\n\n\n\n
- modular \u2013 for simplicity of building the system,<\/li>\n\n\n\n
- consistent \u2013 to reflect the design system properly and facilitate understanding of the naming convention.<\/li>\n<\/ul>\n\n\n\n
When setting a naming convention for alias tokens, a good start will be building names about:<\/p>\n\n\n\n
\n- category \u2013 the attribute a token refers to, e.g., colour, typography, spacing, shadow, border radius, etc.,<\/li>\n\n\n\n
- concept \u2013 a situation a token describes, e.g., Information, warning, success, etc.,<\/li>\n\n\n\n
- purpose (property) \u2013 where in your UI a token will be used, e.g., text, icon, background, border, heading, body, etc.,<\/li>\n\n\n\n
- variant \u2013 potential variants of a token, e.g., states (active, inactive, disabled), sizes (XL, L, M, S), etc.,<\/li>\n\n\n\n
- component (to be avoided unless specifically needed) \u2013 a component that will be affected by a token, e.g., button, checkbox, link, etc.<\/li>\n<\/ul>\n\n\n\n
Token names \u2013 examples<\/strong><\/h3>\n\n\n\nSuch convention could look like this:<\/p>\n\n\n\n
Category.purpose.variant <\/strong><\/p>\n\n\n\nFor example:<\/p>\n\n\n\n
Colour.background.active<\/strong><\/p>\n\n\n\n(describing the design decision made to assign a particular colour to the background of active UI elements)<\/p>\n\n\n\n
Next, you should focus on providing as much context as you can. Remembering that keeping token names as short as possible is worth making a token name a bit longer if it reflects the design decision well. After all, design tokens are not UI elements that end users would see but text information stored in code that developers operate on. Therefore, the more context they convey, the better.<\/p>\n\n\n\n
Design token naming conventions, especially those for multi-brand design systems that require multiple themes (visual language sets, e.g., specific brand colours, typography, iconography, etc.), may consist of many naming levels.<\/p>\n\n\n\n
For instance, if you need to distinguish tokens across brands in your design system, you may need to introduce product namespacing, which might look like this:<\/p>\n\n\n\n
brand<\/strong>.product.colour.information.background<\/strong> Namespacing allows developers to distinguish tokens in code and operate on them more comfortably.<\/p>\n\n\n\nWe have the system established. How do we manage it all together?<\/strong><\/h2>\n\n\n\nNow that you know the basics of the design tokens concept and token naming conventions, it is time to present how using them streamlines design-dev collaboration.<\/p>\n\n\n\n
For better contrast, let me introduce you to the design handoff process in its classic shape, with no use of design tokens.<\/p>\n\n\n\n
Classic process<\/strong><\/h3>\n\n\n\nCommonly, we complete the following handoff steps:<\/p>\n\n\n\n
\n- The designer delivers the UI design in Figma<\/a> (the most popular collaborative interface design tool).<\/li>\n\n\n\n
- The designer prepares UI specs (design documentation with handoff notes for dev).<\/li>\n\n\n\n
- The designer hands off the design file and has a call with the developer\/dev team, who will be implementing the design, to discuss the specifics.<\/li>\n\n\n\n
- Developers inspect the file and start coding.
<\/li>\n<\/ol>\n\n\n\nIt seems quite simple at this level, considering the design will never change. However, product design is about evolution, and design changes are inevitable. Therefore, the above process does not end on the fourth step. Over time, as the brand evolves, there are more steps:<\/p>\n\n\n\n
\n- Let’s say the brand colour changed, and the designer needs to update the design; let developers know so they can update the code accordingly.<\/li>\n\n\n\n
- There are also times when developers need to change something in the code, so they need to inform the designer to reflect those changes in the design.<\/li>\n<\/ul>\n\n\n\n
The more steps and iterations, the more space for mistakes. And let\u2019s be honest, overall, this amount of communication back and forth for just one colour update is a lot considering the daily workload.<\/p>\n\n\n\n![\"Classic](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image17.png\")
<\/a>Fig. 17 Classic design handoff process (simplified scheme)<\/a><\/figcaption><\/figure>\n\n\n\nWe want this process to be as simple and automated as possible (like on the diagram below) to save valuable time for both design and dev teams.<\/p>\n\n\n\n![\"Enhanced](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/07\/image18.png\")
<\/a>Fig. 18
Looking at the world\u2019s organizations, we can determine one thing they all have in common \u2013 branding. Developed at higher or lower levels, it is the visual language that differentiates one from another and allows them to communicate with their target audience in a particular manner.<\/p>\n\n\n\n
In modern times, when industries rely on far more diverse channels than they used to in the past, considering not only printed media but a myriad of screen devices, design systems \u2013 codified brand languages \u2013 come to the aid of everybody involved in the process of creating communication to help maintain branding usage consistency.<\/p>\n\n\n\n
We can safely say that your organisation\u2019s branding is the pillar of its communication and a key factor in building your audience\u2019s trust.<\/p>\n\n\n\n
Let’s look at tokens as an example<\/strong><\/h3>\n\n\n\nHow would one react to mailing or a website of an institution they trust their funds with, if they saw an outdated logo or interface colours not matching the visual language of the brand. Would it not seem odd and rather suspicious?<\/p>\n\n\n\n
Now, to illustrate the importance of being able to apply branding decisions at scale, I am going to draw on a story that Louis Chenais once used<\/a>.<\/p>\n\n\n\nLet\u2019s imagine you are a designer at a large corporation. As the Head of Design, your new rebranding task is simple \u2013 it requires updating the main brand colour with a new one.<\/p>\n\n\n\n
The rebranding is finalized, and you \u2018only\u2019 need to apply it across all the corporation\u2019s product interfaces, which include:<\/p>\n\n\n\n
\n- company’s website,<\/li>\n\n\n\n
- a web app,<\/li>\n\n\n\n
- an Android app,<\/li>\n\n\n\n
- an iOS app.<\/li>\n<\/ul>\n\n\n\n
\u2018No biggie,\u2019 you think, excited about reaching the goal, and ask the managers of the relevant engineering teams responsible for each product to update the colour from X (the old one) to Y (the new one), providing them with RGB (colour space) values.<\/p>\n\n\n\n
That is where it gets a little wild<\/strong>. You start receiving questions about other colour formats to work on different platforms, and people trying to determine if the update should affect all the UI components. Some managers are not even responding, which makes the update implementation in their areas doubtful.<\/p>\n\n\n\nEnsuring the correct application of this one change proves to be a daunting challenge without a common \u2018design language\u2019 both designers and developers could use.<\/p>\n\n\n\n
So, what business problem do tokens solve?<\/strong><\/h3>\n\n\n\nBack in the day, large organizations wasted months on propagating branding changes to their digital products, which now provide products based on design tokens, taking minutes. What is the business issue that design tokens solve, then? <\/p>\n\n\n\n
Long story short, design token implementation saves your organization\u2019s money as you no longer need months and often hundreds of people\u2019s work to implement simple design decisions into code across various platforms, risking inconsistency and <\/strong>negatively affecting your brand\u2019s image.<\/p>\n\n\n\nAlright, design tokens… what?<\/strong><\/h2>\n\n\n\nLet\u2019s take a step back to the birth of the concept of design tokens at Salesforce around 2015. Jina Anne on the design systems team, accompanied by Jon Levine on the engineering side, coordinated the conceptual, agnostic solution \u2013 a one-location design definition (the \u2018Single Source of Truth\u2019) propagated to all platforms \u2013 coining the term \u2018design tokens.\u2019<\/p>\n\n\n\n
Design tokens are the names that are used to convey design decisions, such as:<\/p>\n\n\n\n
\n- a colour,<\/li>\n\n\n\n
- iconography,<\/li>\n\n\n\n
- a typeface or a font size,<\/li>\n<\/ul>\n\n\n\n
in the design language of your organization. To be used and understood by everyone, those names should be a result of common decisions made by designers and developers with consideration of their workflows.<\/p>\n\n\n\n
We can describe design tokens as<\/p>\n\n\n\n
\n(…) the visual design atoms of the design system \u2014 specifically, they are named entities that store visual design attributes.<\/em><\/p>\nSalesforce Lightning Design System<\/cite><\/blockquote>\n\n\n\nIf you are not familiar with the Atomic Design Methodology, the following illustration depicts the concept on the example of the Instagram interface piece broken down from a page to actual atoms, placing design tokens as subatomic particles, meaning the values that atoms consist of.<\/p>\n\n\n\n<\/a>Fig. 1 Atomic Design Methodology<\/a><\/figcaption><\/figure>\n\n\n\n\nDesign tokens are a language for communicating intent between disparate parts of a system<\/em><\/em>.<\/p>\nEthan Marcotte, “Design-ish systems<\/a>“<\/cite><\/blockquote>\n\n\n\nAnd more clearly?<\/strong><\/h3>\n\n\n\nTo better illustrate the concept, let me use a metaphor.<\/p>\n\n\n\n
Imagine you have a dog. Your dog\u2019s name is \u201cCharlie,\u201d but you also call him \u201cLittle Rascal\u201d and \u201cMuffin,\u201d depending on the circumstance.<\/p>\n\n\n\n<\/a>Fig. 2 Design token concept metaphor<\/figcaption><\/figure>\n\n\n\nRegardless of what you call your dog, it\u2019s still the same pet (contrary to what you may think when it has just destroyed your favorite piece of furniture). Design tokens work the same. In place of using hard-coded values \u2013 like hex for colour, pixel for spacing, etc. \u2013 you name those values. It is like giving nicknames to your design decisions. Let\u2019s have a look at the colour analogy below.<\/p>\n\n\n\n<\/a>Fig. 3 Design token concept analogy on a colour example<\/a><\/figcaption><\/figure>\n\n\n\nDesign tokens are intended to be used in your design system and across your products. To enable that, you need to transform them for use on various platforms (Web, iOS, or Android) by different teams.<\/p>\n\n\n\n<\/a>Fig. 4 How design decisions are transformed into design tokens to be used in specific platforms<\/a><\/figcaption><\/figure>\n\n\n\nW3C Design Tokens Standard<\/strong><\/h3>\n\n\n\nIf we want to ensure successful design token adoption in multiple apps, we need a standard securing consistency. The World Wide Web Consortium (W3C), led by Tim Berners-Lee and Jeffrey Jaffe, in cooperation with a plethora of organizations and individuals, works to provide the W3C Design Tokens Standard.<\/p>\n\n\n\n
It would allow other tools to communicate in the same \u2018language,\u2019 for example, enabling tokens from Figma to be taken and used in Adobe Illustrator. Imagine how it would speed up the workflow between marketing and product design departments!<\/p>\n\n\n\n
To learn more about the standard, please explore the Official Design Tokens Community Group<\/a> and the W3C Design Tokens Community Group<\/a>.<\/p>\n\n\n\nHow do we build with design tokens?<\/strong><\/strong><\/h2>\n\n\n\nNow that I have covered the absolute basics of the design tokens concept, why don\u2019t we move further and dive a little bit deeper into different types of tokens and how they serve us to build designs?<\/p>\n\n\n\n
Each digital product is a structure of features that consist of interfaces. Every interface is built of components and composed of design tokens.<\/p>\n\n\n\n<\/a>Fig. 5 Product structure diagram<\/figcaption><\/figure>\n\n\n\nLet\u2019s break down a button component. You can see all the elements that we would translate to design tokens.<\/p>\n\n\n\n<\/a>Fig. 6 The anatomy of a button component showing design tokens composing it<\/figcaption><\/figure>\n\n\n\nSome examples of design tokens<\/strong><\/strong><\/h2>\n\n\n\nHere are some examples of common design tokens used in industry-standard design systems that you could encounter:<\/p>\n\n\n\n
\n- Colour Tokens<\/strong>\n
\n- Primary Colour \u2013 used for primary branding elements and calls to action.<\/span><\/li>\n\n\n\n
- Secondary Colour \u2013 complementary colour for accents and secondary elements.Neutral Colours \u2013 shades of grey used for backgrounds, borders, and text.<\/span><\/li>\n\n\n\n
- Error\/Warning Colours \u2013 distinct colours for indicating errors or warnings in the UI.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Typography Tokens<\/strong>\n
\n- Font Family \u2013 primary and secondary typefaces used for headings and body text.<\/span><\/li>\n\n\n\n
- Font Size \u2013 different sizes for headings, subheadings, body text, etc.Font Weight \u2013 variations in font weight for emphasis and hierarchy.<\/span><\/li>\n\n\n\n
- Line Height \u2013 consistent spacing between lines of text for readability.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Spacing Tokens<\/strong>\n
\n- Padding \u2013 standard padding values for buttons, cards, and containers.<\/span><\/li>\n\n\n\n
- Margin \u2013 standard margin values for spacing between elements.<\/span><\/li>\n\n\n\n
- Grid Spacing \u2013 a grid layout system’s spacing between columns and rows.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Border Tokens<\/strong>\n
\n- Border Radius \u2013 standard border-radius values for rounded corners on elements.<\/span><\/li>\n\n\n\n
- Border Width \u2013 thickness of borders around elements.<\/span><\/li>\n\n\n\n
- Border Colour \u2013 standard colours for borders around elements.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Shadow Tokens<\/strong>\n
\n- Box Shadow \u2013 standard shadow values for adding depth and dimension to elements.<\/span><\/li>\n\n\n\n
- Text Shadow \u2013 shadow values for enhancing readability and contrast of text.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Icon Tokens<\/strong>\n
\n- Icon Size \u2013 standard sizes for icons used throughout the UI.<\/span><\/li>\n\n\n\n
- Icon Colour \u2013 default colour for icons or variations for different states (active, inactive, etc.).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Animation Tokens<\/strong>\n
\n- Transition Duration \u2013 duration of transitions between different states or interactions.<\/span><\/li>\n\n\n\n
- Animation Timing Function \u2013 easing functions for smooth animation effects.<\/span><\/li>\n\n\n\n
- Animation Keyframes \u2013 keyframes for more complex animation sequences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
\n- Accessibility Tokens<\/strong>\n
\n- Contrast Ratio \u2013 minimum contrast ratio between text and background colours for readability.<\/span><\/li>\n\n\n\n
- Focus Indicator \u2013 styles indicating focus on interactive elements for keyboard navigation.<\/span><\/li>\n\n\n\n
- Screen Reader Text \u2013 hidden text for screen readers to convey information to visually impaired users.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Types of tokens<\/strong><\/h2>\n\n\n\nWe divide tokens into three categories (types). Each token type signifies a level of assigned context.<\/p>\n\n\n\n<\/a>Fig. 7 Token types on examples<\/figcaption><\/figure>\n\n\n\nGlobal tokens<\/strong><\/h3>\n\n\n\nTier 1 (global) tokens \u2013 primitive values <\/strong>\u2013 are basic, contextless units of a Design Token System.<\/strong><\/p>\n\n\n\nWhether you are a designer, a developer, or a project manager, you probably work with the brand colours of your organization, and there is a high chance that you operate on the hex (or any other) values in communication regarding those colours.<\/p>\n\n\n\n<\/a>Fig. 8 Hex applied directly to UI elements<\/figcaption><\/figure>\n\n\n\nWhy is it not the most comfortable solution?<\/strong> Let’s see:<\/p>\n\n\n\n\n- unless you know your hexes by heart (and let’s be honest \u2013 you might be the only one in the organization), the hex code does not describe the actual colour<\/strong>, making it unrecognizable,<\/li>\n\n\n\n
- it does not give any information about the design decision behind this colour<\/strong> (where it is supposed to be used, etc.),<\/li>\n\n\n\n
- it is easy to misspell the hex<\/strong>, leading to visual inconsistencies within the product.<\/li>\n<\/ul>\n\n\n\n
Global tokens<\/strong> are names you give, for example, to hex values, to give an initial, consistent, and contextless description of those values that would be understandable to everybody working with them. This allows avoiding any ‘fifty-shades-of-grey’ situations \u2013 accidentally ending up with several shades of your brand colour used in your product.<\/p>\n\n\n\n<\/a>Fig. 9 Global (core) token example<\/figcaption><\/figure>\n\n\n\nAccording to the scheme above, naming your hex value ‘colour.blue.600’ instead of using the hex value benefits you in several manners:<\/p>\n\n\n\n
\n- colour is easily recognizable now,<\/li>\n\n\n\n
- tokenized value is now defined as a variable in code, so any misspelling will be signaled as a code error.<\/li>\n<\/ul>\n\n\n\n
<\/a>Fig 10 Example of global tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\nDespite the obvious advantages<\/strong> of using global tokens, this is still not the perfect solution<\/strong>, and relying only on this type of token does not convey information about use cases of the colour nor allows automated, narrowed-down colour changes, affecting only particular groups of components. Instead, the dev team would have to look for suitable use cases and change the colour manually. What a waste of time, right?<\/p>\n\n\n\nAlias tokens<\/strong><\/strong><\/h3>\n\n\n\nHere comes the next design token type. Tier 2 (alias or system) tokens <\/strong>\u2013 context-specific names referring to design decisions behind values (what they ‘do\u2019). <\/p>\n\n\n\n#0E6EE0, now called \u2018colour.blue.600′, will also exist in the system under different aliases, depicting its use cases. For example, \u2018colour.interactive.primary.background\u2019 would mean this colour is supposed to be used for the background of primary, interactive UI elements.<\/p>\n\n\n\n<\/a>Fig. 11 System (alias) token example<\/figcaption><\/figure>\n\n\n\nAs you can see in the example above, in case of any colour change, this operation would only affect the background of the primary interactive elements of the user interface, eliminating those without a blue background.<\/p>\n\n\n\n
Introducing alias tokens to code results positively in:<\/strong><\/p>\n\n\n\n\n- elimination of possible mistakes when copying to code (just like global, alias tokens are variables in code as well),<\/li>\n\n\n\n
- making the token\u2019s purpose clear to both design and dev teams,<\/li>\n\n\n\n
- speeding up the update process significantly, enabling devs to update component properties at a large scale easily,<\/li>\n\n\n\n
- empowering developers and designers, allowing detection of potential incorrect use of properties (like text colour applied to icons) and correcting such errors by developers themselves or in communication with design,<\/li>\n\n\n\n
- making designers rethink the need for additional values, such as colours, in the design system, reducing potential clutter and unnecessary system complexity.<\/li>\n<\/ul>\n\n\n\n
<\/a>Fig 12 Example of alias tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\nWhen should you reach for alias tokens?<\/strong><\/p>\n\n\n\n\n- For example, tokenizing every colour across your design system would result in a giant global token set to maintain.<\/li>\n\n\n\n
- If global tokens apply to text, icon, background, or border across multiple pages.<\/li>\n\n\n\n
- If you have a multi-brand\/theme\/mode design system.<\/li>\n<\/ul>\n\n\n\n
Example:<\/p>\n\n\n\n<\/a>Fig. 13 Multi-theme design system alias tokens example<\/a><\/figcaption><\/figure>\n\n\n\nOf course, using alias tokens comes with the responsibility of maintaining a larger set of colours and requires thorough and thoughtful system planning; however, in the long term, the perks prove to be worth the additional effort.<\/p>\n\n\n\n
There are cases when it is not advisable to rely on alias tokens. For example, if there is a colour that you need to use in your product, but it is not part of your brand’s visual language, or it would be used only once or for one particular UI element that should not be affected by global design decision changes.<\/p>\n\n\n\n
Component specific tokens<\/strong><\/strong><\/h3>\n\n\n\nFor unique UI elements, it is appropriate to use Tier 3 (component-specific) tokens dedicated to distinct components and their properties<\/strong>.<\/p>\n\n\n\n<\/a>Fig. 14 Component tokens example<\/figcaption><\/figure>\n\n\n\nAll of the above names (design tokens) mean the same hex value but in different contexts or regarding a different design system component \u2013 when you apply component-specific tokens, any possible design decision changes \u2013 e.g., colour updates \u2013 applied to it will affect only this component and the property the token refers to. In our case, it would be only the background colour of the primary button in its default state.<\/p>\n\n\n\n
As you can see on the diagram below, where I switch blue to pink, this is how tokens allow me to be specific about design decision modifications. You can apply particular changes (like colour) to selected tokens, affecting only particular UI elements.<\/p>\n\n\n\n<\/a>Fig. 15 Exemplary design token structure \u2013 from a core token to components<\/figcaption><\/figure>\n\n\n\n<\/a>Fig. 16 Exemplary design token structure \u2013 colour change<\/figcaption><\/figure>\n\n\n\nOkay, but how do we come up with token names?<\/strong><\/h2>\n\n\n\nI will not tell you exactly what naming convention to aim for when establishing a tokens system for your product, as it should be tailored to your product’s specifics and team preferences. Naming takes time, as teams need to invest effort into finding the perfect logic for them. Although looking for inspiration in open design systems is good, you need to remember that what works for one product does not necessarily have to be an ideal solution for yours.<\/p>\n\n\n\n
I will not elaborate too extensively on token naming, as it is a vast topic, worth in-depth exploration once you embark on a design token system building journey. However, let me share some good practices to consider while developing a design token naming system that would serve an organization well.<\/p>\n\n\n\n
Token names \u2013 best practices<\/strong><\/h3>\n\n\n\nMost importantly, token names should be:<\/p>\n\n\n\n
\n- as short as possible \u2013 to not overcomplicate the system,<\/li>\n\n\n\n
- meaningful \u2013 to communicate design decisions clearly,<\/li>\n\n\n\n
- easy to understand \u2013 for easy orientation and potential onboarding to the system,<\/li>\n\n\n\n
- modular \u2013 for simplicity of building the system,<\/li>\n\n\n\n
- consistent \u2013 to reflect the design system properly and facilitate understanding of the naming convention.<\/li>\n<\/ul>\n\n\n\n
When setting a naming convention for alias tokens, a good start will be building names about:<\/p>\n\n\n\n
\n- category \u2013 the attribute a token refers to, e.g., colour, typography, spacing, shadow, border radius, etc.,<\/li>\n\n\n\n
- concept \u2013 a situation a token describes, e.g., Information, warning, success, etc.,<\/li>\n\n\n\n
- purpose (property) \u2013 where in your UI a token will be used, e.g., text, icon, background, border, heading, body, etc.,<\/li>\n\n\n\n
- variant \u2013 potential variants of a token, e.g., states (active, inactive, disabled), sizes (XL, L, M, S), etc.,<\/li>\n\n\n\n
- component (to be avoided unless specifically needed) \u2013 a component that will be affected by a token, e.g., button, checkbox, link, etc.<\/li>\n<\/ul>\n\n\n\n
Token names \u2013 examples<\/strong><\/h3>\n\n\n\nSuch convention could look like this:<\/p>\n\n\n\n
Category.purpose.variant <\/strong><\/p>\n\n\n\nFor example:<\/p>\n\n\n\n
Colour.background.active<\/strong><\/p>\n\n\n\n(describing the design decision made to assign a particular colour to the background of active UI elements)<\/p>\n\n\n\n
Next, you should focus on providing as much context as you can. Remembering that keeping token names as short as possible is worth making a token name a bit longer if it reflects the design decision well. After all, design tokens are not UI elements that end users would see but text information stored in code that developers operate on. Therefore, the more context they convey, the better.<\/p>\n\n\n\n
Design token naming conventions, especially those for multi-brand design systems that require multiple themes (visual language sets, e.g., specific brand colours, typography, iconography, etc.), may consist of many naming levels.<\/p>\n\n\n\n
For instance, if you need to distinguish tokens across brands in your design system, you may need to introduce product namespacing, which might look like this:<\/p>\n\n\n\n
brand<\/strong>.product.colour.information.background<\/strong> Namespacing allows developers to distinguish tokens in code and operate on them more comfortably.<\/p>\n\n\n\nWe have the system established. How do we manage it all together?<\/strong><\/h2>\n\n\n\nNow that you know the basics of the design tokens concept and token naming conventions, it is time to present how using them streamlines design-dev collaboration.<\/p>\n\n\n\n
For better contrast, let me introduce you to the design handoff process in its classic shape, with no use of design tokens.<\/p>\n\n\n\n
Classic process<\/strong><\/h3>\n\n\n\nCommonly, we complete the following handoff steps:<\/p>\n\n\n\n
\n- The designer delivers the UI design in Figma<\/a> (the most popular collaborative interface design tool).<\/li>\n\n\n\n
- The designer prepares UI specs (design documentation with handoff notes for dev).<\/li>\n\n\n\n
- The designer hands off the design file and has a call with the developer\/dev team, who will be implementing the design, to discuss the specifics.<\/li>\n\n\n\n
- Developers inspect the file and start coding.
<\/li>\n<\/ol>\n\n\n\nIt seems quite simple at this level, considering the design will never change. However, product design is about evolution, and design changes are inevitable. Therefore, the above process does not end on the fourth step. Over time, as the brand evolves, there are more steps:<\/p>\n\n\n\n
\n- Let’s say the brand colour changed, and the designer needs to update the design; let developers know so they can update the code accordingly.<\/li>\n\n\n\n
- There are also times when developers need to change something in the code, so they need to inform the designer to reflect those changes in the design.<\/li>\n<\/ul>\n\n\n\n
The more steps and iterations, the more space for mistakes. And let\u2019s be honest, overall, this amount of communication back and forth for just one colour update is a lot considering the daily workload.<\/p>\n\n\n\n<\/a>Fig. 17 Classic design handoff process (simplified scheme)<\/a><\/figcaption><\/figure>\n\n\n\nWe want this process to be as simple and automated as possible (like on the diagram below) to save valuable time for both design and dev teams.<\/p>\n\n\n\n<\/a>Fig. 18
Let\u2019s imagine you are a designer at a large corporation. As the Head of Design, your new rebranding task is simple \u2013 it requires updating the main brand colour with a new one.<\/p>\n\n\n\n
The rebranding is finalized, and you \u2018only\u2019 need to apply it across all the corporation\u2019s product interfaces, which include:<\/p>\n\n\n\n
- \n
- company’s website,<\/li>\n\n\n\n
- a web app,<\/li>\n\n\n\n
- an Android app,<\/li>\n\n\n\n
- an iOS app.<\/li>\n<\/ul>\n\n\n\n
\u2018No biggie,\u2019 you think, excited about reaching the goal, and ask the managers of the relevant engineering teams responsible for each product to update the colour from X (the old one) to Y (the new one), providing them with RGB (colour space) values.<\/p>\n\n\n\n
That is where it gets a little wild<\/strong>. You start receiving questions about other colour formats to work on different platforms, and people trying to determine if the update should affect all the UI components. Some managers are not even responding, which makes the update implementation in their areas doubtful.<\/p>\n\n\n\n
Ensuring the correct application of this one change proves to be a daunting challenge without a common \u2018design language\u2019 both designers and developers could use.<\/p>\n\n\n\n
So, what business problem do tokens solve?<\/strong><\/h3>\n\n\n\n
Back in the day, large organizations wasted months on propagating branding changes to their digital products, which now provide products based on design tokens, taking minutes. What is the business issue that design tokens solve, then? <\/p>\n\n\n\n
Long story short, design token implementation saves your organization\u2019s money as you no longer need months and often hundreds of people\u2019s work to implement simple design decisions into code across various platforms, risking inconsistency and <\/strong>negatively affecting your brand\u2019s image.<\/p>\n\n\n\n
Alright, design tokens… what?<\/strong><\/h2>\n\n\n\n
Let\u2019s take a step back to the birth of the concept of design tokens at Salesforce around 2015. Jina Anne on the design systems team, accompanied by Jon Levine on the engineering side, coordinated the conceptual, agnostic solution \u2013 a one-location design definition (the \u2018Single Source of Truth\u2019) propagated to all platforms \u2013 coining the term \u2018design tokens.\u2019<\/p>\n\n\n\n
Design tokens are the names that are used to convey design decisions, such as:<\/p>\n\n\n\n
- \n
- a colour,<\/li>\n\n\n\n
- iconography,<\/li>\n\n\n\n
- a typeface or a font size,<\/li>\n<\/ul>\n\n\n\n
in the design language of your organization. To be used and understood by everyone, those names should be a result of common decisions made by designers and developers with consideration of their workflows.<\/p>\n\n\n\n
We can describe design tokens as<\/p>\n\n\n\n
\n
(…) the visual design atoms of the design system \u2014 specifically, they are named entities that store visual design attributes.<\/em><\/p>\nSalesforce Lightning Design System<\/cite><\/blockquote>\n\n\n\n
If you are not familiar with the Atomic Design Methodology, the following illustration depicts the concept on the example of the Instagram interface piece broken down from a page to actual atoms, placing design tokens as subatomic particles, meaning the values that atoms consist of.<\/p>\n\n\n\n
<\/a>Fig. 1 Atomic Design Methodology<\/a><\/figcaption><\/figure>\n\n\n\n \n
Design tokens are a language for communicating intent between disparate parts of a system<\/em><\/em>.<\/p>\nEthan Marcotte, “Design-ish systems<\/a>“<\/cite><\/blockquote>\n\n\n\n
And more clearly?<\/strong><\/h3>\n\n\n\n
To better illustrate the concept, let me use a metaphor.<\/p>\n\n\n\n
Imagine you have a dog. Your dog\u2019s name is \u201cCharlie,\u201d but you also call him \u201cLittle Rascal\u201d and \u201cMuffin,\u201d depending on the circumstance.<\/p>\n\n\n\n
<\/a>Fig. 2 Design token concept metaphor<\/figcaption><\/figure>\n\n\n\n Regardless of what you call your dog, it\u2019s still the same pet (contrary to what you may think when it has just destroyed your favorite piece of furniture). Design tokens work the same. In place of using hard-coded values \u2013 like hex for colour, pixel for spacing, etc. \u2013 you name those values. It is like giving nicknames to your design decisions. Let\u2019s have a look at the colour analogy below.<\/p>\n\n\n\n
<\/a>Fig. 3 Design token concept analogy on a colour example<\/a><\/figcaption><\/figure>\n\n\n\n Design tokens are intended to be used in your design system and across your products. To enable that, you need to transform them for use on various platforms (Web, iOS, or Android) by different teams.<\/p>\n\n\n\n
<\/a>Fig. 4 How design decisions are transformed into design tokens to be used in specific platforms<\/a><\/figcaption><\/figure>\n\n\n\n W3C Design Tokens Standard<\/strong><\/h3>\n\n\n\n
If we want to ensure successful design token adoption in multiple apps, we need a standard securing consistency. The World Wide Web Consortium (W3C), led by Tim Berners-Lee and Jeffrey Jaffe, in cooperation with a plethora of organizations and individuals, works to provide the W3C Design Tokens Standard.<\/p>\n\n\n\n
It would allow other tools to communicate in the same \u2018language,\u2019 for example, enabling tokens from Figma to be taken and used in Adobe Illustrator. Imagine how it would speed up the workflow between marketing and product design departments!<\/p>\n\n\n\n
To learn more about the standard, please explore the Official Design Tokens Community Group<\/a> and the W3C Design Tokens Community Group<\/a>.<\/p>\n\n\n\n
How do we build with design tokens?<\/strong><\/strong><\/h2>\n\n\n\n
Now that I have covered the absolute basics of the design tokens concept, why don\u2019t we move further and dive a little bit deeper into different types of tokens and how they serve us to build designs?<\/p>\n\n\n\n
Each digital product is a structure of features that consist of interfaces. Every interface is built of components and composed of design tokens.<\/p>\n\n\n\n
<\/a>Fig. 5 Product structure diagram<\/figcaption><\/figure>\n\n\n\n Let\u2019s break down a button component. You can see all the elements that we would translate to design tokens.<\/p>\n\n\n\n
<\/a>Fig. 6 The anatomy of a button component showing design tokens composing it<\/figcaption><\/figure>\n\n\n\n Some examples of design tokens<\/strong><\/strong><\/h2>\n\n\n\n
Here are some examples of common design tokens used in industry-standard design systems that you could encounter:<\/p>\n\n\n\n
- \n
- Colour Tokens<\/strong>\n
- \n
- Primary Colour \u2013 used for primary branding elements and calls to action.<\/span><\/li>\n\n\n\n
- Secondary Colour \u2013 complementary colour for accents and secondary elements.Neutral Colours \u2013 shades of grey used for backgrounds, borders, and text.<\/span><\/li>\n\n\n\n
- Error\/Warning Colours \u2013 distinct colours for indicating errors or warnings in the UI.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Typography Tokens<\/strong>\n
- \n
- Font Family \u2013 primary and secondary typefaces used for headings and body text.<\/span><\/li>\n\n\n\n
- Font Size \u2013 different sizes for headings, subheadings, body text, etc.Font Weight \u2013 variations in font weight for emphasis and hierarchy.<\/span><\/li>\n\n\n\n
- Line Height \u2013 consistent spacing between lines of text for readability.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Spacing Tokens<\/strong>\n
- \n
- Padding \u2013 standard padding values for buttons, cards, and containers.<\/span><\/li>\n\n\n\n
- Margin \u2013 standard margin values for spacing between elements.<\/span><\/li>\n\n\n\n
- Grid Spacing \u2013 a grid layout system’s spacing between columns and rows.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Border Tokens<\/strong>\n
- \n
- Border Radius \u2013 standard border-radius values for rounded corners on elements.<\/span><\/li>\n\n\n\n
- Border Width \u2013 thickness of borders around elements.<\/span><\/li>\n\n\n\n
- Border Colour \u2013 standard colours for borders around elements.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Shadow Tokens<\/strong>\n
- \n
- Box Shadow \u2013 standard shadow values for adding depth and dimension to elements.<\/span><\/li>\n\n\n\n
- Text Shadow \u2013 shadow values for enhancing readability and contrast of text.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Icon Tokens<\/strong>\n
- \n
- Icon Size \u2013 standard sizes for icons used throughout the UI.<\/span><\/li>\n\n\n\n
- Icon Colour \u2013 default colour for icons or variations for different states (active, inactive, etc.).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Animation Tokens<\/strong>\n
- \n
- Transition Duration \u2013 duration of transitions between different states or interactions.<\/span><\/li>\n\n\n\n
- Animation Timing Function \u2013 easing functions for smooth animation effects.<\/span><\/li>\n\n\n\n
- Animation Keyframes \u2013 keyframes for more complex animation sequences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- \n
- Accessibility Tokens<\/strong>\n
- \n
- Contrast Ratio \u2013 minimum contrast ratio between text and background colours for readability.<\/span><\/li>\n\n\n\n
- Focus Indicator \u2013 styles indicating focus on interactive elements for keyboard navigation.<\/span><\/li>\n\n\n\n
- Screen Reader Text \u2013 hidden text for screen readers to convey information to visually impaired users.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Types of tokens<\/strong><\/h2>\n\n\n\n
We divide tokens into three categories (types). Each token type signifies a level of assigned context.<\/p>\n\n\n\n
<\/a>Fig. 7 Token types on examples<\/figcaption><\/figure>\n\n\n\n Global tokens<\/strong><\/h3>\n\n\n\n
Tier 1 (global) tokens \u2013 primitive values <\/strong>\u2013 are basic, contextless units of a Design Token System.<\/strong><\/p>\n\n\n\n
Whether you are a designer, a developer, or a project manager, you probably work with the brand colours of your organization, and there is a high chance that you operate on the hex (or any other) values in communication regarding those colours.<\/p>\n\n\n\n
<\/a>Fig. 8 Hex applied directly to UI elements<\/figcaption><\/figure>\n\n\n\n Why is it not the most comfortable solution?<\/strong> Let’s see:<\/p>\n\n\n\n
- \n
- unless you know your hexes by heart (and let’s be honest \u2013 you might be the only one in the organization), the hex code does not describe the actual colour<\/strong>, making it unrecognizable,<\/li>\n\n\n\n
- it does not give any information about the design decision behind this colour<\/strong> (where it is supposed to be used, etc.),<\/li>\n\n\n\n
- it is easy to misspell the hex<\/strong>, leading to visual inconsistencies within the product.<\/li>\n<\/ul>\n\n\n\n
Global tokens<\/strong> are names you give, for example, to hex values, to give an initial, consistent, and contextless description of those values that would be understandable to everybody working with them. This allows avoiding any ‘fifty-shades-of-grey’ situations \u2013 accidentally ending up with several shades of your brand colour used in your product.<\/p>\n\n\n\n
<\/a>Fig. 9 Global (core) token example<\/figcaption><\/figure>\n\n\n\n According to the scheme above, naming your hex value ‘colour.blue.600’ instead of using the hex value benefits you in several manners:<\/p>\n\n\n\n
- \n
- colour is easily recognizable now,<\/li>\n\n\n\n
- tokenized value is now defined as a variable in code, so any misspelling will be signaled as a code error.<\/li>\n<\/ul>\n\n\n\n<\/a>
Fig 10 Example of global tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\n Despite the obvious advantages<\/strong> of using global tokens, this is still not the perfect solution<\/strong>, and relying only on this type of token does not convey information about use cases of the colour nor allows automated, narrowed-down colour changes, affecting only particular groups of components. Instead, the dev team would have to look for suitable use cases and change the colour manually. What a waste of time, right?<\/p>\n\n\n\n
Alias tokens<\/strong><\/strong><\/h3>\n\n\n\n
Here comes the next design token type. Tier 2 (alias or system) tokens <\/strong>\u2013 context-specific names referring to design decisions behind values (what they ‘do\u2019). <\/p>\n\n\n\n
#0E6EE0, now called \u2018colour.blue.600′, will also exist in the system under different aliases, depicting its use cases. For example, \u2018colour.interactive.primary.background\u2019 would mean this colour is supposed to be used for the background of primary, interactive UI elements.<\/p>\n\n\n\n
<\/a>Fig. 11 System (alias) token example<\/figcaption><\/figure>\n\n\n\n As you can see in the example above, in case of any colour change, this operation would only affect the background of the primary interactive elements of the user interface, eliminating those without a blue background.<\/p>\n\n\n\n
Introducing alias tokens to code results positively in:<\/strong><\/p>\n\n\n\n
- \n
- elimination of possible mistakes when copying to code (just like global, alias tokens are variables in code as well),<\/li>\n\n\n\n
- making the token\u2019s purpose clear to both design and dev teams,<\/li>\n\n\n\n
- speeding up the update process significantly, enabling devs to update component properties at a large scale easily,<\/li>\n\n\n\n
- empowering developers and designers, allowing detection of potential incorrect use of properties (like text colour applied to icons) and correcting such errors by developers themselves or in communication with design,<\/li>\n\n\n\n
- making designers rethink the need for additional values, such as colours, in the design system, reducing potential clutter and unnecessary system complexity.<\/li>\n<\/ul>\n\n\n\n<\/a>
Fig 12 Example of alias tokens (Lightning Design System<\/a>)<\/figcaption><\/figure>\n\n\n\n When should you reach for alias tokens?<\/strong><\/p>\n\n\n\n
- \n
- For example, tokenizing every colour across your design system would result in a giant global token set to maintain.<\/li>\n\n\n\n
- If global tokens apply to text, icon, background, or border across multiple pages.<\/li>\n\n\n\n
- If you have a multi-brand\/theme\/mode design system.<\/li>\n<\/ul>\n\n\n\n
Example:<\/p>\n\n\n\n
<\/a>Fig. 13 Multi-theme design system alias tokens example<\/a><\/figcaption><\/figure>\n\n\n\n Of course, using alias tokens comes with the responsibility of maintaining a larger set of colours and requires thorough and thoughtful system planning; however, in the long term, the perks prove to be worth the additional effort.<\/p>\n\n\n\n
There are cases when it is not advisable to rely on alias tokens. For example, if there is a colour that you need to use in your product, but it is not part of your brand’s visual language, or it would be used only once or for one particular UI element that should not be affected by global design decision changes.<\/p>\n\n\n\n
Component specific tokens<\/strong><\/strong><\/h3>\n\n\n\n
For unique UI elements, it is appropriate to use Tier 3 (component-specific) tokens dedicated to distinct components and their properties<\/strong>.<\/p>\n\n\n\n
<\/a>Fig. 14 Component tokens example<\/figcaption><\/figure>\n\n\n\n All of the above names (design tokens) mean the same hex value but in different contexts or regarding a different design system component \u2013 when you apply component-specific tokens, any possible design decision changes \u2013 e.g., colour updates \u2013 applied to it will affect only this component and the property the token refers to. In our case, it would be only the background colour of the primary button in its default state.<\/p>\n\n\n\n
As you can see on the diagram below, where I switch blue to pink, this is how tokens allow me to be specific about design decision modifications. You can apply particular changes (like colour) to selected tokens, affecting only particular UI elements.<\/p>\n\n\n\n
<\/a>Fig. 15 Exemplary design token structure \u2013 from a core token to components<\/figcaption><\/figure>\n\n\n\n <\/a>Fig. 16 Exemplary design token structure \u2013 colour change<\/figcaption><\/figure>\n\n\n\n Okay, but how do we come up with token names?<\/strong><\/h2>\n\n\n\n
I will not tell you exactly what naming convention to aim for when establishing a tokens system for your product, as it should be tailored to your product’s specifics and team preferences. Naming takes time, as teams need to invest effort into finding the perfect logic for them. Although looking for inspiration in open design systems is good, you need to remember that what works for one product does not necessarily have to be an ideal solution for yours.<\/p>\n\n\n\n
I will not elaborate too extensively on token naming, as it is a vast topic, worth in-depth exploration once you embark on a design token system building journey. However, let me share some good practices to consider while developing a design token naming system that would serve an organization well.<\/p>\n\n\n\n
Token names \u2013 best practices<\/strong><\/h3>\n\n\n\n
Most importantly, token names should be:<\/p>\n\n\n\n
- \n
- as short as possible \u2013 to not overcomplicate the system,<\/li>\n\n\n\n
- meaningful \u2013 to communicate design decisions clearly,<\/li>\n\n\n\n
- easy to understand \u2013 for easy orientation and potential onboarding to the system,<\/li>\n\n\n\n
- modular \u2013 for simplicity of building the system,<\/li>\n\n\n\n
- consistent \u2013 to reflect the design system properly and facilitate understanding of the naming convention.<\/li>\n<\/ul>\n\n\n\n
When setting a naming convention for alias tokens, a good start will be building names about:<\/p>\n\n\n\n
- \n
- category \u2013 the attribute a token refers to, e.g., colour, typography, spacing, shadow, border radius, etc.,<\/li>\n\n\n\n
- concept \u2013 a situation a token describes, e.g., Information, warning, success, etc.,<\/li>\n\n\n\n
- purpose (property) \u2013 where in your UI a token will be used, e.g., text, icon, background, border, heading, body, etc.,<\/li>\n\n\n\n
- variant \u2013 potential variants of a token, e.g., states (active, inactive, disabled), sizes (XL, L, M, S), etc.,<\/li>\n\n\n\n
- component (to be avoided unless specifically needed) \u2013 a component that will be affected by a token, e.g., button, checkbox, link, etc.<\/li>\n<\/ul>\n\n\n\n
Token names \u2013 examples<\/strong><\/h3>\n\n\n\n
Such convention could look like this:<\/p>\n\n\n\n
Category.purpose.variant <\/strong><\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Colour.background.active<\/strong><\/p>\n\n\n\n
(describing the design decision made to assign a particular colour to the background of active UI elements)<\/p>\n\n\n\n
Next, you should focus on providing as much context as you can. Remembering that keeping token names as short as possible is worth making a token name a bit longer if it reflects the design decision well. After all, design tokens are not UI elements that end users would see but text information stored in code that developers operate on. Therefore, the more context they convey, the better.<\/p>\n\n\n\n
Design token naming conventions, especially those for multi-brand design systems that require multiple themes (visual language sets, e.g., specific brand colours, typography, iconography, etc.), may consist of many naming levels.<\/p>\n\n\n\n
For instance, if you need to distinguish tokens across brands in your design system, you may need to introduce product namespacing, which might look like this:<\/p>\n\n\n\n
brand<\/strong>.product.colour.information.background<\/strong> Namespacing allows developers to distinguish tokens in code and operate on them more comfortably.<\/p>\n\n\n\n
We have the system established. How do we manage it all together?<\/strong><\/h2>\n\n\n\n
Now that you know the basics of the design tokens concept and token naming conventions, it is time to present how using them streamlines design-dev collaboration.<\/p>\n\n\n\n
For better contrast, let me introduce you to the design handoff process in its classic shape, with no use of design tokens.<\/p>\n\n\n\n
Classic process<\/strong><\/h3>\n\n\n\n
Commonly, we complete the following handoff steps:<\/p>\n\n\n\n
- \n
- The designer delivers the UI design in Figma<\/a> (the most popular collaborative interface design tool).<\/li>\n\n\n\n
- The designer prepares UI specs (design documentation with handoff notes for dev).<\/li>\n\n\n\n
- The designer hands off the design file and has a call with the developer\/dev team, who will be implementing the design, to discuss the specifics.<\/li>\n\n\n\n
- Developers inspect the file and start coding.
<\/li>\n<\/ol>\n\n\n\nIt seems quite simple at this level, considering the design will never change. However, product design is about evolution, and design changes are inevitable. Therefore, the above process does not end on the fourth step. Over time, as the brand evolves, there are more steps:<\/p>\n\n\n\n
- \n
- Let’s say the brand colour changed, and the designer needs to update the design; let developers know so they can update the code accordingly.<\/li>\n\n\n\n
- There are also times when developers need to change something in the code, so they need to inform the designer to reflect those changes in the design.<\/li>\n<\/ul>\n\n\n\n
The more steps and iterations, the more space for mistakes. And let\u2019s be honest, overall, this amount of communication back and forth for just one colour update is a lot considering the daily workload.<\/p>\n\n\n\n
<\/a>Fig. 17 Classic design handoff process (simplified scheme)<\/a><\/figcaption><\/figure>\n\n\n\n We want this process to be as simple and automated as possible (like on the diagram below) to save valuable time for both design and dev teams.<\/p>\n\n\n\n
<\/a>Fig. 18
- The designer delivers the UI design in Figma<\/a> (the most popular collaborative interface design tool).<\/li>\n\n\n\n
- it does not give any information about the design decision behind this colour<\/strong> (where it is supposed to be used, etc.),<\/li>\n\n\n\n
- Focus Indicator \u2013 styles indicating focus on interactive elements for keyboard navigation.<\/span><\/li>\n\n\n\n
- Contrast Ratio \u2013 minimum contrast ratio between text and background colours for readability.<\/span><\/li>\n\n\n\n
- Animation Timing Function \u2013 easing functions for smooth animation effects.<\/span><\/li>\n\n\n\n
- Transition Duration \u2013 duration of transitions between different states or interactions.<\/span><\/li>\n\n\n\n
- Icon Colour \u2013 default colour for icons or variations for different states (active, inactive, etc.).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- Icon Size \u2013 standard sizes for icons used throughout the UI.<\/span><\/li>\n\n\n\n
- Text Shadow \u2013 shadow values for enhancing readability and contrast of text.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- Box Shadow \u2013 standard shadow values for adding depth and dimension to elements.<\/span><\/li>\n\n\n\n
- Border Width \u2013 thickness of borders around elements.<\/span><\/li>\n\n\n\n
- Border Radius \u2013 standard border-radius values for rounded corners on elements.<\/span><\/li>\n\n\n\n
- Margin \u2013 standard margin values for spacing between elements.<\/span><\/li>\n\n\n\n
- Padding \u2013 standard padding values for buttons, cards, and containers.<\/span><\/li>\n\n\n\n
- Font Size \u2013 different sizes for headings, subheadings, body text, etc.Font Weight \u2013 variations in font weight for emphasis and hierarchy.<\/span><\/li>\n\n\n\n
- Font Family \u2013 primary and secondary typefaces used for headings and body text.<\/span><\/li>\n\n\n\n
- Secondary Colour \u2013 complementary colour for accents and secondary elements.Neutral Colours \u2013 shades of grey used for backgrounds, borders, and text.<\/span><\/li>\n\n\n\n
- Primary Colour \u2013 used for primary branding elements and calls to action.<\/span><\/li>\n\n\n\n
- Colour Tokens<\/strong>\n