[Design System] Add more color variables to Craft + Naming Convention Discussion for Variables

Question

User Story: As a Webstudio user building large-scale websites with Craft, I find it annoying that when I change --foreground-primary, it also affects components I didn’t intend to modify (e.g my navbar and footer). This reveals that the system I built on global tokens isn’t as scalable as I thought. One change cascades unintentionally leading to manual work were I thought it wouldn't be needed.Situation:I am building a design system for a partner agency in Berlin right now. The directors have over 20 years of experience in brand design, so it's a great opportunity to build a design system that matches their expectations. I thought… let's give Webstudio a spin and build it the WS way (Craft, Open Props, Open Color, Custom CSS Variables). I would love to share my experiences with you – and if I can, help building design systems in Webstudio faster and easier.The first thing that came up: the "foreground" variables will not work in professional brand style guidelines. There are way too few. My idea to solve this problem is to split up the "foreground" colors into:brandtextborderProbably also other core components (but I will see while building)buttonnavbarfooterI also added a new color section "system" for success, warning, error.Have a look↗︎ Dev Page↗︎ Read LinkCurious to hear your perspective,@Webstudio Team, @Sam Gilbert, @Milan Boisgard | Uncode School and other pro devs and designers!

Hiram Broemme · Answer

Suggestion of a new naming conventionI resonated a lot with what @Scott Erickson said on the earlier design system discussion on Github ."Making the name painfully clear (even at the expense of brevity) will make your life easier when you come back to the project 6 months from now.as for the order, go from general to specific, in a parent_child_grandchild relationship. so testimonial-card_person_name instead of name_person_testimonial-card."¹ "We have to think about the ecosystem here... the folders function from Finsweet is a life changer... for this ecosystem to ever come out with something similar we need a parent-token_child-token naming convention like Client-first uses."² So I suggest this naming:1) Sort it from generic to specific (grandparent → parent → child)2) With underscores between the hierarchies (easier to read)3) Precise naming When there are more color variables I think it makes sense to add term "color" to the variable name to show it's relation to the design category "color". --foreground-primary → --color_text_primary--background-primary → --color_background_primaryPrecise naming is super important. Components of a large website sometimes change later. We should introduce Component Variables – contextual/semantic variables for each core component. For example, changing the page background shouldn’t affect the navbar. Design systems should scale with clarity, and shouldn't lead into chaos later on.Another thing: color variable names can't contain:Actual color names (since the color values can change, but the variable name doesn’t)Terms like light/white or dark/black (since they change with Dark Mode switched on/off)

Hiram Broemme · Answer

Other thoughts:I like the terminology for visual hierarchy: primary, secondary, tertiary, quaternary"muted" looks for me like "tertiary" in that logicSo e.g. foreground-mutedcould be color_text_tertiary or color_border_tertiaryEvery color has a described use caseI am still unsure how to name variables that are "flipped" in value. So let's say the page bg is white but our section bg is dark - call it _alternate or _inverted?,All of these incongruencies/questions/changes are marked on the design system I've sent you

Hiram Broemme · Answer

Thank you for reading! Look forward to a good discussion

yannick | revaliant · Answer

Just one Thing to add I agree in most of your points but a muted color is not a tertiary color. I can have my primary color muted as I can have my secondary color muted it's the same color but a tertiary color is something different, at least in my opinion.

Are your inverted Colors truly inverted or is it just an other color? In my opinion we wouldn't need a _alternate or flipped if you want to give a section a different color which isn't always the invert i would add color_tertiary or something like this so I think this would be a Tertiary for me.

You can have primary secondray and tertiary for all pages in muted(often used if you switch to darkmode) and Accents also muted.

Hiram Broemme · Answer

Ok, great, thanks for sharing the thought @yannick | revaliant.

So we use muted like color_text_primary-muted?

The idea of adding alternate additionally is to use primary, secondary, tertiary, quaternary strictly for visual hierarchy. primary attracts your attention first, then secondary etc. I found this precise pattern reflected in Apple's human interface guidelines³ (s. screenshot).

alternate allows you to create a dark section while the rest of the site is in light mode.

Hiram Broemme · Answer

One other thing that comes to mind. For each brand color, I added two versions: a solid and a soft variant. These can later be used for things like buttons – for example, the solid color as the default state and the soft one for the hover state.

Do you think solid and soft are naming conventions that can be brought into the whole system?

Hiram Broemme · Answer

I just visualized the whole thing in a table – I think it's easier to get the structure this way. Also concatenated the variable (once with underscore, once with dash to compare them).

https://docs.google.com/spreadsheets/d/1x7HevKMME0daa89SCCliYLp5ExOGn_294Bh_IGGP4qc/edit?usp=sharing

Join the Webstudio community

[Design System] Add more color variables to Craft + Naming Convention Discussion for Variables