Currently there is a huge limitation in prototyping possibilities because any dropdown menus appear underneath the following element in the autolayout flow.
I can’t remove autolayout because it would break designs across all useage of design system components and we can’t properly demo prototypes. Anchored by the lack of a customizable z-index property.
Hey @Slava_Bronevitskiy thanks for sharing this feedback. It’s definitely something the team is aware of and thinking through.
November 2025 still having issues with z index management.
In the example I attach below, I’ve set the stacking as first on top because I need the gradient on the background to be under the carrousel. I need it to be under the faqs box too. However, as the faqs box is positioned after the text with the gradient background it stays below.
Perhaps I could set them both in a new auto layout, then change the stacking order for them both on that new AL. That way I could keep the page AL as first on top. However, it would be much easier to have a z index input for each AL child.
There are lots of other ways Figma could enable this. “Always on top” or “treat as overlay” or even allowing components to hold onto overlay interactions in prototyping. It’s frustratingly difficult to do something as basic as build a menu that reliably opens in instances.
I think it is genuinely insane that this has not been implemented. It’s completely messing up my attempts to make sticky elements because for whatever reason, the autolayout overrides the “always on top” behaviour of sticky elements and everything scrolls in front of it! What is even the point, then?
The team was “thinking this through” 4 years ago, did they somehow come to the conclusion that this is unnecessary despite this being crucial for accurate prototypes? I cannot rely on hacks forever.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.