Most design systems were built for designers and developers. A third user just arrived, and it reads very differently.

Read more

I’ve learned that the difference between a system that thrives and one that quietly fails often comes down to judgment over novelty.

Recently, I read an excellent article about building scalable design systems. Many of the tips were valuable, but some relied on features that aren’t fully stable yet. Here’s what I’ve learned about when to adopt new approaches and when to stick with what works.

Figma Slots: The Feature That Isn’t Ready

Figma announced Slots in 2025 as a way to improve component flexibility. Everyone was so excited about it, and the concept is promising, and I’ve been using slot-based patterns for years. On paper, they sounded great. But in practice, this feature isn’t fully stable yet:

• Adoption is limited, and documentation is sparse
• Workflows may change significantly as the feature matures
• Teams risk investing time in patterns that could shift

In the meantime, the “classic” approach, slots components, or Instance Swap patterns, remains reliable and well-documented and widely adopted by designers.

Lesson: Stick with a workflow that works today, not one that promises a better future but isn’t battle-tested. Stability beats novelty when you’re building systems meant to scale.

Variables: Handle With Caution

Variables are often presented as the ultimate solution for design tokens and cross-file consistency. In reality, they introduce challenges:

• Zombie or ghost variables appear unpredictably in libraries.
• Team adoption requires significant governance.
• Maintenance overhead is higher than expected.

In my experience, Token Studio is a more stable long-term solution, at least for now. This approach may feel “less modern,” but it supports predictable collaboration and scale without breaking libraries.

Lesson: Tools are only as useful as their reliability. Prioritize predictability over hype when building infrastructure that teams depend on daily. Variables aren’t inherently bad. They’re powerful when implemented carefully, but the migration effort is often undersold.

Hidden Layers: Performance Matters

Some “best practice” guides recommend showing and hiding layers to manage complexity. For small files, this works. For large-scale systems, it introduces problems:

• Every hidden layer in each variant is still rendered in Figma.
• Large files with many hidden elements slow down the workspace.
• Designers avoid components that feel sluggish.

In my work, I balance component flexibility with performance. Rather than creating components with dozens of hidden layers, I keep components focused and create separate variants only when they serve distinct use cases. Hidden layers should serve a real purpose, not clutter the system.

Lesson: Performance is part of system design. Invisible complexity can erode adoption faster than visible mistakes.

Measuring Adoption: Detachment Rate

Detachment rates are the best signal we have of adoption. They reveal:

• When designers bypass components
• Why workarounds happen
• Where the system fails real users

Tracking these metrics isn’t just “nice to have”, it’s essential to understanding system health. Adoption is more than a checklist; it’s an ongoing dialogue with your team. When a component’s detachment rate spikes, I investigate why the system failed designers. Often, the component is solving the wrong problem or missing a critical use case.

Lesson: Observe real use, not just intentions. Metrics like detachment rate tell the story that usage patterns reveal, not assumptions.

Putting It All Together

Best practices are starting points, not guarantees. The systems that survive are built by designers who:

• Choose stability over novelty when the stakes are high
• Design for performance and adoption, not just functionality
• Observe real usage patterns and iterate based on evidence
• Make trade-offs consciously rather than following trends blindly

The hype cycle will always push new features and updated best practices. But your job isn’t to adopt everything, it’s to build systems that actually work for your teams.

What “best practices” have you had to adapt or rethink for your context?