From Chaos to Clarity: How We Realized We Needed a Design System

#designsystem #frontend #architecture #webdev

Some initiatives are easy to pitch.
Some take a few meetings and diagrams.
And some - even if they're clearly beneficial - feel like dragging a boulder uphill for months.

For me, that boulder was our design system.
It took almost a year to convince the company that we needed it.

What Was Wrong

Before we started the initiative, our frontend lived in a kind of organized chaos.
Here's what it looked like:

Design inconsistency - Designers re-created components for (almost) every new feature, using loosely defined color tokens. Developers were reusing almighty components - not as bad as react-select, but close enough.
Lack of reliability - Nobody wanted to touch core components. Every small fix risked breaking something elsewhere, and there were barely any tests to catch regressions.
No documentation - You had to know what components existed or spend time reverse-engineering them from the code.
No accessibility - Almost no keyboard support, no focus management, no a11y structure at all.

For a small company focused on delivering features as fast as possible, this was "fine".
Shipping speed mattered more than consistency or maintainability.
Until it didn't.

When Grows Hit

In 2024, our engineering team tripled - from roughly 15 to 45 people.
New developers joined critical projects with tight deadlines, and naturally, they had no time to explore the existing UI foundation.

So they did what anyone under pressure would do - they just built things from scratch to match the designs.
Within a few months, we ended up with dozens of inconsistencies, duplicated code, and bugs that nobody wanted to own.

The lack of ownership became a real cost - every small feature was getting slower and riskier to release.

The Breaking Point: Rebranding

Then came the rebranding project - our "bingo moment".
We had to update almost all colors and fonts in the product… in two weeks.

On paper, that sounded simple. In reality, it was a nightmare.

We did have CSS tokens, but they were too abstract (inkMain, inkMedium, etc.). During rebrand, it turned out that the new inkMain could mean several different things depending on where it was used - background, text, or hover state, etc.

This rebrand became a stress test.
We patched components with feature-specific if statements, applied conditional CSS, and created more exceptions than rules.
CI started producing weird, unpredictable failures that haunted us for months.

What looked like a "simple UI refresh" turned into 100+ engineering tickets, exposing every bit of technical debt we had accumulated.

We had finally hit the ceiling of our "move fast and patch things" philosophy.
A design system was no longer a nice-to-have; it was the only way to bring order back to the product.

It was clear that without a unified design language and shared ownership, every future change - even a small one - would cost us exponentially more time and nerves.

And at that moment, something finally clicked.
One of our senior designers stepped up to become the design system ambassador - someone willing to take responsibility for the design side, ensure that the design team followed consistent Figma components, and work closely with engineering to build the bridge we'd been missing.

That was the moment when the idea stopped being "my thing" and became our initiative.

Finding the Right Starting Point

Once we finally got the green light, we needed a plan - roadmap, resources, milestones.

Right after the rebranding, we were scheduled to rebuild two major user experiences:

The logged-in dashboard and its related pages - kittl.com
The core editor UI - app.kittl.com

That was the perfect timing: if we were already rebuilding large parts of the product, we might as well build them properly this time.

Defining The "Foundation"

We started with an architecture planning session to define what "foundation" actually meant for us.
Building a design system isn't a one-week task - so we had to define a minimal, realistic first iteration.

We used an impact–effort matrix to prioritize components:

most-used and visible components first,
those blocking new features next,
and finally, replacements for bug-prone legacy ones (if still have some time).

Every new UI task in ClickUp was linked to a component ticket in the new design-system project. That helped us track dependencies and ensure that the base components were built before any new feature ticket was started.

Some components were intentionally postponed for the post-release phase, and a few legacy ones we decided not to touch at all until there was a real need to update them.

Lessons Learned (So Far)

Looking back, the hardest part wasn’t the tech.
It was the waiting - nearly nine months before we could even start.

And while we finally made it happen, I still believe we could have saved enormous effort by starting earlier, before the aggressive hiring phase and the architectural sprawl that followed.

But that's a topic for the final part - where I'll look back at what worked, what didn't, and what I'd absolutely do differently if I were starting again.

Next: In Part 2, I'll share how we built the actual system - architecture, tooling, CI/CD, and the technical decisions behind it.