Simplifying design tokens
Design tokens are the basis of every Design System. It’s with design tokens that you should start. I studied the concept of design tokens a lot before starting to create a Design System. I noticed that all I studied were more complex forms of token design that served companies with many products, with many development teams and with many customers. But, what to do in a company (or startup) with a single product? How to transform that complexity into something simple and easily implemented?
What are design tokens?
Design tokens are a comprehensive variable that incorporates various style elements and can be coded as a data file. By means of a token, it becomes possible to promote several simultaneous style changes in a project, preserving the visual integrity and quality of the user’s experience with the product.
How do big companies do?
Nathan Curtis wrote this article that pretty much represents how a company with many products should create design tokens. The complexity can even be scary, but it makes a lot of sense in the context of a company like Salesforce, for example. Several products require a series of rules in writing the tokens, as shown in the image below:
Simplifying the process
But what about your Startup that only has one product? Does it make sense to use tokens this way? How can we start our Design System using simplified tokens?
The solution I found was to use a concept similar to atomic design, where we will have a Base token and a Semantic token.
Base token
The base token will represent the literal value of the property. It will be the base and you don’t need to have many rules for creation. We can simply do as exemplified below:
colorBase {
$1: “#207120”;
$2: “#64EB27”;
$3: “#87D134”;
$4: “#293647”;
$5: “#987F64”;
…
}
borderRadius {
$1: “0”;
$2: “2px”;
$3: “4px”;
$4: “8px”;
$5: “16px”;
…
}
As we don’t always know which values we’re going to use, I put a good range to suit the design team. This amount of items may seem exaggerated, but it helps a lot when we still don’t know what properties we will have in the components. Imagine you have a token named $3 and value 24 and another token named $4 and value 40. You find that you need a token worth 32 but manage to fit more into the same sequence.
Example of a good base token range:
$1: “0”;
$2: “2px”;
$3: “4px”;
$4: “8px”;
$5: “16px”;
$6: “24px”;
$7: “32px”;
$8: “40px”;
$9: “48px”;
$10: “56px”;
$11: “64px”;
$12: “72px”;
$13: “80px”;
$14: “128px”;
I probably won’t use them all but I know they’ll be there if I need them.
The number assigned to the variable has no semantic value in this case, so it’s better to use a sequential number anyway.
Semantic token
Well, we created the Base Tokens and now we will decide which semantic tokens should be created. Note the example:
colorBase {
$1: “#207120”;
$2: “#64EB27”;
$3: “#87D134”;
$4: “#293647”;
$5: “#987F64”;
…
colorSemantic {
$primaryColor: “$2”;
$secondaryColor: “$4”;
$neutralColor: “$5”
}
}
borderRadius {
$1: “0”;
$2: “2px”;
$3: “4px”;
$4: “8px”;
$5: “16px”;
…
borderradiusSemantic {
$border-radius-default: “$2”;
$border-radius-rounded: “$5”;
}
}
This is the best way to write tokens when a product is still under construction. We are not sure which properties we will use and having Base Tokens with a variety of properties we can quickly create and combine Semantic Tokens, accelerating the development of your product’s features.
If your company changes the color palette (this can be very common in startups), just change the base tokens ($1, $2, $3…). If you opt for square borders by default instead of round ones, just change the value of the semantic token:
$border-radius-default: “$2”; => $border-radius-default: “$1”;
Example implementation (React.js)
import {tokens} from “@designTokens”
const Card = styled.div”
border-radius: ${tokens.borderRadius.border-radius-rounded};
background-color: ${tokens.colorBase.neutralColor};
“;
Above we have an example of application in javascript. The token is easily referenced and its value keeping is limited to the token sheet only. Just create a component with the properties and their semantic tokens. Note that at no time do you see base token values. Only the semantic tokens. This makes maintaining your design styles very easy.
If you are starting a Design System now in your Startup, with a small design team, keep it simple!