Recently this question came up for how to handle a tab set component: do you set it up with an arbitrary number of tabs inside, and if designers need more then they're expected to detach so they can add extra tabs? Or do you load it up with a massive number of tabs so there's always more than enough, and instead of detaching designers can simply hide the tabs they don't need? Is there an alternative option that somehow gets around the negative tradeoffs that come with the first two options? Actually, yes.
Often people think only of those first two options: building components that are to be intentionally detached, or weighing down components with hidden layers to give designers flexibility. But with some creative thinking, a third, strong, stable option presents itself. These are the only three kinds of components that exist in Figma, each with unique strengths and weaknesses. I'll cover each of these in more detail below to help you confidently reach for the one that best suits your needs.
Real quick—some important caveats:
You've already built dozens, probably hundreds of components using this technique. It's what every "how to make components in Figma" tutorial teaches. It's what Figma itself teaches! The idea of a "basic" component is that it contains all the nested layers it needs. It has everything it needs, and nothing it doesn't (the sink).
When used properly, the basic method provides designers with components that are highly efficient in their layer usage. Ideally they have zero hidden layers and also make it easy to understand where overrides are expected to be made.
A button component is a good example of where the basic technique works well: buttons are made up of a label and sometimes have icons on either side of that label. If you include all the variants for interactive states, visual hierarchy, and so on, your designers are going to be happily inserting thousands of instances of it without any thoughts of detaching. Why would they? They've got their label, their icons, their states... now, if they're doing experimental work then they'll detach it (totally appropriate), but otherwise they've got everything they need! That's because basic components have clear limits to the amount of content they can acceptably hold, and that makes them more predictable pieces of interface to build. Even in an extreme case where a designer is trying to fit 50+ characters into the button's label, they've still got what they need: a label whose text they can easily override. This is not true of all components, which is why this method doesn't work across the board.
⭐️ There is no need for designers to detach these components, the component has everything they need. These components are the backbone of a strong component library.
⭐️ Basic components are not totally rigid, they can make use of variants to offer designers flexibility in the component's appearance. E.g. turning an icon on and off using variants on a button component.
❌ Before Figma released their variants feature, component architects had to use hidden layers or slash naming to offer designers alternate compositions of similar components. Figma warns us that too many hidden layers will bloat your file. Component architects who find themselves adding hidden layers to a basic component are often doing so because they're trying to account for unpredictable amounts of content, like checkbox responses in a form field. To avoid this, it is vital that component architects consider what kind of content the component will house. If that content can be inserted with overrides made only to the visible layers in the component, then you're in good shape. But as soon as you find yourself adding layers that might get hidden in certain contexts, you've gone a step too far.
The defining characteristic of a starter kit component is that it's meant to be detached. They are simply a collection of other component instances that designers can then duplicate, remove, and rearrange after detaching.
You can think of starter-kits like a meal-kit services (e.g. Blue Apron, Hello Fresh): all the ingredients (components) have been sourced and portioned out for a specific recipe and put into a box (frame). Consumers (designers) open and get rid of that box (detach the instance) so they can start using the ingredients (components) in the recipe (a mockup or prototype). If they need to add a little extra of something, like more hot sauce (component instances) than what was provided, they can (by duplicating them)! On the flip side if they don't like hot sauce, they leave it out (delete the instances)!
⭐️ Starter-kits save designers time. Instead of manually inserting different components one by one from the asset panel, starter-kits offer designers pre-assembled packages of commonly associated components. The bigger the starter kit, the more time saved: e.g. a component representing a website's homepage comprised of dozens of nested instances will save a designer more time than a starter kit for a tab set only 3 tabs in it (it takes very little time to insert a single tab instance and duplicate it twice).
❌ If the top-most level of the component has a fill, a stroke, an effect (like a shadow), padding, space-between, or resizing rules applied—basically anything you're able to do to "style" a frame via the design panel—then designers will lose out on any updates to those characteristics of the main component, because the nature of starter-kits is to detach. This means it is essential for the top-most layer of a starter kit to act only as a vessel for its contents. It must not be part of the design. Remember the meal kit example? The cardboard box gets thrown out. It's not an ingredient, it's disposable packaging.
❌ Do not include any layers that are not components. Even if you've avoided the first pitfall by making sure the top-most layer is as disposable as a cardboard box a meal-kit arrives in, starter-kits only work when you follow atomic design principles. When you lift up the hood of a stater-kit by unfurling that first layer in the layers panel, all you should see are these guys: ◇◇◇◇
The placeholder method exploits Figma's component swapping feature, which lets designers swap any component with any other component, regardless of name, shape, or size. This method should be used when content of a component is highly unpredictable. Modals are a great example. There can be thousands of different arrangements of content that might occupy a modal, and it would be a waste of component architects' time to try and build each of them out. Instead, they can use a placeholder component. These components often look like a visual version of "lorem ipsum." Sometimes they're just a single frame with a bright neon-color fill that purposefully stands out from all the other colors so designers know it's not part of the UI. Other times folks will use Figma's purple hue featured in their UI to signal that something is a placeholder.
When designers encounter a placeholder, they know it's just holding space for content. Designers must assemble that content be it a paragraph of text, a form made up of various input fields, or a carousel of images, put it in a frame, and make that frame a main component. Now they can swap the placeholder with their content. Adam Przewoski has made one of the best video tutorials I've seen demo-ing how to use the placeholder method.
⭐️ For allllll you people who have been asking for the ability to alter the structure of component instances, this is it. The slot technique is a natively supported workflow for adding layers to component instances in Figma, and it's been around for years.
⭐️ If you fall victim to the pitfalls of the other two methods like stuffing a basic component with hidden layers, or needing to style the top-most layer of a starter-kit, then this method has your back. It combines the benefit that basic components give of not having to detach, and the benefit starter-kits offer of having highly customizeable contents.
⭐️ Placeholder components unlock the ability to create spacing tokens in Figma (future journal entry)
❌ Component architects who get the hang of this technique may be tempted to turn the dial on this technique up to 11 by building a series of nested components that use the slot technique (kind of like the Inception movie, but slots. Slot-ception). They stand to win back a lot of time and effort that comes with updating components, but at the cost of a bloated layer-count, much like poorly implemented basic components. Component architects should be judicious with how they choose to nest components that use the slot technique, and remember to appropriately balance performance with maintenance.
There you have it. The only three techniques you need to know to build a strong component library. And remember, while they're all distinct from each other because of their unique strengths and weaknesses, they also rely on each other:
The placeholder and stater-kit techniques don't work without kitchen sinks to populate them with. Mastering the kitchen sink first is essential.
The kitchen sink technique has it's limits, and when you hit them it's a good sign you need to reach for the slot technique instead.
Starter-kits can include components using the placeholder technique inside of them.
Now that you know there's only three ways to put together components in Figma, doesn't the job of component architect seem a bit less daunting? With just three methods you can reach for, you can build endless components to support your designers' mocks and prototypes
If you'd like to be notified of when I publish a new blog post, joining my newsletter is a great way to keep up. Readers get extra insight behind every post.
