Minimum viable design tokens
Documenting and sharing design decisions will help integrate design into production — and serve as a central control center of styles.
We all strive for consistency. Having to manage different styles for different brands across different platforms and devices is overwhelming.
The key to success: a shared understanding of decisions.
Please note that this is a follow up on my previous article on how to get started building design systems:
Why Tokenize?
Design tokens are the subatomic particles of visual design in a design system: named entities that store visual design attributes.
We define our design in a single location and use a system to cascade it down to all platforms. Salesforce Design
These central and tiny pieces of UI information will be used across several brands and platforms, allowing you to catch consistency, interoperability and fragmentation issues.
Establish organic relationships between elements to facilitate changes to be implemented on different platforms.
Options
Hard coding style properties (eg. border radius, padding, animation, or in this case, color) doesn’t scale. List your style options by substituting values that are subject to change with variables that will handle change.
--color-primary: #f74d7b--color-neutral-0: #ffffff
--color-neutral-20: #f5f5f5
--color-neutral-40: #dcdcdc
--color-neutral-60: #aaaaaa
--color-neutral-80: #7e7e7e
--color-neutral-100: #303030
Tip: use meaningful scales with meaningful names.
Start with few options, and agree on a scaling model that lets you add steps later: xs/s/m/l/xl, or lightest/light/base/darker/darkest.
The resulting list of key-value pairs are your options: in this case, your primary brand color, and greys ranging from white to the darkest grey you intend to use. This is great, but..!
The gap between naming and use remains. We answered the question “What are my options?” but left “What choice do I make?” unclear.
Decisions = Option / Context
A system’s strength comes from knowing how to apply options to contexts, Nathan Curtis argues.
Like applying ‘color-neutral-80’ as the default text color is a design decision. It is now time to document your decisions in a way the whole team will understand:
--font-color-base = "color.neutral.80.value"
--font-color-light = "color.neutral.40.value"--background-color-light = "color.neutral.0.value"// similarly with font decisions--font-size-paragraph = "font.size.m.value"
--font-size-microcopy = "font.size.s.value"// and any other decision you take--space-inset-default = "size.space.s.value"
--button-border-radius = "size.radii.pill.value"
Doesn’t this look just like a big ol’ spec sheet?
This practice of matching two abstractions is commonly referred to in software engineering as a ‘middle layer’. We introduce tokens that make sense at the component level but receive data from universal design tokens.
All of our tokens now become readable, understandable, and traceable decisions. With this shared structure in hand, designers recognize the impact of their decisions, start to collaborate, and make decisions with more deliberation and confidence. They/we finally are a part of the development process.
Sharing Tokens
To effectively share your design tokens you’ll need to store them in a format reusable across platforms and brands, using consistent naming rules.
The simplest way i found was using Style Dictionary, a free build system by Amazon that provides a single place to create and edit your styles, and a single command to export these decisions to all the places you need them (iOS, Android, CSS, Sketch files, style documentation, etc.).
The structure suggested by Style Dictionary sets a base line for naming your tokens. If you don’t have a particular way set up already — which by the way is totally supported — I suggest you just start from the provided examples.
Tip: Find detailed implementation steps by Cristiano Rastelli here.
Once you have your main distribution channels set up, you can think of how to extend the system into design tools like Sketch or Framer (more on this in the resources section at the end of this article).
Takeaways
It is easier than it seems. Instead of writing a long list of guidelines, simply write them up in a JSON document — or even better: edit an existing token library to suit your needs. And try it as early as possible.
Even though the concept of Design Tokens seems a bit technical, the truth is that it’s more related to design and the architecture of a DS rather than code. Gonzalo Vásquez on Design Tokens
- Options → Decisions
Organize your decisions to suggest their atomic basis — options to decisions, simple to complex. - Prepare to expand
Start with colors and fonts, keep adding decisions as you make them - Invite contribution
Help team mates weigh in on design decisions, suggest changes and give feedback
Further reading
Lessons on Design Tokens by the Mother of all Design Tokens, Jina Ann (paid)
