Luxury Presence

Figma Slots Migration

Role

Senior Product Designer

Skills

Design Systems

AI-Augmented Workflows

Figma

Duration

~2 weeks

Tools

Figma

Claude

Figma MCP

Figma Desktop Bridge

Before

10 booleans

Show List 1
Show List 2
Show List 3
Show List 4
Show List 5
Show List 6

After

1 slot

Menu Items
.ContextMenu Item.ContextMenu Item.ContextMenu Item+ add more…

Context

The LUX Design System serves all internal products at Luxury Presence — a CRM, marketing websites, and advertising tools. Several components in the Figma library relied on boolean properties to simulate variable-length content, creating friction for designers working with the system daily.

Problem statement

"Components use rigid boolean toggles to manage repeating content, forcing designers to show/hide fixed slots instead of composing freely. This leads to property bloat, rigid item counts, and unnecessary variant explosion."

The pain points

Property bloat: Secondary Navigation alone had 10 booleans just to toggle nav items on and off

Rigid item counts: Components had fixed maximums (6 menu items, 8 pills). Need more? Detach the instance.

Variant explosion: Avatar Group had 18 variants for combinations of count, size, and type

Approach

Figma Slots — a then-new feature in open beta, announced at Schema 2025 — offered a way to replace boolean toggles with composable child slots. Instead of toggling Show List 1 through Show List 10, designers could simply add or remove items inside a slot.

I used Claude with the Figma MCP to systematically audit and convert components. The AI handled the mechanical execution — reading component structures, creating slots, configuring preferred instances — while I directed every design decision about what should and shouldn't become a slot.

AI-powered execution: Claude + Figma MCP read component trees, created slots, and set preferred instances programmatically

Human-directed decisions: Every conversion choice — what becomes a slot, what stays a boolean, what gets excluded — was a design judgment call

Scope

21 components were converted across four tiers, organized by complexity and dependency:

1

Tier 1Container components

Context Menu, Alert, Confirmation Modal, Banner, Empty State, Onboarding Popover

2

Tier 2Repeating-element lists

Tabs Group, Secondary Navigation, Select Menus, Avatar Group, Pill Button Group, Graph Popover

3

Tier 3Cards and events

Event/Activity, Event/Collaborations

4

Tier 4Page-level layouts

Header, Tertiary Navigation, Footer, Action Bar, Standard List

Key decisions

Knowing what not to convert was as important as the conversions themselves. Several components were intentionally excluded:

Input components: Booleans are the correct pattern for field configuration (show/hide label, helper text)

Button icon swaps: Instance swap properties are the right abstraction here, not slots

Table Cell: 84 variants made this too complex for Phase 1 — needs a dedicated refactor

Property Card: Requires a structural refactor before slots can be applied meaningfully

Every slot was configured with preferred instances so designers see the right child components when inserting content (e.g., Context Menu's Menu Items slot suggests .ContextMenu Item). Slots also ship pre-filled with default content so components look correct out of the box.

Suggested for Menu Items
.ContextMenu Item
.ContextMenu Divider
.ContextMenu Heading

QA

A full QA checklist was created and executed across high, medium, and lower priority tiers. Two components — Avatar Group and Event/Activity — were canceled during QA when the slot pattern didn't improve the designer experience enough to justify the change.

Results

21

Components converted

~45

Booleans eliminated

120+

Variants simplified

21

New slots created

Reflection

Doing this manually would have taken weeks of repetitive Figma property editing. Claude + MCP tooling made it systematic — but the AI didn't make the design decisions. Every call about what should become a slot, what should stay a boolean, and what should be excluded entirely was a judgment call grounded in how designers actually use these components.

The two canceled components are part of the story, not a failure. Being willing to revert work that doesn't improve the experience is exactly the kind of quality gate that matters in design system work.

Let's get in touch!

Feel free to reach out, I'm always up for a good chat :)

© Victor Zanivan 2026