May 5, 2024
Design Tokens can be challenging; do you feel overwhelmed about where to even start? Do you spend a lot of time trying to find the right approach or names? What are Design Tokens?
We sat down with Sam Gordashko, a freelance Design Systems expert, to discuss Design Tokens, Naming and her upcoming workshop at the Into Design Systems Conference - May 15-17.
We were chatting about:
πΉ What are Design Tokens?
πΉ How to get started naming Design Tokens?
πΉ What are the benefits naming Design Tokens?
πΉ Figma variables and when to use Tokens Studio
πΉ Upcoming workshop: How to name & automate Design Tokens
In this edition we will cover:
What are Design Tokens?
How to get started naming Design Tokens?
About Sam Gordashko:
Sam is a freelance Design Systems expert who works with Tokens Studio. She has spent over six months researching Design Tokens and token architecture, creating content to ensure that anyone interested in design tokens can easily understand the topic.
What are Design Tokens? Could you explain them with a simple example as if to a 5 year old?
If you ask a five-year-old why they did something, they might simply respond, "I don't know." Yet, if you observe their actions, they might explain, "Oh, I did this because of that," revealing a thought process behind their actions.
Similarly, when you ask them to choose their favorite stuffed toy, they might not know why they picked a particular one. Design tokens serve a similar purpose for designers; they capture and document our decisions.
When we hand over a design element, like a stuffed animal or a button, to an engineer, and they ask, "Why did you do it this way?" we wonβt say "I don't know." Instead, we have all our decisions captured in a format we can share.
Design tokens help express our design choices in a common language that engineers can then translate into any programming language they need.
How to get started naming Design Tokens?
I call the top layer "the options." It includes all the choices available to you, similar to every paint palette in a store when you're planning to repaint your room.
You have endless options, but when you bring one home and apply it to the wall, you start making decisions and marking off some choices. So, we have options at the top, decisions in the middle, and then we apply these decisions to components.
For the sake of consistency, this is what I call them. You can name them whatever suits you. I don't want to say it depends, but this is essentially the hierarchy in my mind.
If we name each layer differently in my architecture, I can immediately understand where things are coming from.
We need to change how we write names so they indicate who the design decision is for, where it belongs in my system, what its intended use is, when it applies, how the decision was made, and what its value is.
In her six-month research project, Sam developed a new approach to naming Design Tokens:
Can we get the who, what, where, when, why, and how of our decisions into our tokens just by looking at the name?
Thatβs actually the entire goal of this workshop that I'm going to share.
Who? When? Where? What? β> Design Token Name