If I’m building components for other people to use with the potential for multiple elements, like a tab set, what is the best way to structure them? It seems it’s not possible to manipulate an instance by adding tabs – so would it be best to create many tabs they can turn off OR have them detach an instance to add/subtract tabs? Or are there other options?
Hey Eric,
There is a third option you might consider, which is using placeholder components. Some people also call this the “slot method.” The idea is that when you need to build a component whose contents you cannot predict the size of (such as a tab set, a generic card, modal, checkbox options on a form field, etc.), you add a placeholder component that designers can use to swap in their own content. @Adam_Ruthendorf-Przewoski has produced an excellent video tutorial demonstrating how to put this method into practice.
What’s great about the placeholder component method is it avoids the negative tradeoffs that have to be made with the other two methods you mentioned:
1. building a component that’s meant to be detached
• 
let’s designers freely manipulate the detached component. Because they can add or remove tabs in the tab set to get the exact amount they need, they can keep the layer-count low and the file will stay performant.
• 
designers have to detach from the main component, which means they won’t receive any updates made in the future. This puts them at great risk of producing visually inconsistent mocks and prototypes.
2. building in layers that designers can hide/show
• no detaching means all instances of the tab set will maintain visual consistency!
• you, as the component manager, have to make a call about how many tabs to include. A higher number means you’re covering most, maybe even all, use cases… but that comes at the expense of memory usage. Figma has a 2GB memory limit, and the things that eat away at memory most are layers, and images (especially high resolution ones).
The good news about the placeholder component method is it wins out in both those areas: layer count stays low because (like the detach method) designers can include only the content they need, and they never need to detach from the main component.
The learning curve for implementing the placeholder component method should be low because designers are likely already familiar with Figma’s component swapping capability. A very common example is swapping one icon for another nested inside a component like a button. What I think can make this method of working hard to put into practice is expanding how we think about components in Figma from “user interface elements that can be reused across your design files” to also include: content needed to build realistic mocks and prototypes. Figma does not yet have a robust system for managing content, but in the mean time we can exploit component swapping for this purpose.
Hope this helps!
2 Likes
This is great technique to know about. So would you see the workflow for the designer as such -
- Pulls out component
- Builds the content
- Turns content into component
- Replaces original component sub area with newly built component
If this were a tab group, would there even be a master component then since it’s only made up of tabs? I think they just might pull out a single tab component and duplicate.
Would you happen to know why you are not able to add to a component instance? If you have a tab group component, you can delete layers but not duplicate into the instance.
Yeah, it’s honestly been the building method I reach for most often!
And yes, those steps you outlined are correct 
The only reason to have a tab group as a main component is if you want to save your designers a little bit of time of having to pull in a single instance of a tab component and duplicate it themselves. For example, if your design system might dictate that you need at least two tabs to necessitate the use of a tabs (a single tab may not make sense). You could have a tab set with two tabs in it, and that saves designers maybe a few seconds and a couple clicks and keystrokes. Perhaps that’s not worth it! 
I think the most important thing to keep in mind when you’re building a component that is meant to be detached is that the top-most layer shouldn’t have any visual design applied. No fills, strokes, padding, space-between, or effects… It must be a simple frame (auto-layout is okay though) because that’s the part that breaks away from the main component. If the parent frame has to have any of those things, then this method is probably not a good choice.
My understanding of why you can’t add or rearrange the layers of component instances is because that would defeat the purpose of having components in the first place. Components are what allow us to confidently create visually consistent mockups and prototypes, so if we had the ability to alter instances then we couldn’t rely on our main components to be “sources of truth.” Overrides exist help us work with realistic content and data in our designs, but I think what you and I (and many others!) are running into is that Figma hasn’t given us a good way to manage that content. Overrides fulfill our needs up to a certain point, but I think many of us are findings these “edges” of Figma where it’s still far away from what our engineering colleagues are able to do with the code expression of components.
All great points. I’m new to Figma from Axure so looking for insights. I can understand why Figma might limit the editability of components but I bet you could get away with it and still maintain the integrity of the component. I’m sure easier said than done but you could define a list/options and let the number of items in it be adjusted. It would be useful for things like dropdown options, rows in a table, tabs in a tab bar, accordion sets, ckbox/radio options. Wishful thinking but thanks for the feedback!
Ah gotcha! I’ve used Axure briefly in the past, I don’t remember much about how they handle component management, but I do remember it being very easy to import data from spreadsheets and populate components with that information. There’s a plugin for Figma that sort of works the same way: Google Sheets Sync. I haven’t used it in a while so I’m not up to speed on the latest improvements the publisher has made, but I don’t believe it neatly solves the problem we’re talking about. It can speed up the process I described above, about populating a main component with content—let’s say a list of country names for a droplist—using instances of other components (a droplist item), and inject data from the spreadsheet as text overrides as it does so, which saves time copy/pasting that information. Then, elsewhere, you could have a main component acting as a container to handle the padding, stroke, and shadow around an instance of that “country name droplist” component.
But it can’t (and again I want to double check the version history notes, maybe the publisher has found a way to do this!) get around the limitation of changing the layer structure of instances (adding, removing, or rearranging layers).
I’m with you though, I’d love to see some Axure capabilities in Figma! There might be other plugins out there that get us halfway there.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.