Slots and the control paradox: Why loosening your design system might save it
How Figma's newest feature exposes an uncomfortable truth about the way we've been building systems
Picture this: a designer stares at a component in frustration. The card is almost perfect. They need to add one more content block, swap in a different icon size, adjust the layout slightly. But the component doesn’t allow it. Every variant’s been pre-built. Every configuration anticipated. Except this one.
They have two choices: detach and lose future updates, or compromise their design to fit what the system allows. Neither is ideal – detaching creates maintenance headaches for both the team and the system, while, depending on the context, compromising may not solve the use-case. This moment – replicated across thousands of design teams daily – reveals something I’ve been arguing for years: we’ve been building design systems backwards.
At Schema 2025, Figma announced Slots: placeholder containers that let designers customise component instances without detaching. On the surface, it’s just another feature. But Slots represent something more significant. They expose an uncomfortable truth about control in design systems, and they’re forcing us to confront a paradox we’ve been avoiding for years.
The illusion of complete control
For the past decade, design systems have sold themselves on a promise: if we could just anticipate every use case, build enough variants, and cover every edge case, teams would never need to detach. Component libraries became insurance policies – the more coverage, the better protected you’d be.
So teams built. And built. And built some more.
Card components spawned 47 variants. Buttons multiplied into dozens of permutations. Elaborate property panels with nested configurations, all in service of comprehensiveness. Teams drowned in options, struggling to find the right component for their needs, yet somehow still couldn’t find exactly what they wanted.
I’ve watched this play out repeatedly. Design system teams build what they think are comprehensive components – anticipating layouts, configurations, content types. The components work well for what was planned. But then teams need to adapt them for their specific context in ways that weren’t pre-built.
The components were comprehensive, just not composable.
And building more variants only made it worse. More options meant more maintenance, slower iteration, and components that were somehow both overwhelming and limiting.
Teams stopped adopting them. The systems were solving the wrong problem – confusing completeness with usefulness, rigidity with consistency. Building cages when we should have been building playgrounds.
Elyse Holladay captured this perfectly in the latest minisode of On Theme, where she recapped Converge 2025: “We are overdoing, over-engineering, over-building so much, specifically on the design side, and doing it in a way that I am not actually convinced is solving a whole lot of problems for most teams, most of the time”.
That’s why Slots hit a nerve: they reveal how brittle that illusion of control has always been.
What Slots actually mean for design tools
Slots let you add layers, swap content, and compose freely within component instances – all without detaching. You can specify which instances a slot accepts, maintaining guardrails while enabling creativity.
The concept of slots isn’t new. If you come from a development background, you’ve likely been working with this pattern throughout your career. React’s children props, Vue’s slot system, Web Components’ slot elements – developers have been composing interfaces this way for years. The concept of a designated area where you can insert content is fundamental to how the web works.
This isn’t entirely new territory for experienced Figma users either. Teams have been hacking around this for years – creating slot components with instance swaps, building elaborate workarounds to achieve basic composability. But those solutions had limitations and took time for less experienced designers to learn. Slots make this pattern native, accessible, and far more powerful.
The implications run deeper, though, because Slots represent a fundamental philosophical shift in design tooling: from “prevent deviation at all costs” to “enable creativity within clear boundaries”. From rigid anticipation to structured flexibility.
I’ve always viewed components through this lens. When I see a card component, I naturally see a container with defined structure and flexible content areas. When I work in code, composition is the default assumption, not some advanced feature. A button wraps whatever you put inside it. A modal accepts any content you pass as children.
The revelation isn’t that slots exist – they’ve existed in code forever, and many of us have been using them all along. The revelation is that our design tools have finally caught up to this reality.
Nathan Curtis, who published an extensive piece on Slots, captures the broader principle perfectly: “No system solves every problem we’ll ever face. Nor should we want it to. Instead, a well-architected system balances what’s fixed and what’s open, where you are constrained by guardrails and where you can – and should – innovate”.
Design tools have been the bottleneck. Figma’s component model forced designers into rigid variant thinking because that’s all the tool could support. Those of us working across both design and code have felt this friction for years. We’d build composable components in React, then watch designers struggle to represent that same flexibility in Figma. The workarounds were painful: nested instances, complex boolean properties, hidden layers teams could unhide, elaborate instance swap setups. All attempting to recreate what code does naturally.
When your tool forces variant thinking, you build variant-heavy systems. When your tool enables composition, you build composable systems. And composable systems are more flexible, more maintainable, and far more aligned with how interfaces actually get built in production.
The control paradox
Here’s the paradox: giving up some control actually increases system health and adoption.
Tight control feels safe. If we pre-build every variant, we maintain consistency. If we lock down every parameter, nothing can go wrong. Design system teams become gatekeepers for what can and cannot live in the product. But that’s not our role – our role is to enable teams, not police them.
And in reality, tight control doesn’t prevent workarounds. Teams build parallel solutions, maintain forked versions, or yes – detach when they need to. Not because they’re being difficult, but because the system doesn’t serve their needs.
When components are too rigid, designers lose confidence. They can’t experiment. They can’t adapt solutions to specific needs. And when designers don’t feel empowered to adapt or contribute, they disengage. Confidence drives adoption – but it also drives contribution. I dug into this in my piece on the component adoption gap.
The pattern is clear: systems with too much control see low adoption, frequent workarounds, and parallel systems emerging in the shadows. Teams proud of the solutions they’ve built themselves resist adopting centrally-dictated alternatives. Worse, they stop sharing what they learn. The system loses the very insights that could make it better.
On the flip side, systems with too little control create different problems: chaos, inconsistency, no efficiency gains. Every team doing their own thing is no system at all.
Brad Frost identified this tension years ago in his article ‘Design System Frictions’: “It’s important to find the place on this spectrum that imposes enough constraints to avoid complete chaos, but also provides teams enough flexibility to be creative and effectively solve problems for users”.
Wart Burggraaf from govern.design puts it well in his article ‘How to govern a design system that is continuously evolving’: “There doesn’t have to be a tradeoff between consistency and creative freedom”.
The best APIs have always known this. They’re both constraining and composable. They define clear contracts – inputs, outputs, expected behaviours – but they don’t dictate implementation details. They establish boundaries that enable creativity rather than stifle it.
Slots bring this API thinking to design tools. They’re saying: here’s the structure, here’s what stays consistent, and here’s where you get to compose. The component maintains its identity, its accessibility, its core behaviour. But you control the content within those boundaries.
That’s not losing control – it’s getting better at where to apply it.
What needs to change
Slots don’t just add a feature to Figma. They require a mindset shift for design system teams.
Trust is the hard part. It means accepting that teams will use components in ways you didn’t anticipate. It means believing that clear boundaries are enough without pre-building every possibility.
I’ve seen teams achieve more by abandoning “proper” approaches than by following best practices religiously. Systems that work are rarely the ones that look pristine in documentation – they’re the ones that enable teams to move faster, make decisions confidently, and align around shared understanding, even if the underlying structure isn’t something you’d present at a conference.
The best system isn’t the one that looks perfect in your portfolio. It’s the one that solves your organisation’s real problems.
If you’re wondering where to begin, start by looking for the friction points – the places where your system is actively working against your teams.
Practical steps:
Audit your component library: Which components have the most variants? Which see the lowest adoption? Which have the biggest gap between your Figma and code versions? These are your prime candidates for Slots.
Identify your non-negotiables: What must stay consistent for brand identity, accessibility, or technical reasons? Everything else is a candidate for flexibility.
Document the boundaries: Slots work when teams understand the constraints. Make it clear what’s protected and what’s composable.
Provide examples: Show teams how to compose effectively. Good examples teach better than extensive documentation.
Build feedback loops: Watch how teams actually use the flexibility. Their creativity will inform better system patterns.
For teams that have been operating as gatekeepers – controlling what can and cannot exist in the product – this represents a significant shift. The role becomes more about defining clear boundaries and trusting teams to build within them. But not every team operates this way, and not every organisation needs that model.
Nathan Curtis frames the broader principle well in his article ‘Principles of Design Systems’: “Products own their destiny, systems equip them to realise that destiny. Systems should neither take over building things for products nor think they decide what and when the products do or don’t do anything”.
The specifics vary by organisation. Some teams move from policing implementation to maintaining boundaries. From approval gates to clear guidelines. From “no you can’t” to “here’s how you might”. Others have always operated with distributed trust and are simply gaining better tools to support it.
What’s consistent across successful systems is this: when you give teams more flexibility, they need more guidance about how to use it well. That’s the work that matters: helping teams build confidence in composing components correctly.
And for the first time, the tools are finally catching up to support this approach.
Why this matters now
Figma hasn’t added Slots on a whim. Several forces are converging that make composable systems essential:
AI agents are coming: As I explored in my previous article about design systems for AI, agents consuming design systems need structured, composable interfaces. Rigid variant systems don’t translate well. Clear boundaries with flexible composition do.
The code-to-design revolution: Tools like Dessn are enabling designers to work directly with rendered code components. This only works if those components are composable. The design-to-code workflow Figma has been pushing? It’s backwards. We already have the code. The future is designing with it.
Tool evolution: Slots, improved variables, Extended Collections – these aren’t random features; they’re design tools finally aligning with how the web works. Extended Collections are just variable overrides, the most basic function of a variable: inherit from a parent, override when needed. The fact this required a special announcement at Schema tells you everything about how constrained we’ve been. Teams that learn to use these tools well will have significant advantages.
Right now, we’re having a conversation about control in design systems. We get to decide how this plays out. We can cling to the illusion that comprehensive variant libraries equal control. Or we can embrace what good API designers have always known: the best systems balance constraints with flexibility, structure with freedom, governance with trust.
The control paradox isn’t really a paradox at all. It’s a lesson about designing systems that work with humans, not against them. The magic happens in between – and that’s exactly where Slots live.
Design systems are finally growing up. We’re learning that the goal isn’t perfection or completeness. It’s usefulness and trust. It’s enabling teams to do their best work within clear, well-considered boundaries.
Slots don’t just let designers add content without detaching. They let systems stop trying to control everything and focus on enabling what matters.
Thanks for reading! Subscribe for free to receive new posts directly in your inbox.
This article is also available on Medium, where I share more posts like this. If you’re active there, feel free to follow me for updates.
I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.
Further reading
I recently wrote a piece for the wonderful team at zeroheight, exploring when design tokens become technical debt. Feel free to give it a read.
Love this perspective! "Building systems backwards" truely makes sense.