#Figma Variables from loose colours help!

17 messages · Page 1 of 1 (latest)

agile prism
#

Hi, Everyone.

Variables help here. I have two Collections, namely Primitives, where I store the default colours and values and Tokens, where I reference my alias to the Primitives.

The Problem
Originally, there was no brand or colour palette associated with the application. So, I had to use the colour picker to create the primitives manually. Also, the way I named them in the primitives level was based on the state (default, hover, pressed, etc) of the UI component. The way I named the alias references the primitive name (ds-dropdown-input-fill/default), for example. I provided two screenshots showing the structure, naming, and categorizing. The Tokens naming convention is the same as the Primitives one, except I added "ds" before the Primitives.

Questions

  1. Is this considered best practice? I based the colour variables on colours that did not have a palette to begin with, so I thought it would be easier to maintain the growing list of colours assigned per UI component (dropdown, button, split-button). Some are the same; some are not the same, which made it harder to begin categorizing the colours. This application runs on Microsoft, so I have had difficulty looking for the palette since it was created a while ago.

  2. Is there a way to go back and try the default approach of creating the palette, assigning primitive variables, and referencing primitives to the tokens from my existing Collections? This is probably not possible because then I would have to manually categorize the colours that need to be organized in the first place.

  3. Is there a better naming convention in my Primitives Collection so it is shorter, concise and specific given my use case?

  4. Should I stick to this method?

Thank you.

primitives.png tokens.png
tender sparrow
#

Primitives are the base base colours with no information. Nothing should be repeated. Neutral-100 , Neutral-900 for your lightest and darkest neutrals respectively. Primary-100 - Primary-900, Secondary, Tertiary, Accent. You obviously don’t need 9 shades/tints for every colour but use the scale for naming. You may have only an accent-500. Then once you have those set up , you make your Semantic levels with those. That’s where you would have surface-primary , surface-accent etc (there’s a fair bit of acceptable naming conventions) and their values would be assigned FROM the primitive collection. Eg

surface-default: secondary-300.

On top of that is where you could (but don’t need to) have a components level, esp for a small project. THIS is where you would reference your components , that are pointing to the semantic level eg

input-surface-default: surface-primary

I could go on forever abiut this but there are a ton of resources out there that will answer your other questions. Figma just did a QA live stream recently and they talked a fair bit about design systems/tokens

#

Everyone’s got their own take and opinion on how to name the levels but as long as you stick to a hierarchy and tokens are easily understandable from their name, you can start to form your own preferences of naming conventions. There are some designers who think it should be a 3 letter acronym but in my opinion that’s not understandable to someone new coming onto your team, it’s one more thing you have to explain to them and make a cheat sheet for. Being more verbose dues save time and brain power in the end, in my opinion.

agile prism
#

Thanks for sharing your knowledge, @tender sparrow I saw the video last night, so I went back into my DS file and rethink how I can make it more useful. Basically, I have to re assign the colour variables after re creating the primitives because each variable is specifically set for every UI element, right?

tender sparrow
# agile prism Thanks for sharing your knowledge, <@961235371537096714> I saw the video last ni...

The point is NOT to make a variable for each UI element . If your palette has 3 colours with various shades and tints , you make one Primitive layer referencing those. Each hex code will have one variable assigned to it.

Then on the semantic level you sit and think and plan how you’re going to use these colours. You then assign primitive variables AS the values of the semantic variables. Very rarely do you need component levels in small projects.

Once you have semantic set up you go through your page , apply maybe surface-primary to your page fill, then surface-secondary as a section background , surface-tertiary as a button background, surface-secondary as your input-border. The system is meant to be reusable and easy to change your whole palette in a few clicks if needed. If you’re going to make a separate variable for every ui element you may as well just set it as a raw fill/stroke; you’re not saving any time or creating reusable tokens.

Not sure which video you’re referencing as a sent many but I’d recommend going through and watching if you’re actually curious to know how to set it up properly

agile prism
#

The video that was uploaded last night as well as the other videos you posted.

#

I'm going to have to reduce all my repeated variables into a primitives collection and reference them to my tokens as you've said. The planning part will be tedious. I'll probably create document to say what hex and what primitive variable to use when re-referencing them to my tokens.

tender sparrow
#

The nice thing about Figma variables is if you plan to do the component level or expand your semantic collection, if you right click on the variable you can limit where it’s available. Border-primary can be set to only be available as a stroke. As far as numbers, you can set margin-small to only be available as a gap or padding. Radius-md can only be available as a border radius

#

But it really shouldn’t be as tedious as you’re thinking. If a separate document helps you , go for it but you can also look at your wireframe and set up semantic variables as you’re looking at one of your frames. Small projects shouldn’t need a lot . And do the research! The info is out there and free! I’m not seeing a video uploaded last night or the last couple days but there are tons and tons of videos and articles and courses on this. Take what you learn and shape it into something conventional that other designers will understand but in a way that works for you

agile prism
agile prism
tender sparrow
#

Also go through community files and look at how professional designers laid out their variables

iron estuary
#

hello, can't resist to participate to the discussion 😄 , actually, have you created 1 variable for each states of a component ?