Building an Efficient Design System at Supertone
From Early Struggles to Sustainable Processes

Introduction
A design system promises efficiency. It should save time, reduce inconsistency, and empower teams to move faster. Yet when I first started managing the Supertone Design System (SDS) in 2023, I quickly realized a paradox: instead of solving inefficiencies, our system was unintentionally creating them.
This post is a reflection on that journey — the struggles we faced, the process improvements we introduced, and the lessons we learned about treating a design system as a living product.

The Challenges We Faced

1. Version Tracking Chaos
When multiple product teams were updating components independently, it became nearly impossible to track what was actually “current.” Designers worked from one version of Figma, while developers referenced another, and QA found inconsistencies in production.
Changelogs existed, but they were inconsistent and often incomplete. Without a clear source of truth, trust in the system began to erode.

2. Experiments and A/B Tests Out of Control
Supertone frequently runs experiments to optimize user experience. This culture of testing is healthy for product development — but destructive for a design system if unmanaged.
Temporary components and experimental UI variants flooded the library. Many were abandoned after experiments ended, but they lingered in the system, creating confusion about what was official and what was not.

3. Limited Resources and No Issue Process
At the time, our design system team consisted of just one full-time designer and one part-time contributor. With no dedicated developers, every issue competed for attention against ongoing product work.
Requests piled up in Slack threads. Some were urgent bugs, others were long-term structural questions, but without formal triage, everything blurred together. We often spent more time debating than fixing.

4. Weak Usage and Content Guidelines
Specs were documented, but usage guidelines were scattered across Confluence pages. Designers struggled with questions like:

• When should I use this button vs. that one?

• How should copy be styled in error states?

• Is this variant still valid, or deprecated?

Without clear guidance, people defaulted to guesswork. This hurt consistency and forced the system team to answer repetitive questions instead of advancing the library.

Redefining SDS as a Product
The turning point came when we stopped thinking of SDS as a static library and started treating it like any other product. A design system needs its own roadmap, release cycle, and user community. Once we adopted that mindset, improvements followed.

Process Improvements

1. Transparent Versioning & Verification
We introduced explicit update rules:

• Every update required a changelog tied to a code-level change.

• Each changelog included a Figma branch link for designers and a Jira ticket for developers.

• Versions were released as packages, not piecemeal updates.
   

To reinforce trust, we built a sample app called SDS Stage. Every component update was tested there first, covering all states and variants. Designers could validate changes visually, while developers could confirm behavior before release.
This workflow gave everyone confidence that a component was truly stable before entering production.

2. Smarter Experiment Handling
Instead of forcing experiments into the system, we flipped our approach:

• During projects, experiments stayed local.

• Once results were in, winning patterns were refined, validated, and then added to SDS.

This post-experiment adoption prevented the library from bloating with failed ideas. It also encouraged system-level thinking: before adding a new winner, we re-examined it holistically, refining details so it scaled beyond its original use case.

3. Formal Issue Triage
We introduced a weekly SDS Triage meeting with designers and product leadership. Every issue went into Jira, tagged as:

• Bug → urgent fixes, delivered in minor updates.

• Structural change or new component → scheduled for quarterly major updates.

This structure stopped ad hoc decision-making. It ensured that no single designer unilaterally decided what was “in” or “out.” Instead, prioritization became a collaborative, transparent process.
Just as importantly, documenting discussions created a history. When a similar issue arose months later, we could reference past decisions instead of starting from scratch.

4. Strengthening Guidelines & Communication
We consolidated usage and content guidance directly inside Figma, the tool designers were already using. Guidance was divided into three layers:
 

1. Spec — technical details.

2. Usage — examples of when and how to apply components.

3. Content — copywriting and tone guidelines.
    

Figma’s limitations made publishing long-form guidance difficult, but we used prototyping features to enable navigation, turning guidelines into a lightweight reference site.

Additionally, we held pre-release briefings with design and development teams. Instead of quietly updating the library, we shared what changed, why it mattered, and how to adopt it. This small investment paid off by reducing friction and increasing adoption.

Key Insights

Through these changes, several insights became clear:

• Trust is foundational. Without reliable versioning and validation, no one will confidently use the system.

• Less is more. Adding every idea to the system dilutes its value. Post-experiment adoption kept our library clean and high-quality.

• Process beats heroics. One designer working overtime cannot replace structured triage and prioritization.

• Guidelines must live where the work happens. Designers won’t dig through wikis; guidance has to be accessible in the tools they use daily.

• Communication matters as much as components. A design system is successful only when teams understand and trust how it evolves.
   

Conclusion
Managing the Supertone Design System taught us that efficiency does not come automatically with a design system. It requires careful operations, clear processes, and cultural adoption.

Today, we continue to survey SDS users — designers and developers alike — and feed insights back into the roadmap. Each improvement, however small, compounds into greater efficiency and trust.
A design system is not just a set of components. It is a living product. And like any product, its success depends on how thoughtfully it is maintained and evolved.