There are a lot of questions at the moment about colour tokens and Figma soooo
I thought I'd thread some thoughts on it to create a healthy discussion in public 🧂
Some assumptions first:
• This is *in Figma*, not talking about code
• You have a Figma design systems team set up
• You're at least splitting up styles and components into two files
And very importantly!
There is almost no *right* answer, but you've got to start somewhere
I'll be using some terminology in this thread which makes sense to me right now, but will probably horrify you 😱
The style ➡️ components relationship in Figma
Right now, the recommendation is to use slash naming conventions to create folders with your styles
This will eventually map to a similar model for your non-Figma tokens too
(these are example style names)
Alright, the token relationship!
The relationship goes like this:
1️⃣ Your base value (e.g. #ffffff for white)
2️⃣ Your base token (e.g. Mono/100)
3️⃣ Your token alias (e.g. Input/Fill)
An example – an input field
A question to ask: are there shared component values?
Yes? You can bundle the tokens to start with
Here, we bundle border, text, icon into a token & fill is split
(Content) + (fill)
Remember when I said this would cause discussion? 😅
What if you don't have shared values? Split the tokens!
Here's an example that isn't too realistic, but shows how you could structure the styles, with a separate token alias for:
• Border
• Icon
• Text
• Fill
This would compound when we add states too 😬
Alright, alright, what about variations of components?
Well, they will still likely have shared styles, so we can bundle certain bits and split the differences
Here's an example of the input/search with a default and error state
If you want to be *even more descriptive*, you could do something like this
This example shows the same token value, but the application is hyper specific
e.g. grey/400 is split into every aspect of the input – border, icon, text
Overkill? Probably, yes
Readable? Definitely!
Important notes:
• Specificity is easier to read, harder to manage
• Within Figma, it's (probably) easier to optimise for reuse, rather than being overly descriptive
• Right now, your code tokens and Figma styles will probably have to be differently named
More notes:
• I've used "fill" here to represent what other people call background or surface, this is something we argue about in the team all the time
• I've used "content" to bundle the inner elements of components. This is *my* name, which again might not be what you use
Finally, tokens are really difficult to learn and I'm not an expert at all – just ask my team!
It'll take time to learn, and even longer to use effectively, but start somewhere
I'd advise taking a component in your library and trying to break it down first into logical aliases
Thank you to @HonzaTmn for helping me to simplify the visuals 🙌🏻
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It's common during the handoff process to provide screens to our engineering teammates by "throwing designs over the fence"
We've all been there!
This puts pressure on devs to play a game of spot the difference, finding minor changes between screens 🔎
We can simplify this 📣
The red circles are the true differences, sooooo why are we duplicating *everything* from each screen?
This is inefficient from both sides:
– Designer must track identical screens, with changes doubled* every time there's a modification
– Developer is playing spot the difference
Let's remove duplicate screens!
Instead, we can show *component* differences alongside the main screen
Then group them with a section & use component labels to describe the differences
The developers then just need to look at one template, and read the component differences 🪄
How can you use component props for contextual spacing?
For example, an icon that needs a 12px margin in *some* instances?
– Create a spacer component
– Place that inside a wrapper component for your icon
– Nest that one inside your main component
– Bubble up the props
Going to try and explain this in tweets.
Step #1
Create your icons
Step #2
Create a spacer component with fixed size auto layout
Step #3
– Create a new icon wrapper component
– Nest one icon and the spacer inside
– Duplicate spacer & place either side, then rename the instances to "left" & "right”
– Add visibility (boolean) props to spacers and the icon
– Expose nested instances for spacers and icon