When I moved from India to the UK, I arrived with two suitcases and a lot of optimism. I moved into a small flat with no furniture, no cutlery, and no kettle. So I did what everyone does. I went shopping. And then, I kept shopping.
Three months later, I had five cheese graters, four colanders, three chopping boards, and seven sets of mugs. I had absolutely no idea what I actually used or needed.
I did not plan to create clutter. I just kept solving the same problem, slightly differently, every time. Before I knew it, I had more stuff than I needed. One Saturday morning, I had enough and cleared the clutter out. I did not want to be bogged down by unnecessary choices every time I stepped into the kitchen.
The design system kitchen
Fast forward a few years later. I joined a team to help modernise a design system. My goal was to bring in more structure, improve consistency, and help teams build features with confidence. But when I first opened the component library, the feeling of that kitchen came back.
I was looking at a library full of options. In fact, there were too many options for the same thing. They all were trying to solve similar problems, slightly differently. It had not happened overnight. Things had built up slowly and with good intentions. Everyone had been solving problems the best they could at the time. Without a shared structure, those quick fixes started to pile up.
It was not broken. It was bloated.
The cost of complexity
I wanted to understand the cause of it and found a number of basic issues. There was no documentation. There was no dedicated development team. There was no real bridge between design and code. Even when people wanted to use the system, they were not sure how or if they could trust the coded components.
Designers used whatever looked latest. When those designs were handed over to the developers, they tried to match things on their own, mostly by overriding an existing component. Some components were overridden so heavily that they barely resembled the original.
In the absence of clarity, teams just kept adding new components, new variants, and new ideas. Everything was layered on top of each other. That is how the design system got messy. It did not happen from one big mistake, but from lots of small fixes made in isolation. It did not guide decisions. Instead, it delayed them. People hesitated, work slowed down, and over time, confidence in the system started to fade.
Clearing the path
To solve this, we started by pausing. We stopped adding and started looking. On the design side, we began mapping out everything in the library, every component, every variant, and every duplicate. We asked ourselves a simple question. Is it serving or just surviving?
Some were still useful, but most had not been used in years. On the development side, we dug into the codebase to see what was really going on under the hood, with overrides, inconsistencies, and components that looked the same but behaved completely differently. We brought in the feature team perspective to understand what was slowing people down and where they needed support most.
We went through it all and flagged what was safe, what needed rework, and what had to go. We took a step back and aligned the vision for the system. This was not about starting over. This was about clearing the clutter.
Building for the future
From there, the rebuild began. We started trimming the fat. Some of it was tedious, and some decisions were hard. But every time we cleared something that did not serve a purpose anymore, the system got lighter.
We introduced tokens to bridge the gap between design and code. We modernised the core components and merged duplicates. We baked in accessibility and, for the first time, we had documentation. It was not perfect, but it was enough to build trust.
We did not add more. We just made it easier to trust what was already there. It was not about going fast. It was about making it last. Over time, things shifted. Designers stopped second guessing which version they should use and started trusting the system to guide them.
Final thoughts
Progress is not always about adding. Sometimes, it is about letting go. We like to think progress means more options, more features, and more tools. We think this way because every time we add something, we convince ourselves it is important. But when everything is important, nothing truly is.
When you let go, you make space. Space for clarity, space for better decisions, and space for momentum. For us, the real progress was not about what we added. It was about what we cleared away so the right things could stand out. It changed how we saw our work. From more to meaningful and from fast to focused.
Next time you are about to add something new, whether it is a feature, a pattern, or a component, ask yourself. Will this grow the garden or just block the path?