Make it easier for viewers to select nested frames for icons export and layout inspection

Question: Let’s say I need to use a 16×16 pixel icon for my UI design, so I place a star in a 16×16 frame. I want the viewer to select the frame instead of the star. So I think frame could add an option to prevent the viewer from selecting its content.

I’ve also found some solutions on the Internet, but none of them are perfect.

  1. Ask the Viewer to hold the command key and click (the problem is that the target frame may have many parent layers, which may cause the Viewer to click several times before selecting the target frame).

  2. Use a ‘slice’ layer to mark the size of the frame (the problem is that the Viewer clicking still selects the star instead of the slice, so Viewer has to look for its parents layer to determine the star icon’s size)

  3. Use ‘Rasterize Selection’ to convert the frame to an image (the problem is that the converted image is only @1x, which is very fuzzy and unfriendly to either Designer or Viewer).

  4. Create a layer with 0.01% opacity fill over the star. This will not be visible to our eyes, but will prevent the Viewer from selecting the star (but developers will select&export this transparent layer instead of the star).

So I think maybe the frame needs an option like “prevent viewer from selecting content” after “Clip content”, which would be a perfect solution to this problem.

Hope the officials consider this issue. If anyone has a better solution, please reply. thank you
(English is not my first language, so maybe there are some mistakes. Forgive me :pray:)


I agree, that would be great. I’m not sure this exact solution would be ideal, but solving this problem in any way would be awesome.

There are two more ways you can solve this problem right now:

  1. Create a separate place somewhere where you put all your component icons. Like a UI kit. The developer will be able to select these more easily and export them in one go. I’m pretty sure developers would even prefer this approach instead of exporting the icons right from the design files. Moreover, you can prepare them better here by flattening everything into one layer while keeping your original component icons fully editable.

  2. Manually add necessary export settings to icons. This way developers will be able to export all necessary icons by simply selecting the frame and going to File → Export… (this feature allows you to export all items marked for export on the selected page/in the selected objects) in one go. However, this has the disadvantage over the first approach: you can see on this screenshot that different icons have different colors and developers will usually prefer to have all icons monochrome and just color them where they are used.

Examples taken from my Starter Design System file:


Very happy to see your reply.

Your reply is very useful. In my daily work, I also put all the icons in a public frame for developers to download.

However, I have noticed that some developers still download it in the design files. There is an even more troubling problem, when developers need to set the position and size of an icon, it’s easy to make mistakes because they selected the star instead of the frame.

This adds a lot of extra trouble to us.:joy:


Good points! The fact that your developers do this probably means they need to be educated just a bit more about using Figma. Specifically, all they really need to know is outlined in the article about using Inspect panel, or even just this section of it.

Regarding the position and size — I suggest a solution that is similar to yours but a bit better. Actually not sure why I haven’t thought of it before, I think it’s pretty good for it! Mostly inspired by @Gavin’s idea he shared on Twitter some time ago. Here is what you need to do:

  1. Give the icon the background with 0.01% opacity fill of any color.
  2. Lock all vectors in the icon so they can’t be selected.
  3. Call the style something like “_Workaround — don’t use!” so the developer knows not to use this color for background.

Done! Now they can only select the icon container and not the contents. Here is what they will see in the inspect panel (and check out the file)

However, when exporting the icon, they will have to manually remove this background. For me as a developer, this would completely ruin this approach and I would be willing to go to the extent of reading a couple of paragraphs on how to properly use Figma and export your icons in bulk, not download them from the design. It seems quite weird to me that they do it.


That’s a great solution! I’ll try at work.

Yes, we told developers how to use Figma when we switched from Sketch to Figma last year, and most developers were able to download the icons correctly. My last reply was actually that they downloaded the right image, but when they coding, they selected the stars (not frame) in the design to get the size and position. So, this leads to mistakes in the final UI.

Of course, our design team worked to deal with this problem. For example, I mentioned above that I use Slice to mark the size of an icon in a design, and some colleagues have a habit of adding background colors to frames to help developers identify them. These solutions have greatly prevented mistakes. But developers often complain to us that they need extra steps to determine the size of the icon. In addition, new developers will have the same problems as before.

They said “extra” because the handoff platform we used with Sketch previously didn’t have this problem, we simply created a slice or transparent rectangle at the top of the icon to prevent the developer selecting the content of the icon. They just click on the icon in the design to get the correct images and their size.
There’s a plug-in on Figma called Juuust-Handoff, and Slice in that platform can stops clicks from going through; Also, when adding an “export” to a frame, it is also possible to disable clicking through the frame. I think this plug-in is very suitable for our team habits. But the disadvantage is that it can only export local web files instead of uploading them to the cloud for cooperation.

However, the method you provided is useful. At the same time, I hope the Figma team can have a better plan. Thank you so much for writing so many words to help me.:+1:


good I salute you!!!

I think this needs just a simple fix - Enable viewers the same clicking experience as for editors. I. e., when they click, they click the parent first, not the children. Then they would just click through as deep as they need. Of course, they could just hold cmd / ctrl if they needed to get to the children right away.


Yes, it does go some way to solving the problem. But if so, they will complain that they have to click too many times to select what they want. :sweat_smile:
Also, we’ve experienced many design handoff platforms that generally allow developers to go straight to the deepest layer of the design. This kind of interaction design may be more suitable for developers.

Well, of course there is a more intelligent solution. Go to the deepest layer, but not in components. I. e. if I have a component in a frame, when I click on a component, select it first. Developers likely don’t need to see the details of the component, they’ll just put it in the screen. Zeplin does this well.


I think this goes for designers using component libraries as well. So for example, in the Microsoft Fluent iOS library, if I click this progress indicator, it selects the child layers (the grey bar OR the blue bar) but not the entire component by default.

Maybe this is just a difference in muscle memory I need to get used to still (from, say, Illustrator which always selects the Group first and then you can continue to double-click to delve deeper into the hierarchy), but I find it far more common that I want to move/copy/select a full group/component rather than going to the bottom of the ‘depth’ to grab the deepest child object.

1 Like

For designers deep select works the opposite way so you would select the group first unless you hold Cmd/Ctrl. File viewers can reverse this too: they can hold Cmd/Ctrl to select groups before contents.

1 Like

By “designer” do you mean an editor vs a viewer? That may be true, but at a large design org I won’t have edit access to all files, so therefore I (a designer) only have view access and it appears to be depth-first.

1 Like

Editors need to press Cmd/Ctrl for deep select. Viewers need to press Cmd/Ctrl for normal direct selection.


It would be great to be able add some special symbol to layer name to resolve this issue (*layername) :slight_smile:
1 symbol added by designer - 1 pick for developer. No more mistakes and stretched vector shapes instead square icon :slight_smile:

1 Like

We’ve transitioned from Sketch to Figma too, and are slowly moving things away from Zeplin at the moment. Maybe its a designer thing too, but I was testing out this issue and had a similar problem, that I only want a developer to be able to click the top layer - especially when I’ve dragged in global icons from our library. Just something that we’ll need to train our devs on if they don’t know already.

What is also slightly annoying on top of this is that marking an icon/layer for export in your global library does not mark it for export in your working file. So you have to still go through the trouble to marking them all again.


When using cmd+click to deep select an element the deepest element gets selected. This is less than ideal when using a fleshed out design system with complex variants as a lot of the time you will select a layer inside of the component and have to move up the tree to select the actual component.

Aside from being annoying in general it also means that consumers of the design system are more likely to set manual overrides instead of utilising the provided variants as it’s easier to miss variants if you happen to select the wrong layer.

It also makes it harder for devs to select the correct component when inspecting.

The logical solution here would be to make it so that locked layers aren’t selectable through cmd+click (they already aren’t), but have the component remain selectable. Allowing for this flexibility would be very helpful for selecting the correct elements with the fewest amount of clicks.

Does anyone have another good solution for this that I’ve missed?


To add to the discussion… I find that it’s fine, and I can click a component though the cmd selection, and then cmd + shift (repeat until necessary) to get the parent component… However, when I want to select five more of the same component and move them / align them I can’t just select the parent component. This is seriously hindering my productivity. Why can’t I just select the same component, from different frames?

1 Like

Yes, same problem here. We are trying to teach our client to use a complex design system with many nested layers, and there’s no way to easily get to the container that allows you to switch the variant without command-clicking and then navigating back up in the layer tree.

It would be great to be able to switch off ‘Direct deep-select’ for certain layers.


I have the same need, I find that the current viewer setup is better suited for organizations that lacks an established design system (or a more loosely defined system).

My developers always complain that it’s hard to find what actual components were used as they constantly find themselves selecting shapes instead of the actual components that they’re trying to implement.

(Actually, I would say that Sketch handles strictly defined design system components better with its more rigid and configurable controls)