Modular Modal System That Achieved 100% Team Adoption
Turning inconsistent modal patterns into a scalable design system component.
All 5 designers adopted the system within the first 2 weeks. Zero custom modals built outside the system since launch.
Used in 5 active design files within the first month, supporting multiple product features across the platform.
Modal creation time dropped from 20-30 minutes to approximately 10 minutes per instance.
From problem identification to shared library publication in a 3-day sprint: build, document, launch.
Designers needed a way to build modals quickly and consistently without sacrificing flexibility. The challenge was creating a system that enforced structure while staying flexible about content.
Mediavine's design team had no standard approach for building modals, with 10+ different modal types already in production.
With 10+ different modal types already in production and new modals being created regularly, each designer was approaching modal design differently: rebuilding the container structure from scratch every time, breaking design system rules, and creating unpredictable handoff for engineering. This wasn't a skill issue. It was an infrastructure gap. Every new modal was custom work, and that meant wasted designer hours on structure instead of content strategy.
No Progress Visibility
Each designer spent 20-30 minutes just creating the container structure for every modal, making the same decisions about padding, button placement, and close icon positioning.
Visual Inconsistency
With no shared standard, modals looked different across the product. Users experienced unpredictable interaction patterns that signaled lack of polish and reduced trust in product quality.
Unpredictable Engineering Handoff
Engineering teams received varying modal structures requiring interpretation, inconsistent spacing and button placement, and multiple versions of similar patterns to maintain.
Compounding Technical Debt
10+ patterns in production meant future refactoring cost. At scale, multiple modals per sprint meant dozens of hours spent on repetitive work rather than strategic design.
The modal system.
A two-part modal system combining a rigid shell with a flexible content slot, using Figma's instance swapping for infinite flexibility without maintenance burden.
By making the shell rigid and the content flexible, I gave designers both consistency AND flexibility which solves the fundamental tension.
The approach centered on solving the root cause, not the symptoms. The problem wasn't that we had 10+ modal patterns; it was that we had no infrastructure to prevent that drift.
Consistency where it matters
The shell enforces the things users expect to be predictable: where the close button lives, how the overlay behaves, spacing and padding. This builds trust.
Flexibility where it counts
Content varies wildly. A simple alert needs different treatment than a complex form. The swappable content slot lets designers optimize for their specific use case.
Easy to use, hard to break
The system should be intuitive enough that one demo is sufficient, and architected so that designers can't accidentally break consistency even if they try.
What we built.
The solution is a two-part system: a rigid modal shell that enforces consistency, and a flexible content slot that adapts to any use case.
The Modal Shell (Rigid)
Consistent framework
Built using Figma's auto-layout for responsive behavior. Fixed outer container with consistent 32px padding, standardized 8px corner radius, overlay backdrop at 60% opacity. Close button always top-right, 16px from edge. Uses 8px grid with design tokens for all internal spacing. Button container bottom-aligned with 16px gap between buttons.
The Content Slot (Flexible)
Swappable interior
The modal shell contains a nested component instance named Modal/Content that designers can swap with any content they need. Designer duplicates the base modal, clicks the content instance, swaps it with their prepared content (alert, form, media, etc.), and content automatically inherits the shell's structure and spacing. 30 seconds to swap content vs. 20-30 minutes to rebuild.
Instance Swapping Over Variants
Architectural decision
I considered building a variant library (Alert Modal, Form Modal, Media Modal) but rejected it. Variants would be prescriptive and require predicting every use case. 20+ variants would create decision fatigue. Every new modal type would mean a new variant to build and maintain. Instance swapping solved all three problems: designers get infinite flexibility within a consistent structure, with zero maintenance burden.
20+ variants to maintain. Decision fatigue. Every new use case needs a new variant.
Infinite flexibility. Zero maintenance. Future-proof by default.
Auto-Layout Intelligence
Responsive by default
The shell uses auto-layout with proper constraints, so it expands and contracts based on content height, maintains consistent padding regardless of content, keeps buttons aligned at the bottom, and handles overflow gracefully. Width is adjustable via properties panel to accommodate different content needs.
Design Token Integration
System-wide consistency
Every spacing, color, and typography value uses design tokens from the existing design system. This means when tokens update, all modals update automatically with no manual rework needed. Nothing is custom; everything leverages the existing design system.
The receipts.
Impact was measured through team adoption tracking, before/after time comparisons, click tracking, direct observation of designers working, and qualitative feedback from both designers and engineers.
All 5 designers adopted the system within the first 2 weeks. Zero custom modals have been built outside the system since launch. This voluntary, immediate, and sustained adoption validates that the system solved a real pain point.
Modal creation time dropped from 20-30 minutes to approximately 10 minutes per instance. The time saved comes from eliminating structural decisions; designers now spend time on content, not containers.
Used in 5 active design files within the first month, supporting multiple product features across the platform. Every new modal designed since launch has used this system.
Months after launch, the system remains the only way designers build modals. No one has reverted to custom creation or requested changes to the architecture. Longevity proves this wasn't just a novelty.
Organic Content Library Emerged
Designers started creating reusable content components to swap in, and a mini-library of "modal contents" emerged organically. Designers began sharing content components with each other, and the system encouraged modularity beyond just modals.
Figma Validated the Architecture
After I built this system, Figma announced that "Slots" will roll out as a native component feature, using essentially the same pattern I designed with instance swapping. This validated that the architecture wasn't just clever for our team's needs, but aligned with where the industry and tooling were headed.
Engineering Loved It Too
Engineers reported that modal handoff was "so much cleaner" with predictable structure. The consistency made implementation faster and eliminated back-and-forth during implementation.
What they said.
This is a very clever solution, Karlyn
HOLY COW, I don't have to detach instances anymore!
OOOO YES
What I took away.
Solve the root cause, not the symptoms
The problem wasn't 10+ inconsistent modal patterns. The problem was no infrastructure to prevent drift. Building a foundation that makes consistency the default is more effective than enforcing rules designers have to actively maintain.
Ship fast, validate through adoption
A 3-day sprint and live demo was more effective than weeks of documentation and committee approvals. The best validation is voluntary adoption. If the team uses it without being required to, you've solved a real problem.
Separate what's rigid from what's flexible
The breakthrough was recognizing that designers need consistency AND flexibility. These aren't opposing forces. By making the shell rigid and the content flexible, both needs are served simultaneously.
Leverage existing infrastructure
The innovation was in the architecture, not in building new patterns. Design tokens, existing components, auto-layout, and instance swapping were all existing Figma capabilities. I just combined them in a new way.
One demo should be enough
If your system requires extensive training, it's too complex. The modal system was intuitive enough that a single walkthrough demo was sufficient for full team adoption. Simplicity drives adoption.
This project proved that the best design system components are invisible infrastructure. Designers shouldn't have to think about containers, spacing, or structure. They should think about content and user experience. When the system handles the boring stuff automatically, designers do better work.
Interested in working together?
Book a 15-minute chat and let's talk about your next project.