Tokens – Pavvy Designs

If you stare at your twitter feed long enough, it can look like everyone is talking about Design Systems. In some cases you could be persuaded to think how shallow the term can go.

“Isn’t this what we called Style Guides?”, “Here’s my React Design System”, “I’ve just updated the Design System in Sketch”

To me, they are some and all of these things. Over the last 4 years of consulting with two clients on their Design System, my own view has changed a little.

If you dig a little deeper into Design Systems twitter you will probably see the term “Design Tokens” pop up at least once a day somewhere. Design Tokens came out of work that was being done at Salesforce with Jina and others who pioneered the creation of Design Tokens as we know them today – creating the first command line tool in Theo that had started the adoption of Design Tokens to the wider Design Systems Community.

A cool term but, what are they?

If you look at your client work, your companies site, the project you’re working on you should notice some parts of the page have a degree of consistency: the background colour of your form buttons is the same colour as your link text, or your text has the same margin, or your card elements have the same spacing as your media object.

These are design decisions, and they should be littered across the overall design of your project. These decisions might start off in a Sketch file and make their way into code from detailed investigation of a Sketch file, or you may find that the design evolves from your design application once it gets into code.

These design decisions can change, and to keep them synchronised across design and development in applications, as well as a larger documentation site in your Design System, is going to take some effort.

This is where Design Tokens come in, and I find the best way to succinctly reiterate what they are is via the two following quotes…

“Design Tokens are an abstraction for everything impacting the visual design of an app/platform.”

– Sönke Rohde

…and

“We use them in place of hard-coded values in order to maintain a scale-able and consistent visual system.”

– Jina

There are several global design decisions that we can abstract to create a top level design token – Sizing, Font Families, Font Styles, Font Weights, Font Sizes, Line Heights, Border Styles, Border Colours, Border Radius, Horizontal Rule Colours, Background Colours, Gradients, Background Gradients, Box Shadows, Filters, Text Colours, Text Shadow, Time, Media Queries, Z Index, Icons – these can all be abstracted as required.

So, spicy Sass variables?

We can look at Design Tokens as an abstraction of CSS, sort of like Sass variables, but spicier. Looking at them like this we can see that they are (in either .yaml or .json) a group of related key value pairs with more information that can be added as needed.

The great thing with abstracting design decisions outside of your CSS pre-processor is that you’re not tying those decisions to one platform or codebase.

As a crude example, we can see here that we are defining a name and a value that could then become our color, background-color, or border-color, and more.

# Colours
# -------
- name: color-red
  value: #FF0000
- name: color-green
  value: #00FF00
- name: color-blue
  value: #0000FF
- name: color-white
  value: #FFFFFF
- name: color-black
  value: #000000

These can then generate our Sass variables (as an example) for our projects.

$color-red: #FF0000 !default;
$color-red: #00FF00 !default;
$color-red: #0000FF !default;
$color-white: #FFFFFF !default;
$color-black: #000000 !default;

Why are they so good

Ok, so we now know what Design Tokens are, but why do we need them? What makes them better than our existing solutions (css pre-processors) for defining these design decisions?

I think there are 5 really good reasons why we all should start abstracting these design decisions away from the CSS that they may live in. Some of these reasons are similar to reasons some developers use a pre-processor like Sass, but with added bonuses.

Consistency

Much like using a CSS pre-processor or using CSS custom properties, being able to define a background colour, breakpoint, or font-size in more than one place using the same key ensures that we are using the Sass values across the entire product suite we are developing for.

Using our Design Tokens in their generated formats, we can be sure to not end up with 261 shades of blue.

Maintainability

By using a pre-processor like Sass, or using native CSS custom properties, we can already have maintainable code in our projects. Design Tokens also do this at the abstracted level as well.

Scalability

“Design Tokens enable us to scale our Design across all the permutations.”

– Jina

At this point, we’re only talking about abstracting the design decisions for use in CSS. Having Design Tokens allows design to scale for multiple brands or multiple projects as needed.

The main benefit of Design Tokens in regards to scalability is the option that it gives us to offer the Design Tokens for other platforms and frameworks as needed. With some of the tools available, we can even have these Tokens shared between applications used by designers and developers.

