Skip to main content
Question

Who should manage CSS colour variables in a web project? Design or Front-End?

  • August 27, 2021
  • 3 replies
  • 1687 views
heyadaho

We’re working on a multi-brand project where the site must switch between company branding.

To do this we have CSS colour variables in place switching between styles depending on what brand is using the system.

The design team have been tasked with managing this by the front-end team and applying the matching named colour styles in Figma and documenting in a system based chart.

5FAQT

This is taking up a lot of our time and resources and slowing down our design time greatly as we have to create, document and attach all these new styles with the design files as opposed to working with a set palette from each brand. Creating a lot of additional work and duplicate colours styles in our design system. So the front end can inspect and see what colour variable has been applied. Rather than a single colour.

In what team would this responsibility to document this logic normally sit? I feel when a variable is introduced this should be handled in the CSS and the logic is managed by the front-end as opposed to complicating the design files with multiple styles?

Any experience in this? Your advice is greatly appreciated 🙏

    3 replies

    Eric
    • Eric
    • 20 replies
    • September 22, 2021

    Some places have a dedicated person to do/organize/keep track of this type of thing…

    It also depends on how good/receptive your front end devs are. It also depends if you use tints or whole hex values.

    I don’t know if there’s a right answer, brand palette should be defined, usually we have to “add-on” to the base brand for the usual things.

    Most roadblocks are front end devs not caring, not being good with sass.

    Basically it’s more of a process/people problem then it is a technical problem. I find 80% of common complaints about ux/ui are people/process problems, not design or technical issues.

    So, make a process, get buy in, if it fails or it’s not receptive, or no one cares, try to get rid of the task, if you cant, move jobs. People don’t know, or don’t care. Lifes too short for these headaches. I don’t listen to my own advice.

    Cristina_Martinez_Fernandez

    Hello @heyadaho
    I am working in a similar project. Can you find interesting share our knowledges?

    Mojo
    • Mojo
    • 67 replies
    • March 6, 2022

    There’s a lot to discuss here… dunno where to start, but I would love to chat more with you to understand where is the current pain now.
    For my processes at least, variables always start on design, maybe even unwillingly, but you start creating style variables to preserve your work and save time… so why don’t be aligned with frontend too, and setup the steps to follow.

    Is much easier for the communication and also to prevent errors of developers missing or duplicating code / logic.

    Component definition, naming, and styles, come always from the product side, and we are the closest area to that.

    I would also like to point out, naming conventions are super important, it would be great for devs and designers to be in synch with these matters.

    Probably that would also ease some of the pains you might be having on logistics, how to name things, etc. For example: I noticed you are naming colors by their HUE and not by their purpose. That can greatly hurt you in a short/mid term stretch.
    Imaging you have a color named yellow, and of course, is yellow, now imaging devs implement this and after, brand comes and says to you that his new primary color is no longer yellow… now your naming convention has no ground to support itself, both you and devs need to update code, rename and change colors.
    I would recommend sticking to usage-oriented naming, like, primary color, secondary, alert, success, accent, link, what ever, but always purpose oriented.

    Reply


    Terms & ConditionsCookie settings

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings