This is the second in a two-part series for designers and frontend developers. In part 1 we established that Figma's Auto Layout is a direct mapping to CSS flexbox. Now we're going deeper: if Auto Layout properties map to CSS properties, then Auto Layout nodes should map to HTML elements. When done well, your Figma layer hierarchy becomes a blueprint for the DOM.
As a designer, you're not just designing how something looks — you're influencing how easy or difficult it will be to build. And one of the biggest time sinks in design handoff isn't visual at all. It's structural.
The Problem: A Bloated Hierarchy
When developer opens your Figma file to implement, say, a card component, visually, it's straightforward — an image, a title, some body text, and a button. But when they inspect the layer structure, they find this:
Card
└─ Container
└─ Content Wrapper
└─ Inner Content
└─ Text Group
└─ Title Container
└─ Title
└─ Description Group
└─ Body Wrapper
└─ Body Text
└─ Action Wrapper
└─ Button Container
└─ ButtonTEXTIt's a little bit excessively nested. But big deal. Oftentimes it's just the result of copying and pasting components from elsewhere in the file and while it might inherit another nested structure, it's faster to just copy it wholesale.
But have you considered how much harder deeply nested hierarchies can be for the developer to comprehend and implement? While keeping the hierarchy organized may not feel important, as the nesting accumulates gradually frame by frame, what should be a simple implementation becomes a hair-pulling exercise for the developer to accurately transcribe.
Digging through Auto Layout nodes in Figma to find the box model and spacing information and translating that into an optimal DOM structure takes time and effort. It's a missed opportunity because it could be solved at source
Here's what the developer may see: three extra levels of unnecessary nesting for what should be four elements. And if we were to map those Auto Layout frames to HTML elements and each of those wrapper frames becomes a
<div> in the DOM, the resulting HTML would look like this:<div class="card">
<div class="container">
<div class="content-wrapper">
<div class="inner-content">
<div class="text-group">
<div class="title-container">
<h2 class="title">Card Title</h2>
</div>
</div>
<div class="description-group">
<div class="body-wrapper">
<p class="body-text">Description goes here</p>
</div>
</div>
</div>
<div class="action-wrapper">
<div class="button-container">
<button class="button">Click me</button>
</div>
</div>
</div>
</div>
</div>HTMLExtra elements that are surplus to requirements, making the DOM bloated and the code that bit harder to read and maintain. OK, it's a bit of a crude example because the developer would typically sift through the Figma file to pull out the styles and flatten this down to the most essential DOM nodes when implementing the design. Doing so makes it easier to read and maintain, and makes you feel like you care about what you do.
But therein lies the point. Digging through Auto Layout nodes in Figma to find the box model and spacing information and translating that into an optimal DOM structure takes time and effort. It's a missed opportunity because it could be solved at source.
The Insight: One Frame, One Element
Here's the shift in thinking: when you create an Auto Layout frame in Figma, consider that it will likely come to represent an HTML element. Not metaphorically or philosophically. Literally. That frame will likely be converted to a semantic HTML element be it a
<h1>, <section>, <aside>, or some other container element when the design is transcribed.If you internalize this, you start asking different questions:
- Does this frame need to exist?
- Can I flatten this structure and still get the same visual result?
- If I had to describe every node in this hierarchy, would it make sense?
The object of the game here is a 1:1 mapping between your Auto Layout frames and the semantic HTML elements a developer would write. One frame, one element. Furthermore, the flatter the hierarchy, the more meaningful your document structure becomes and the easier it is to implement.
The most important aspect of HTML is that is describes the content. This is what we mean when we talk about semantics. Is it a list, an article, a sidebar, a header
That's not to say that nesting is bad, some designs need multiple layers of Auto Layout to flow correctly. It's simply to say that excessive or unnecessary nesting implies extra time and effort on the development side.
What "Flat" looks like
Let's revisit that card component. Here's what a well-structured Figma hierarchy might look like:
Card (Auto Layout: Vertical, Gap 12, Padding 24)
├─ Image (Fixed height, Fill container width)
├─ Title (Text, Fill container width)
├─ Body (Text, Fill container width)
└─ Button Row (Auto Layout: Horizontal, Gap 8)
└─ Button (Text, Padding 12 16)TEXTFour frames. Four layers. And when a developer implements this, they might write:
<div class="card">
<img src="https://example.com/images/example.png" alt="an example" class="card__image">
<h2 class="card__title">Card Title</h2>
<p class="card__body">Description goes here</p>
<div class="card__button-row">
<button class="card__button">Click me</button>
</div>
</div>HTMLNotice the difference from our earlier example? The structure in code still mirrors the structure in Figma exactly. No translation required and the result is the same The developer can look at your Figma file and know without thinking, what the HTML hierarchy should be because that work has already been done.
Practical Guidelines for Flatter Structures
Consider using padding and gap instead of wrapper frames
If you need space around content, consider adding padding to the parent frame. If you need space between items, use gap. You might not need a wrapper frame just to add spacing.
Adds unnecessary wrapper:
Container
└─ Padding Frame (Auto Layout, Padding 24)
└─ ContentTEXTConsider instead:
Container (Auto Layout, Padding 24)
└─ ContentTEXTConsider flattening groups that don't represent layout boundaries
If a group exists purely for organizational purposes in Figma — to keep the layers panel tidy, for instance — but doesn't represent a meaningful layout boundary, it might not need to be an Auto Layout frame. Auto Layout frames can become signals to the implementing developer that there will be some Flexbox styles to look out for so being intentional with your Auto Layout frames can make transcription easier.
Extra grouping layers:
Card
└─ Text Content
└─ Title
└─ BodyTEXTConsider instead:
Card
└─ Title
└─ BodyTEXTLet alignment properties do the work
Auto Layout frames have powerful alignment controls. Consider using them instead of creating a wrapper frame just to center something or align it to an edge.
Wrapper for centering:
Card
└─ Center Wrapper (Auto Layout, Align Center)
└─ ButtonTEXTConsider instead:
Card (Auto Layout, Align Center)
└─ ButtonTEXTThink in semantic sections
This is big one. The most important aspect of HTML is that is describes the content. This is what we mean when we talk about semantics. Is it a list, an article, a sidebar, a header etc. When you create an Auto Layout frame, consider what semantic HTML element it might become. Would this be a
<section>? A <nav>? An <article>?
The eponymous <div> element is semantically meaningless and regularly used for instances where no obvious meaning can be prescribed, so in many cases your Auto Layout frame might become a <div>. But in many other cases it might be a useful exercise to think about what HTML element you think it should be an even suggest that when naming the Auto Layout frame.The Payoff: Speed and Accuracy
When your Figma structure is clean and flat, developers can implement your designs faster and with fewer questions. They're not inventing wrapper elements to make the layout work. They're not sifting through the hierarchy figuring out which frames matter and which are just organizational artifacts. They're transcribing.
And transcription is fast. It's accurate. It doesn't require interpretation. The developer looks at your Auto Layout hierarchy, writes the HTML to match it, applies the CSS properties that correspond to your Auto Layout settings, and things work systematically.
A Note on AI-Assisted Implementation
You might reasonably ask: if AI tools and MCP agents can now automatically transcribe Figma designs into code regardless of hierarchy depth, does any of this still matter?
The short answer: AI can transcribe structure, but it can't necessarily infer intent. A well-organized Figma hierarchy communicates what matters — which elements are conceptually related, which need flexibility, where the meaningful divisions are. Deep nesting might get transcribed accurately, but the resulting code may be just as convoluted as the Figma file. Good structure is foundational.
Conclusion
When you design in Figma using Auto Layout, you're not just designing the visual appearance of a UI. Consider that you're also proposing the structure of the document and therefore the structure of the code that will implement it. It's the place where design meets engineering. So there is a huge opportunity to be intentional about how Auto Layout can also design the semantic structure of your web application.
And it's worth designing with this in mind. Challenge yourself to keep your structures as flat as you can without affecting your design. Use padding, gap, and alignment properties to do the work instead of creating wrapper frames. Ask yourself: does this frame need to exist? Am I spreading the layout styles across extra frames and creating more implementation overhead?
When designers and developers synergise in this way, the translation from Figma to code stops feeling like interpretation and starts feeling like transcription. Your designs become faster to implement, easier to maintain, and as a designer much more likely to be a facsimile of your design. The developer isn't guessing. They're following the blueprint you've already drawn.
And that's the point: you're not just designing the UI. You're proposing the DOM.