Your marketing site and your iOS application can soon share the same design decisions codified, and you can move towards creating an Android app or web application as required.

Documentation

If we abstract the design decisions from one platform specific programming language it would be no good if it wasn’t made to be easily accessible.

The tools and applications available that are mentioned later in this article can now create their own documentation, or allow you to create your own. This documentation is either hosted within a web-based application or can be self-hosted with the rest of your Design Systems documentation.

Most of the command line tools go further and allow you do add more details that you wish to convey in the documentation, making it as unique as it is required for your project.

Empowerment

When you abstract your design decisions to Design Tokens, you can help empower other people on the project. With the tools available today, and the tools that are just around the corner, we can have these design decisions determined by anyone on the team.

No-one necessarily needs to understand how to set up the codebase to update the colour slightly. Some of the tools I mention later on allow you to update the Design Tokens in the browser.

Design Systems are already “bridging the gap” between design and development. With Design Tokens and the tooling available, we can create better team relationships by closing that gap instead.

Some of the benefits of creating and using Design Tokens are the same as using a pre-processor when it comes to authoring CSS. I feel the added bonuses of being able to empower other team members and document how you use them, as well as the fundamental reasoning in that they can be platform agnostic, are all great “selling points” to why you need to start using Design Tokens today.

Tools

There are several tools available to help you and your team to create the required files from your abstracted Design Tokens:

Command Line Tools

There are several tools available on the command line that can be used as part of, or separate to, your development process.

These tools allow you to define the Design Tokens in a .json or .yaml file format which can then be compiled into the formats you require.

Some have built in functions to turn the inputted values to something different when compiled – for example, turning hexadecimal code that is a Design Token into a RGB value in your .css file. These command line tools, written in JavaScript, allow you to create your own ways in which you want things transformed.

My current client has certain design decisions for typography in long form content (font size, weight, line height and margins) which need to be together to make sense. Being able to write JavaScript to compile these design decisions into an independent Sass map for each element allows us to develop with assurance that the long form content has the correct styling.

WYSIWYG Tools

WYSIWYG (What You See Is What You Get Tools) have been around for almost as long as we have been able to make websites. I can just about remember using Dreamweaver 2, before I knew what a


 was.
When browsers started to employ vendor prefixes to new CSS for their browsers, a flurry of online WYSIWYG tools came with it built in. They’re still there, but the industry has moved on.
Design Tokens also have a few WYSIWYG tools available. From simpler online tools that allow you to generate the correct Sass variables needed for your design decisions to tools that store your decisions online and allow you to export them as npm packages.
These types of tools for creating Design Tokens can help empower the team as a whole, with some automatically creating documentation which can easily be shared with a url.
Retrofitting Tools
If you are starting from scratch on a new re-design or on a new project that requires a Design System and Tokens, the many of the tools mentioned above will help you along your way. But what if you’re in the middle of a project, or you have to maintain something and want to start to create the parts required for a Design System?
Luckily there are several tools and techniques to help you make a start.
One new tool that might be useful is Superposition. Currently in private beta with the public release set for Q1 of 2020 Superposition helps you “Extract design tokens from websites and use them in code and in your design tool.”
Entering your domain gives you a nice visual documentation of your sites styles as Design Tokens. These can then be exported as Sass Variables, CSS Custom Properties, JavaScript with the team working on exports to iOS and Android.
If you have an existing site, this could be a good first step before moving to one of the other tools mentioned above.
You could also make use of CSSStats or Project Wallace’s Analysis page that I mentioned earlier. This would give you an indication of what Design Tokens you would need to implement.
Component Based Design
So, we’ve created our Design Tokens by abstracting the design decisions of brand colours, typography, spacing and more. Is that as far as we can go?
Levels of Design Decisions
Once we have created our first set of Design Tokens for our project, we can take it that little bit deeper. With command line tools and some of the applications available, you can link these more global decisions to a more deeper level.
For example, you can take your chosen colours and make further design decisions on the themes of your project, such as what the primary, secondary, or tertiary colours are or what your general component and layout spacing will be.
With this, we can go one step further. We could also define some component specific design decisions that can then be compiled for the developer to use. Invest in time to check over the designs with a fine toothcomb and make sure you are using the correct Sass variable or CSS custom property for that component.
If you are going more than one or two levels of design decision making, you can compile each set of these Design Tokens to your Sass variables which can then be used as required. So you can provide: global, theme, component level Sass variables which can be used in the project. Or you could choose to only compile what you need for the components you are creating.
Variables, Maps, Custom Properties
Some of the tools available for creating and maintaining your Design Tokens allow you to compile to certain programming languages.
With my current client work, I am making use of Sass variables, Sass maps, and CSS custom properties. The Design Tokens are compiled into one or more of these options depending on how they will be used.
Colours are compiled as global Sass variables, inside of a couple of Sass maps and CSS custom properties. Our macro layout breakpoints are defined as a single Sass map.
If we know we are creating a component that has the ability to be themed, we can make use of CSS custom properties to reduce the amount of CSS we need to override, and also allow us to inline things that can be changed via a CMS as required. Which leaves us using Sass variables for parts of a component that won’t change. We are using Sass maps differently still. As mentioned, we generate a Sass map containing the design decisions for each element of text, and we can use long form text. This Sass map is then compiled into separate CSS declarations as needed using Sass mixins.
I find the beauty of being able to make use of the global, themed, and component level design decisions by compiling them into various formats (that essentially become CSS) and that gives us more power in authoring components.
Creating Consistent Utility Classes
As you have created your more global generic design decisions, you can create your own small set of utility classes.
Using a pre-processor like Sass you can define a set of mixins and functions that can take your Design Tokens that have been compiled down into variables and maps and generate separate classes for each design decision.

