A behind-the-scenes look at how I reduced Edifire UI's button component from 432 variants to just 32 using parametric logic, slot-based design, and Figma properties. This case study explores the thinking, tooling, and cleanup strategy behind a scalable, token-driven system built solo and made for open source.

When I started building Edifire, a personal design system built from the ground up with a vision to become open source, I thought I was being thorough. Thoughtful, even. After all, what’s a design system without a button component that can handle every edge case and visual preference imaginable?

I created states for hover, focus, disabled, and loading. I accounted for size variations, different icon placements, tones, hierarchies based on importance.

It seemed comprehensive at first, just a simple frame with a label. Maybe an icon. Maybe two. Then came sizes. Colors. States. Icon alignments. Theme modes. Before I knew it, my tidy component panel had morphed into a scrollable mess of 432 button variants.

It was chaos… but it was my chaos.

Edifire UI started as a personal project, to build a scalable, visually balanced design system I could reuse across side projects and eventually release for others to use. I wanted it to be minimal, flexible, and fully tokenized.

The button, being the most frequently used component in any UI kit, was naturally one of the first elements I tackled. I approached it with a mindset of “account for everything.” And that’s exactly what I did. I over-accounted.

This wasn’t a visual failure. Nothing was broken, misaligned, or technically wrong. But something felt heavy. My build-up felt bloated.

I wasn’t getting error messages. I wasn’t struggling to make the component work. What I was struggling with was the mental load of navigating it. I had unknowingly recreated one of the most common and least discussed problems in design systems: Variant Overload.

In Figma, the component panel had become a scroll-fest. Every time I needed a simple button, I found myself buried in nested menus and 5-syllable variant names. It was like trying to order a coffee and being handed a menu with 400+ combinations, each with a slightly different name.

Even though Figma handled it just fine, I wasn’t.

The bigger insight? Component overload is a quiet killer in many design systems.

I came across a talk by the Uber design systems team. They were walking through how they reduced their badge component from dozens of rigid variants to just a few highly dynamic configurations, by switching to a parametric design model.

Their badge could take on any shape, tone, or status, without bloating the variant list. It used just a handful of props like tone, size, icon, and message, powered by tokens and context-aware logic. It was simple, smart, and scalable. This stuck with me.

So when I looked back at my own button, I began to see it not as a static set of visual options, but as a parametric system waiting to be unlocked. That mindset that shift from how it looks to how it behaves, became the catalyst for rethinking everything.

I took a step back and mapped every possible combination I had created.

What i did was to map out the anatomy of the buttons including its different sizes, so i can identify what property to turn into a parametric variable.

I tracked the following elements:

• Button size

• Font size

• Font height

• Spacing between elements

• Vertical padding

• Horizontal padding

• Corner radius

This time i approached the button like a developer might approach a component API.

I then broke down the visual and functional aspects into properties that could be toggled and scaled. I created a collection of token variables for the identified properties and then assigned the variables to the button component while maintaining both light and dark mode.

Instead of hundreds of rigid variants, I created one core structure with 32 intelligent configurations. Each decision was driven by 2 questions:

"Will this scale without duplication?"

“Will this reduce mental load for anyone using it, including future me?”

Reducing 432 variants to 32 wasn’t just about decluttering. It created space—for speed, focus, and consistency.

• Faster performance in Figma

• Less chance to reduce or override

• Easy theming with token hooks

• Predictable behavior across breakpoints

Now when I need a button, I toggle a few properties.

That’s it. No overly long list of variants and properties, No visual/mental fatigue.

Working alone on Edifire gave me full control, but also full responsibility. I couldn’t rely on team reviews or shared standards. The system had to be resilient by design.

Here’s what this process taught me:

• A component should feel like a tool, not a trap.

• Flexibility comes from constraint, not chaos.

• Designing alone means future you becomes your toughest stakeholder.

• Component logic is more powerful than visual stacking.

• Design systems are about decision reduction, not just reusability.

• Tokens, slots, and props are your best friends.

• If something starts to look heavy, it's time to refactor.

The button refactor was just the first step in shaping Edifire into a system that’s thoughtful, scalable, and genuinely enjoyable to use.

Next, I’m applying the same approach to modals, dropdowns, tabs, and inputs, where logic not layering, leads the design.

Edifire is going open source soon. When it does, it won’t just be a collection of UI parts. Build small. Think in systems. Reduce friction. Leave room to grow.

I’m also focused on bridging the gap between design and development so others can use the system right out of the box. I plan to include the React code snippets of the components in Edifire UI directly on the file using Figma MCP and Cursor.