Myself and many other Figma users seem to be fond of the “Kitchen Sink” component approach for managing components that are highly variable in the content they can hold. Think of objects like tables, forms, cards, feeds and other lists... How do you build a component that handles every possible permutation? Should you build a component like that? My favorite answer "it depends" absolutely applies to these hairy questions. Let’s examine the tradeoffs and the scenarios where using Kitchen Sinks is ideal:
A Kitchen Sink is a component that contains many hidden layers that designers can show and hide as needed. My colleague Jay and I came up with the name "Kitchen Sink” for this method of component building when we once made a “card” component that was so chock-full of nested frames that we couldn’t even see the names of the lowest level layers anymore... as the idiom goes, we jammed “everything but the kitchen sink” inside this component.
Before Variants, folks sometimes used this method to handle interactive states (hover, active, pressed, disabled...etc.), or arrangements (the same component but with different layouts). The idea is to package up everything you need in a single component. This means you end up having to manage fewer components, but they tend to be very weighty in terms of the number of layers they contain, which often makes them complicated to work with. Having fewer components to manage frees designers up from spending time naming and organizing components, which is great! Less time managing means more time to design. But depending on how complex the object is, Kitchen Sinks can be intimidating to work with if you didn’t have a hand in building them. They require designers to go spelunking through the layers panel, hiding and showing things, until they get the right combination for what they need. Any time saved in not having to organize, sort, and name main components would be well spent making sure any Kitchen Sink’s layers are well named and as tidy as possible.
Variants largely make the Kitchen Sink building method obsolete, but in a way that cleverly recycles the same method and let’s designers preserve overrides (which was not possible before): designers build out all the needed variations of a single component, ideally using the same layer structure and preserving layer names (again, to take advantage of overrides), but instead of nesting these within a single object, you make them each a component and then combine them as variants.
Here are some examples of folks using Kitchen Sinks before the variants feature was released:
In step 6 of his medium article titled “10 tips on using components in Figma”, Jake Tsacudakis writes,
Since components act like frames for all intents and purposes, we can utilize the clip content feature to toggle whether or not elements that extend beyond the bounds of the component are cropped or hidden. While you won’t use clip content for every component, it’s very useful for components with repeated elements like data tables and lists.
In 2019, Jesse Showalter recorded a tour of his team’s design system. A couple minutes in he starts to show us how his team approaches building components,
We have an avatar [component], and you can see it has an outline that I can turn on and off, and it also has a huge selection of faces inside so I can hide and show the different avatars in there. These are all here so I don’t have to have multiple versions of avatars [...] It’s one component with lots of variables inside. We try to have as few components as possible with as much variation as we can give it, that’s our rule of thumb.
Those examples above were during a time before Figma released the variants feature. But Kitchen Sinks live on! Here we see Christian Baptiste using a Kitchen Sink after variants had launched:
The way that we currently deal with things like this is to place a bunch of hidden copies of the components and wrap them in an auto layout so that the container resizes to only the objects that are viewed. Then when we need more rows, tabs, cards, etc. we go to the layers panel and just unhide more. *Note this approach is still a little problematic because it doesn’t let you rearrange the order like you can do in a detached component.
Yes. As Carol Chan recommends in her Medium article on “Building Complex Figma Variants”, the Kitchen Sink (or as she calls them, Base Components) can help save designers tons of time managing their Variant components. She writes,
Before building out your variant, create a base component outside of your variant and put everything in there. Include all the layers you need to turn on or off, the number of buttons you want to make available, elements for different states etc.
Sounds just like a Kitchen Sink, no?? She continues,
A base component helps safeguard against spending lots of time applying changes that may come up after iteration, testing, or experimentation. For example, if my team decides we need have an additional button added as an option, I can just add 1 button to the base component and have it apply to my 288 variations — instead of going into each variation and adding a button (adding 1 button 288 times in my case).
I completely agree with Carol’s method and use case. I recently built a button component with 1620 variants. You better believe I used the Kitchen Sink method so my future self won’t need to spend hours adjusting things like padding or border radius a thousand times over.
So what are the tradeoffs? It may seem like you’ve got nothing to lose with a Kitchen Sink, but I advise you to proceed with caution when using them. Remember that card component I mentioned? How there are so many deeply nested layers inside it that Jay and I can no longer see the lowest level ones because the layers panel can’t expand enough to show them? I believe there is such thing as a too-big Kitchen Sink. At some point the gains you get in time-saved managing components are negated by the lag these gargantuan components create in your file. They’re hefty! All those hidden layers take up space in your file. In Figma’s documentation on reducing memory usage, their first recommendation is removing hidden layers. In other words, hidden layers make for laggy files. This means some of the time you saved yourself from having to make repetitive changes to variants in the future may get eaten up in the now during micro-seconds it takes to zoom in, out, and around your file. Lag adds up. And when you're crunching under a deadline, you need your tools and files to perform at their best.
The long and short of it is that Kitchen Sinks will save you time, but at the cost of file space.
For some, file space is a non-issue. The design systems and prototypes some folks build are always small enough that they never even come close to the "lag begins to happen" 1GB threshold. Pro tip: turn on the “Resource Use” panel in Figma to check in on your file size. This handy feature will show you the total number of layers in your file, the amount of memory this file requires, and a real-time gauge showing you how much information you're adding and taking away from the file as you create, move, or remove objects. Through some tests I've run, I have reason to believe these numbers are not 100% accurate, but they're better than nothing.
For others, file space is a real problem that’s easy to run into. Knowing that Kitchen Sinks still have great utility in a post-variant world, the question becomes: how do you build the most efficient Kitchen Sink possible? Asked another way, using Carol Chan's naming, how do you optimize your Base component for file performance? Is it even possible? Is the nature of a Kitchen Sink just to be... big?
No. And the explanation behind that “no” will require its own journal entry. But for now, consider using a Kitchen Sink to manage your variants! Especially in your files that are on the small side. Read Carol’s article for details on how to apply this method. She does a fantastic job of outlining the process.