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
The more I talk to hiring managers and senior designers about what they are looking for in designers, the more I back up the theory that portfolios shouldn't be X, Y, Z case studies, but explorations of your obsession with details
Showing deep, deep examinations of your solutions AND what you didn't deliver is a really great way to show how you approach solving a problem
A slideshow of solutions doesn't show anything below the surface, just a public-facing polished mockup
But jumping incredibly deep into your rough work can show that you really do take the end to end product process into consideration when solving a problem
"this didn't work, because..." is a fascinating discussion that I know would be way more interesting than "here's a flow"
Been asked a lot over the past few days about how to get started with colour variables, so here are some pointers 🖍️
Hope this is useful!
As usual, before we get started here are some T&Cs:
• These are my opinions, take with a grain of salt!
• You will need more or less of these options, adjust to your team's workflow
• Tokens are opinionated, bring your microphone
• Tokens are angry, enter with care
The types I'll discuss are:
1️⃣ Bg = Background
2️⃣ Text = Text!
3️⃣ Border = Also known as strokes
4️⃣ Icon = This is a layer I'm personally adding on, will explain why
Let's take a look at the four types of colour styles you might build / encounter in your systems 🎨
• Raw values e.g. #CC8700
• Base tokens e.g. Yellow/400
• Global tokens e.g. Warning/Primary
• Component tokens e.g. Alert/Warning/Text
The last layer (component tokens) may be overkill for your needs, and you might not need to get that specific!
The "levels of abstraction" are down to how sophisticated your system might be, and you may not even need...any of the last three if you're okay with raw values😄
The way I have structured this, with the arrow inheritance, should indicate that you follow a path down from abstract raw value down to specific component token value
Each level introduces control – providing the systems team with a much stricter way of managing styles
Here's another thread about managing Figma styles 🗂
It's pretty hard to know how far to push naming conventions on styles, and you can end up in some heavily nested folder structures if you're not careful
So let's take one component and work it out!
As usual, these are thoughts / ideas!
There's not necessarily a perfect right answer, but hopefully this sets you up with something to think about 💡