3 steps to consistent naming of Design Tokens
In this article I will tell a bit about the naming structure of Trygs Design System Anchor and show how we built an airtable to help us name our tokens more consistent.
I will assume you know what a design token is and why it might be smart to implement. (Otherwise. There is plenty of great articles and talks on the subject)
1) Naming structure
In order to name your tokens consistent you will need a structure. Instead rewriting what Nathan Curtis have written so well I will just recommend you to read his article a couple of times about different naming structures.
Naming Tokens in Design system — by Nathan Curtis
We, the Anchor design team, didn’t locate the the perfect naming structure for design tokens during our research. We identified the important thing was to do what made sense for our system and our stakeholder.
For Trygs Design System Anchor we ended landed on this:
We ended up with 11 steps to consider when naming a token. It is a lot and time will tell if it was too much – but this was the amount we needed to feel covered.
One thing was clear. It was not enough to have just a structure. We needed to document what each step could contain. So we (or somebody else) could name consistent after 2 weeks, 3 months. So we needed to document.
2 Naming Guidelines
We didn’t do anything fancy for our documentation. We simply documented all off our steps with descriptions and examples.
For some steps it was simple.
Tier and Category is what I categorise as simple since they have a know numbers of options.
Example: the category is based upon the type of value the token consists off.
font family → font family or font weight
color → color
number → size
For other steps it was more unclear what the potential options would be.
Here we provided examples.
Example: property is dependent on the category and some of the options could be this.
We felt quite confident. We had a naming structure and we had documented the different steps.
However to have a more structure approach to go through each naming we decided to build a simple tool to help us through the steps.
3 Naming tool
We chose to build our simple naming tool in airtable. Here the simple steps with known options could be done using a drop-down while the more flexible was free text.
The airtable gave a structured way to go through the naming structure and helped combine the steps into the token name.
We added some additional columns to track the status of the each token.
We could also link the tokens to other tokens. The Airtable was originally just intended as a helpful tool for naming tokens, but in the end our developer used it to generate our refactored tokens based on a json exported from the airtable.
Remember you can far with simple tools. Maybe you could have a type form to help you name your next token or feed your rules to a chat it and get it to help you out.
Hope you have enjoyed the read – feel free to share in the comments how you work with naming your tokens consistent.
