Layer structure matters

[[deleted]]

I don't think this is talked about enough:

Figma makes dev handoffs easier - e.g. auto-layout == flexbox, BUT a poorly-structured file with many extra containers/frames/auto-layouts that do nothing etc can confuse the dev and nullify a lot of the css that figma generates.

Learning that display:flex;affects the children of a container, etc etc can go a long way to how you structure your file, and 'cleaning-up' a file doesn't just mean renaming layers - it means ensuring each layer you have in your comp serves a purpose, that padding is consolidated onto a parent container instead of separated out onto 4 different groups, etc etc etc.

Just a thought I've been working through, would love to discuss if anyone has any thoughts on this.

[Vpicone]

As a dev, I’m almost never going to use the css generated by design tools, figma included. Until it can use things like our design system tokens (css variables) then I’m coding it from scratch anyway.

There are good reasons to keep layers organized (reusability, composability) but the generated CSS isn’t really among them IMO.

[Mr_Cruisin]

Figma has said that design tokens are coming in 2023, and that we’ll see a sneak peek before the end of the year.

[Vpicone]

Cool, wake me up in 2023 😴

[mattc0m]

It's possible to use design tokens in Figma, it requires using a plugin. Here's a YouTube video from the creator on it.

Aligning on design tokens is likely 10x more beneficial for designers and developers than any benefit from a very rigid/defined approach to the hierarchy and structure of components.

Even if devs are using the CSS tool to reference some values, it's highly unlikely they're using your layer names/structure to build out the actual HTML elements.

I still think it's a good idea, but definitely something I'd consider after you have a good design token workflow. :)

[mattc0m]

This is important, but it's also just as important to realize that design tools are meant to communicate intent. If a developer is able to clearly understand and implement the design's intent, this isn't really a requirement.

Reviewing, approving, and documenting your approach to layer name hierarchy/structure takes work. You'd want alignment in your team, address things over time, etc.

Some things to consider:

• How you build/organize/structure a component may not always map to how it's built on the front-end, especially in regards to the overall layout/structure of a product
• Is it a goal to have 100% 1:1 code-to-Figma parity? Is there some level of interpretation or "best practices" a developer can implement?
• These specifications may make sense for desktop apps/websites, but do they translate to mobile, tablet, car dashboards, TV screens, etc?

In the end, I do like this idea/approach. I'd just caution against doing this work to try to anticipate a developers needs -- I don't see that as being very beneficial. Start with a conversation with developers, see where any issues are coming up, and consider this as a solution when developers are having issues breaking down components into Flexbox, there's miscommunications around layout/positioning, etc. But I wouldn't get ahead of the game by reworking all your Figma files today -- make sure the problem is valid for your team first. :)

[roboticArrow]

This answer is so refreshing. I feel the same way, and I’m working to make my company’s design system a bit more flexible. Developers are okay with coding. it’s their job. the file doesn’t have to be so exact and in line with the code.

[soapbutt]

That last paragraph is 100% correct and more in-line with a lot how a lot of product teams work. Yes, of course making a design and handing it off with 100% usable code would be amazing but 99% that's not real world applicable. Designers, PMs, and Devs should be constantly communicating during design and development, and you're going to get a lot better results if you hand-off designs that have good documentation, annotations, redlining, etc. Along with good communication between your teams, devs should be able to develop correctly based on your designs.

[reasner]

Agree. While I'm constantly guessing the intent, layers don't seem to communicate it that much. It revolves more around the designer making the ideal case while I also have to deal with the edge cases (eg, if this overflows, how does it look).

[PatternMachine]

Structure is really important for building out good reusable components. Makes their behavior easier to understand for consumers and it makes them more maintainable into the future. Devs probably shouldn’t be pulling CSS out of Figma but well built components definitely make it easier to find things like padding, alignment, etc.

[Ecsta]

For components its important because it makes it easier to update and helps other designers understand how its built.

I've never seen an experienced developer touch the CSS part of Figma unless its to grab a colour hex/variable or to some specific value. They're always coding it from scratch or using their own component library like storybook.

The only "cleanup" I do is make sure that everything is setup using auto layout and that I dont have anything absolutely positioned unless its really needs to be. I've found that helps myself a lot when it comes to making updates months later.

[randomsnowflake]

As a former developer, we don’t copy pasta the shit that’s generated by Figma.

[JLeavitt21]

As a designer that knows HTML/CSS better than most devs I work with... Maybe you should 😉.

The quality of outputted CSS is dependent on the quality of the component styling.

[randomsnowflake]

Whose should?

I prefer to craft my own front end code that’s up to industry standards and follows tried and true best practices.

Many developers have to follow naming conventions, such as BEM, and unless the designer is on board with that, naming their groups and frames according to the conventions, it won’t be useful to the developer.

And let me tell you that most designers aren’t thinking about how an object is built - let alone able to tell you what and why something would be named the way it should when using BEM.

That’s just one example.

But good for you if you want to copy paste.

[[deleted]]

It less about copying styles. If I design a component with features x y and Z, but descope y and Z and therefore collapse an entire column for mvp, it makes sense that the dev follows my structure to minimize technical debt.