By making tokens available to all digital teams, we can enable them to create custom experiences that are aligned to current visual standards when a component does not (or will not) exist in the design system.

Maya King
In creating utility classes with Design Tokens (using something like Sass) you have consistency with the overall Design System for times when you or a team need to create a one-off component for a project.
These exceptions tend to be something that won’t make it as part of the overall Design System, but it still needs that look and feel.
Having classes available that we can guarantee use the generic, global design decisions from the Design Tokens means these one-off components should be well on their way to have the overall look and feel of the project, and will get any updates with little to no additional overhead.
Wrapping Up
I think we are starting to see the potential of using Design Tokens as Design Systems become even more popular. I think that, from this overview, we can see how they can help us close the gap that still exists in places between the designers and developers on the team. They can help empower people who do not code to make changes that can be automatically updating live work.
I think you can start now. You may not have or need what you could term “a fully-fledged Design System” but this small step will help move towards one in the future and give you instant benefits of consistency and maintainability now.

If you want more Design Tokens, as well as the links that are dotted around this article I also maintain a GitHub repo of Awesome Design Tokens which I try to keep updated with links to tools, articles, examples, videos, and anything else that’s related to Design Tokens.

	
		
			
				

				Design Tokens Beyond Colors, Typography, and Spacing
				
					
						November 21, 2019
					 • Design, Tokens
				

																
		

		
						
				
									
			
						
				

As I said above, many people think of design tokens as “a set of core design properties of an application or website”. While this is pretty intuitive it can also be quite misleading and reductive.
Take a look at this playground, and see how the only things you can tweak are colors and typography:
Try this management tool for design tokens, and see how it’s built around the idea of “core” values of design properties:










A screenshot of the interface used to add a new design token.
Look at the many existing plugins for Figma, Sketch or Framer, that exist for exporting design tokens: they’re all based on the idea of exporting granular and isolated values for colors, font-sizes/line-heights, spacing, etc.
Open the “design tokens” page of the many design systems available online, and in most cases what you see are colors, typography, spacing, elevation, timing, sizing, etc.
Let me be clear: there is nothing wrong with this.
But, as I said before, I think design tokens can do much more than this.
In my experience, design tokens’ great potential and power are fully expressed when two other things form part of the equation, when they are:

used to express properties and values for components;
annotated with meta-information.

There’s no reasons why design tokens can’t be used to describe a component’s properties.
From a purely technical point of view, design tokens are organised lists of key-value pairs that describe design decisions. So it’s just a matter of convenience (and context) what are the boundaries that we assume when describing a UI via design tokens.
In some cases, especially when a design system is in its early stages, limiting ourselves to just core values (eg. colors, typography, spacing) makes perfect sense. But once the system becomes more complex, and starts to include more and more components, there are a lot of good reasons for using design tokens for these as well.
Moreover, basic colors and typography don’t change very frequently (re-branding exercises are a case in point). But by contrast, in my experience, components are constantly evolving.
In recent months, many new components have been added to our design system; some existing ones have been fine-tuned (and in some cases even refactored); a few others have been extended for use in different contexts or visual states. By contrast, only a couple of colors and one font size have been changed.
How we use them in MagicLab
Whenever a component is created, we discuss — with the designers and developers involved in the design system — the possible states and variants of the component, and its specific design decisions. Then we translate all these specifications into specific design tokens.




Here, for example, is what the JSON file for the LifestyleBadge component looks like (we use Style Dictionary to manage our design tokens):
{

    "lifestylebadge": {

        "height": {

            "value": "34",

            "type": "size"

        },

        "border_radius": {

            "value": "17",

            "type": "size"

        },

        "padding": {

            "start": {

                "value": "{spacing.md.value}",

                "type": "size"

            },

            "end": {

                "value": "{spacing.md.value}",

                "type": "size"

            }

        },

        "icon_size": {

            "value": "{icon.size.md.value}",

            "type": "size"

        },

        "spacing_icon_text": {

            "value": "{spacing.xsm.value}",

            "type": "size"

        },

        "base": {

            "text_color": {

                "value": "{color.gray_dark.value}",

                "type": "color"

            },

            "background_color": {

                "value": "{color.gray_light.value}",

                "type": "color"

            }

        },

        "selected": {

            "text_color": {

                "value": "{color.white.value}",

                "type": "color"

            },

            "background_color": {

                "value": "{color.primary.value}",

                "type": "color"

            }

        }

    }

}
These values are processed in different output formats, and then distributed to multiple platforms (mobile web, iOS, Android) and products (we currently support four main brands plus a few white-labels).
Once the tokens for a component are added to the system, the developers that assume the task of implementing it will immediately have at hand all the necessary design specifications:










The “LifestyleBadge” tokens for Android, as visible in our design system
At first sight, this may look like a case of over-engineering, adding a lot of complexity to the system. But actually, what we’ve found is that this allows us to distribute information to the “consumers” (the developers) in a reliable, well-established way. This in turns reduces opportunities for confusion, misunderstandings and (human) error.
The developers themselves have started demanding specific tokens whenever a component is added to the system. This is because it obviates the need for them to open a Sketch file (or a Sympli page), and then figure out all the sizes, colors, and component specs. Instead, all they have to do is update the version of the design tokens package in their codebase, launch a sync/update script, and all these specs are automatically there for them, abstracted in easy-to-read variable names. (Plus, we use illustrations like the one below, to show how/where a component’s design tokens are defined and used).




Another important aspect of this approach is that you derive the same benefits as when the design tokens are used for core design properties:

In a multi-product design system like ours it makes easy to achieve multi-product components, where the same component (with exactly the same code) has a different look and feel for different products/brands. Doing this helps us keep the cost of scaling down (eg. when adding new applications to our portfolio)!
Whenever a designer decides to update the visual styling of a component (eg. the background color) or its layout/geometry (eg. the horizontal padding) all that these changes require is an update of a few values in a single JSON file, and the change of a version number for the imported tokens in the codebase, and nothing else: the cost of change is extremely low!

If we see design tokens as a way to convey information, then it makes absolute sense to use them for components as well.
Both of the main management tools for design tokens (Theo & Style Dictionary) support the addition of meta-data to the key-value pairs. While they can be used for adding comments and annotations, their real power manifests when they’re used to add an extra layer of meaning.
For example, you can add type information to the values, for use later on, when they are processed to generate specific outputs. You can add grouping information which can be used later for organising or filtering them in very specific ways. Many other kinds of information can be added, depending on context and needs. The key here is to add what has meaning for you, your context/usage/need.
How do we use them in MagicLab
The first meta-information that we introduced, once we had adopted the design tokens in our design system, was “documentation/comment”. This was used to enable the addiction of extra information to a token, that would appear in the design system website. We decided to use the documentation namespace for it, rather than just using a comment property, in case we needed to add even more information (eg. if a design token is deprecated, and what it needs to be replaced with).
Here, for example, is how we add a comment to a design token:
{

    "actionsheet": {

        …

        "item": {

            "height": {

                "value": "48",

                "type": "size",

"documentation": {

"comment": "Notice: this is the 'internal' size, the border will be added as extra"

                }

            },

            …

        }

    }

}
And this is rendered in the documentation of the design token in this way:












The second piece of meta-information that we added immediately after was “type”. This is not strictly a type in the “programming-language” sense, but rather in a a semantic way.
Below some examples of types we’re using:
{

    "color": {

        "primary": {

            "value": "{color.palette.purple_grape.value}",

"type": "color"

        }

    },

    "icon": {

        "size": {

            "xsm": {

                "value": "10",

"type": "size"

            }

        }

    },

    "tooltip": {

        "shadow": {

            "opacity": {

                "value": "0.08",

"type": "opacity"

            }

        },

        "animation": {

            "timing_bounce": {

                "value": "0.9",

"type": "time",

                "unit": "s"

            }

        }

    },

    "chat": {

        "bubble": {

            "relative_width": {

                "value": "0.8",

"type": "ratio"

            }

        }

    },

    "actionsheet": {

        "gravity": {

            "value": "center",

"type": "string"

        }

    }

}
The “type” meta-data is used in the post-processing script to create custom output for different platforms. Below you can see a piece of code relating to the template used to generate the XML file for Android:










For Android, depending on the token “type”, we generate values with specific formatting.
And this is the custom formatted output:










The XML generated for Android, with the XML format/type depending on the token “type” meta value.
More recently, we have added a third kind of meta-data to our set of design tokens: “group” information. This is one of the most important ones, and it’s used for multiple reasons.
Filtering
For some products/targets, we only want to release a subset of tokens (eg. just the colors). In this case, it was quite easy for us to add a custom filter to Style Dictionary like this:










A custom script to filter only “proper” colors.
If you notice, we are applying two filters here: one for the “color” token “type”, and one to filter out any “aliases”. This is because we make use of special colors (like color-palette-purple-grave) as pointers to hex color values, but because we don’t need them as generated tokens, we flag them with a meta-data called isAlias.
This filter is then used to generate color-only specific files:










We filter the design tokens based on their “type” meta-data, to generate color-only files in output.
This is just one example of how you can use meta-data to filter tokens and generate specific outputs. I can imagine many other instances where this could be used, depending on your context and needs.
Grouping
Another way in which we’re using the meta-data of design tokens is for grouping them in specific ways.
For example, using the “group” attribute we can create lists of tokens that share the same group, and later use these lists (or maps) in our codebase.
Assigning a different “group” to the design tokens for color values, icons sizes, like here:
// color/xxx.json

{

    "color": {

        "primary": {

            "value": "{color.palette.purple_grape.value}",

            "type": "color",

"group": "brand"

        },

        …

        "generic_red": {

            "value": "{color.palette.pink_salmon.value}",

            "type": "color",

"group": "generic"

        },

        …

        "gray_dark": {

            "value": "#767676",

            "type": "color",

"group": "mono"

        },

        "feature": {

            "verification": {

                "value": "{color.palette.blue_neon.value}",

                "type": "color",

"group": "features"

            },

            …

        },

        "provider": {

            facebook": {

                "value": "#4867aa",

                "type": "color",

"group": "providers"

            },

            …

        },

        "others": {

            error": {

                "value": "{color.generic_red.value}",

                "type": "color",

"group": "others"

            },

            …

        }

    }

}// icon.json

{

    "icon": {

        "size": {

            "xsm": {

                "value": "10",

                "type": "size",

"group": "size"

            },

            "sm": {

                "value": "16",

                "type": "size",

"group": "size"

            },

            "md": {

                "value": "22",

                "type": "size",

"group": "size"

            },

            "lg": {

                "value": "30",

                "type": "size",

"group": "size"

            },

            "xlg": {

                "value": "36",

                "type": "size",

"group": "size"

            },

            "xxlg": {

                "value": "46",

                "type": "size",

"group": "size"

            }

        },

        "jumbo-size": {

            "sm": {

                "value": "{brick.size.sm.value}",

                "type": "size",

"group": "size"

            },

            "md": {

                "value": "{brick.size.md.value}",

                "type": "size",

"group": "size"

            },

            "lg": {

                "value": "{brick.size.lg.value}",

                "type": "size",

"group": "size"

            }

        }

    }

}// spacing.json

