While building my own design system, I initially tried to make the button component cover every possible use case. I added multiple sizes, visual styles, interaction states, icon placements, tones, themes, and hierarchy levels.

At first, the system felt complete. But as more combinations were added, the component quickly became difficult to manage. What started as a simple button eventually turned into a large collection of variants that made the system feel heavier than it needed to be.

The goal of this refactor was to reduce unnecessary complexity and rebuild the button as a more flexible, scalable component powered by properties and design tokens. 

The design system began as a personal project designed to support different digital products while staying visually consistent and easy to maintain.

From the beginning, I wanted the system to be:

Because buttons appear across almost every interface, they were one of the first components I built.

My first instinct was to prepare for every scenario upfront. I created different variants for sizes, states, themes, icon positions, hierarchy levels, and visual tones.

The system technically worked, but the architecture became much more complicated than necessary. 

The problem was not visual quality.

The buttons still looked correct, spacing was consistent, and the component functioned properly in Figma.

The real issue was usability.

As the variant count continued to grow, using the component became increasingly tiring. Finding a simple button required navigating through too many combinations and properties.

The component had become flexible in theory, but inefficient in practice.

This revealed a larger design-system problem:

A design system should reduce decisions, not introduce more of them. 

Instead of treating every visual combination as a separate variant, I started thinking about the button more like a configurable component API.

The question changed from:

to:

That shift made it possible to separate the component into a smaller number of reusable controls rather than maintaining hundreds of fixed combinations. 

A major reference for this refactor came from seeing how mature design systems approach component architecture.

Rather than creating a new variant for every possible appearance, they rely on a smaller set of configurable properties such as:

These properties can then work together with design tokens to produce many outcomes without multiplying the number of components.

That approach made me reconsider the structure of my own button system.

Instead of designing a collection of static buttons, I began designing a system of rules. 

Before rebuilding anything, I mapped the current button anatomy and identified which values changed between sizes and states.

The audit focused on:

Button size

Label size

Line height

Item spacing

Vertical padding

Horizontal padding

Corner radius

This project changed how I think about component architecture.

A scalable design system is not about creating a component for every possible scenario.

It is about identifying the smallest set of rules that can support many scenarios.

The key lessons were:

More variants do not automatically create more flexibility.

Constraints can make components easier to use.

Properties are often more scalable than duplicated variants.

Tokens make visual decisions reusable.

Component architecture should reduce cognitive effort.

A design system should behave like a system, not a library of screenshots.

If a component becomes difficult to navigate, the architecture probably needs to be reconsidered.