Implementing Slots in a Figma Library

Go beyond "Swap swaps" to explore, decide on and implement slot patterns

Figma’s native slots promise a more flexible and easily composable future for design libraries. System owners are eager to transform their components, often with the expectation of a simple, one-to-one swap of existing slot utility instances for the new slot layers.

“I can’t wait. Our components will be delightfully easier to use.” True

“Figma’s native slot layers are simple to set up.” Also true.

“Just swap slot utilities for slot layers!” Hold up a minute. That’s not quite right.

A transition to native slots should reach further than replacing your slot utility asset. Migrating to Figma’s slots should force system architects to critically look at how components are composed and customized.

This post describes the journey of implementing native slots in a Figma library, from discovery with exploration through deciding your patterns and implementing them across the catalog.

---

Discovery

Don’t expect to just open a Figma library branch, rapidly change a bunch of components and hit publish. Migrating a library to slots with deliberate care can be informed by discovery activities like a library audit, research, and synthesis to identify patterns.

Audit

Start by auditing your existing Figma assets. Begin with already-composable components that may include slot utility instances, but don’t stop there. My audit included any component or subcomponent asset, and I catalogued each component with:

• Name, like Button or Pill / Start Visual.

• Role in the composition, such as Root / the “Main Component” versus its Header, Body, Footer, Actions, Start Element, End Element, or Other purpose

• Slot utility?, indicating if it has a slot utility bound to an instance swap prop.

• Slot utility as variant option?, if the slot utility is available in some variants but not others. For example, a Content prop with options for Icon, Mark, Avatar, and Slot option (that shows a slot utility).

• Composable nested instances?, if any nested instance had a slot utility in it. For example, a Button that has an End Visual with a slot utility option.

• Props (all types) to determine which variant, text, and boolean configurations will be kept, changed or removed.

I found myself sorting component props that I expected to keep versus those to consider more deeply or expect to remove (at least some instance swap props, obviously!).

Component slot audit, including component props

In hindsight, I would structure the data I collected (and the decisions to come) in the format of this Slots Audit Google Sheet. It boils down what can feel like myriad different cases and examples into the kinds of patterns and decisions to plan around.

---

Comparative research

The migration’s intended to balance incorporating legacy code patterns with adopting a modern, composable shape. While working through Figma assets, I also researched both:

• Compare against and align with existing code implementations, across platforms as needed and ideally via LLM prompts and agents

• Gain inspiration from public libraries with strong compositional qualities, like Github Primer and MUI React.

---

Exploration

Before making decisions, I dug in and experimented with many approaches within and across components. I varied many aspected of the architecture like where props were exposed, where elements were included, how content was available by default, and how to name each slot. This led to an array of working examples to workshop with the team.

Explorations file format for slot patterns with examples and alternative approaches

I prepared a Figma file with sections per pattern, establishing dedicated zones for:

• Examples established the pattern’s relevance. For example, the Group and repeating items pattern included Checkbox Group, Tabs, Radio Buttons, Breadcrumbs, Action List and Avatar Group. I annotated each likely slot area in magenta.

• Alternatives distinguished choices around component hierarchy, layer structure, props, slot layer depth, and slot default content.

In the periphery, I tracked:

• Open questions in the form of voting dots and rationale.

• Architecture decisions addressing conventions of slots, props and layout. If I felt strongly, I recommended a decision as a starting point.

This enabled me to learn by building and thinking through how to communicate distinctions per slot model. As we worked through options and examples, we riffed and made decisions.

---

Decisions

It may feel like you are just working through components (Checkbox Group, Card, Button), but the reality is that you are defining rules and standards to apply across your entire catalog as core patterns.

Sheet, shifted from audit to decisions focus

The spreadsheet started with the audit serves as a structured way to record and plan implementation of your slot approach, props, and layout as you refactor each and align them with code.

---

Slot approach

As decisions gave way to patterns, we ultimately decided on an approach. Each component or subcomponent was either EOL’ed (deleted) or kept with a slot architecture of:

• Slot, empty default

• Slot, with default content

• Configuration-first (props bound to layers, but no slot), “Custom” escape hatch (a slot with layers not bound to props)

• Named slot, always visible

• Named slot with visibility prop

• Items slot

• Subcomponent, no slot

• Subcomponent with slot

• No slot

---

Slot properties

Slot property conventions are straightforward yet require agreement:

• Name of both “default” slots (like children or items) and other named slots if needed

• Default content, whether none, uniform, or varying across variants

• Permissiveness, whether closed (to a strict set of anyOf children) or open (to set preferred values) as well as minItems and maxItems as relevant.

Slot props per component, such as name and default content

---

Slot layout

I recommend avoiding setting visual styles of slots like color, corners, and strokes. However, it’s practical to set layout properties like direction, resizing and item spacing and work out with development how those do or don’t impact code implementation.

Slot layout per component, such as item spacing and resizing

Prohibit padding on the slot layer. A component should not control the inset of its slot. If internal padding is required, nest the slot within a containing frame and apply padding there.

Empty slot sizing. In cases like Card and Modal, slots could be empty by default. Empty slots will retain a customized fixed height and width if needed. Discuss if and how to set the slot’s default height or width, likely to a typical expected size.

---

Refactored props and subcomponents

The transition to composable native slots forces a look at every component, both for its own internals as well as its relationships with other components. This leads to refactoring, and I expect slots to result in a configuration collapse described in a recent, separate post. Composition, not configuration, becomes the preferred approach to solve many problems.

Decisions to keep or remove existing Figma component props

---

Relating design assets and code architecture

In addition, consider a method to distinguish props that are “Figma helpers” that may not belong on a composable component’s code API.

For example, a Custom (false|true) prop that activates the slot for composability, and the bound label, description and visibility props presented to designers by default as the more common configurable case. This separates the bound label, description, and visibility props—presented for the common configurable case—from the asset’s Custom appearances, which define its true, composable API.

In the spreadsheet, I distinguish these using the *. In our tooling, that’s transformed when converting Figma assets to specification data.

---

Implementation

Equipped with implementation patterns and confident decisions, it’s time to plan and convert a library, from low- to high-order components, one at a time.

Notable characteristics of my implementation plan included:

• One branch per component.

• Convert components of the same pattern (such as groups with repeating items) simultaneously as a batch. That way, you can implement, review, and adjust across branches as decisions evolve.

• Leave more deeply nested component structures for later, like Alert (with its e, Text and Actions) and Action List (with its Item, Start Visual, Text, and End Visual). This offers space to sit with the more complicated architecture for a bit as people adapt to the easier stuff.

• Test slots using ready-made examples built beside the component assets. Early on, they are more test cases than published examples, even if they should represent acceptable cases by the time you publish.

• Pilot and get feedback on many things before publishing all the things.

Equipped with a plan, the conversion is a structured, component-by-component process of applying new conventions to a library that’s robust, tested, and ready for adoption.