{

    "spacing": {

        "xsm": {

            "value": "4",

            "type": "size",

"group": "size"

        },

        "sm": {

            "value": "8",

            "type": "size",

"group": "size"

        },

        "md": {

            "value": "12",

            "type": "size",

"group": "size"

        },

        "lg": {

            "value": "16",

            "type": "size",

"group": "size"

        },

        "xlg": {

            "value": "24",

            "type": "size",

"group": "size"

        },

        "xxlg": {

            "value": "32",

            "type": "size",

"group": "size"

        },

        "gap": {

            "value": "{spacing.lg.value}",

            "type": "size",

"group": "size"

        }

    }

}
we can generate Sass maps like this one:
$tokens-color-map: (

providers: (

        provider-facebook: $token-color-provider-facebook,

        …

    ),

mono: (

        black: $token-color-black,

        gray-dark: $token-color-gray-dark,

        gray: $token-color-gray,

        gray-light: $token-color-gray-light,

        white: $token-color-white

    ),

others: (

        error: $token-color-error,

        …

    ),

brand: (

        primary: $token-color-primary,

        …

    ),

generic: (

        generic-red: $token-color-generic-red,

        …

    ),

features: (

        …

        feature-verification: $token-color-feature-verification

    ),

);$tokens-icon-map: (

    size: (

        size-xsm: $token-icon-size-xsm,

        size-sm: $token-icon-size-sm,

        size-md: $token-icon-size-md,

        size-lg: $token-icon-size-lg,

        size-xlg: $token-icon-size-xlg,

        size-xxlg: $token-icon-size-xxlg,

        jumbo-size-sm: $token-icon-jumbo-size-sm,

        jumbo-size-md: $token-icon-jumbo-size-md,

        jumbo-size-lg: $token-icon-jumbo-size-lg

    ),);$tokens-spacing-map: (

    size: (

        xsm: $token-spacing-xsm,

        sm: $token-spacing-sm,

        md: $token-spacing-md,

        lg: $token-spacing-lg,

        xlg: $token-spacing-xlg,

        xxlg: $token-spacing-xxlg,

        gap: $token-spacing-gap

    ),

);...
These maps now allow us to write declarations such as these:






















How we’re using Sass maps generated by the design tokens in our codebase.
In this way we’re not merely abstracting away the declaration of lists of classes/properties based on color/size/etc. More importantly for us, different products can have different lists of colors, or different spacing scales, or icon sizes, etc. but the same Sass code, now works for any list of colors, spacing, sizing, etc.
These Sass files are now universal, and can be used for multi-product and multi-platform components!
Whenever a color is added, or removed, the list automatically gets updated. No code change is required at either component or application level. Everything is controlled by the design tokens declarations.
And this is not only for CSS/Sass. The same benefit of having “lists of tokens associated by the same group” can also be applied to JavaScript code:










In the design system website, we showcase all the possible colors of a component using the lists of tokens generated via the “group” meta-data associated with them.
Which leads to another possible application, for CSS-in-JS. In this case, the list of possible colors (or spaces, or sizes) for a component, simply becomes a loop/map on a list of key-value objects, directly generated by the design tokens tooling.
Following the same approach, we have also recently used the “group” property to generate TypeScript definitions. Using a custom template in Style Dictionary we have been able to generate an output file like this:
declare namespace Tokens {namespace Color {

        enum Providers {

            PROVIDER_FACEBOOK = 'provider-facebook',

            …

        }

        enum Mono {

            BLACK = 'black',

            GRAY_DARK = 'gray-dark',

            GRAY = 'gray',

            GRAY_LIGHT = 'gray-light',

            WHITE = 'white'

        }

        enum Others {

            ERROR = 'error',

            …

        }

        enum Brand {

            PRIMARY = 'primary',

            …

        }

        enum Generic {

            GENERIC_RED = 'generic-red',

            …

        }

        enum Features {

