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
“We use them in place of hard-coded values in order to maintain a scale-able and consistent visual system.”
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
.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
border-color, and more.
- name: color-red
- name: color-green
- name: color-blue
- name: color-white
- name: color-black
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.
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.
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.
“Design Tokens enable us to scale our Design across all the permutations.”
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.
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.
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.
There are several tools available to help you and your team to create the required files from your abstracted Design Tokens:
Command Line Tools
These tools allow you to define the Design Tokens in a
.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
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