            …

            FEATURE_VERIFICATION = 'feature-verification'

        }        type Color = Providers | Mono | Others | Brand | Generic | Features;}namespace Icon {

        enum Size {

            XSM = 'xsm',

            SM = 'sm',

            MD = 'md',

            LG = 'lg',

            XLG = 'xlg',

            XXLG = 'xxlg',

            JUMBO_SM = 'jumbo-sm',

            JUMBO_MD = 'jumbo-md',

            JUMBO_LG = 'jumbo-lg'

        }

    }namespace Spacing {

        enum Size {

            XSM = 'xsm',

            SM = 'sm',

            MD = 'md',

            LG = 'lg',

            XLG = 'xlg',

            XXLG = 'xxlg',

            GAP = 'gap'

        }

    }}export default Tokens;
These TypeScript definitions and enums can then be consumed directly by the client codebases, to ensure strict type safety (and autocomplete in the IDEs).
One last possible use of meta-data to add extra semantic meaning to design tokens, especially relationships, is for example to declare text styles. We all know that to have a minimum viable text style, you need at least a font-family, a font-size, a line-height, and a font-weight. How can you define the relationship between distinct design tokens, and explicitly declare their relationship, to create an “H1 text style”? One can imagine using the naming (so all the properties of the same style have the same prefix/suffix). Why then not use some meta-data associated with the tokens, to identify them and filter/group them at process time? This is not something we needed to implement, but if we had I would have certainly used a meta-data attribute associated with the different style values.
The key takeaways of this post are the following:

Design tokens are not only a way to store information, but also a way to convey information.
Design tokens are useful for describing core design values, but their full power emerges when used to describe the specs of UI components
There are many ways in which adding meta-data to the design tokens adds extra meaning to them. This meaning can be processed to determine and convey even more information, beyond the mere key/value definition.

For example, using such meta-data it is possible to:

annotate a design token with useful information
selectively generate output according to specific filters
generate dynamic lists driven by tokens for Sass, JavaScript, TypeScript
making use of these dynamic lists, use the same component (with the same code) for multiple products/platforms

I have tried to show real use cases of how we are using this approach to design tokens in our design system. But this is how we use them, to satisfy our needs.
I’m sure many of you will have (or find) dozens and dozens of other examples of how design tokens can be used, beyond colors, typography, and spacing.
It’s a matter of imagining. Think about what you can do, when you add meta-information to the tokens, that has special meaning for you, and in the context of how and where these tokens are used.
And having done so, do please share them with the community 🙂


			

					
	

	
		
			
				

				Why Toggle Tokens Are a Better Alternative to Checkboxes
				
					
						October 4, 2019
					 • Toggle, Tokens
				

																
		

		
						
				
									
			
						
				
What interface component would you use for selecting from a large set of options? For most designers, checkboxes come to mind. But a long list of checkboxes is intimidating to users and can cause them to abandon your form. Not only that, but checkboxes are not efficient or easy to use because they take up space, increase the number of visual elements, and offer small tap targets.
A better component for option selection is toggle tokens. Toggle tokens conserve vertical space so you have room for more content and users don’t have to scroll. Checkboxes require vertical stacking, but toggle tokens allow for both vertical and horizontal stacking. This creates a compact arrangement that makes it less intimidating for users.

Not only that, but toggle tokens don’t require a checkbox and checkmark with the label. As a result, there are fewer elements on the screen competing for the user’s attention. Minimizing visual noise allows users to focus on the options.
The small tap targets of checkboxes can also cause tapping issues. Toggle tokens offer larger tap targets so users can make selections without mistapping.
All these benefits make toggle tokens a better component for selecting options than checkboxes. However, there is an exception when checkboxes fare better.
If your options have long text labels that wrap to multiple lines, you should use checkboxes. Checkbox labels aren’t horizontally constrained and allow enough space for more text. On the other hand, toggle tokens are constrained by its background shape and should only be used when your options are single text line labels.

The name “toggle token” is also as intuitive as the name “checkbox.” It comes from its token-like shape and toggle functionality. Next time you’re thinking about using checkboxes for option selection, consider toggle tokens instead. You’ll conserve screen space and simplify the interface, which will prevent users from abandoning your form.