Killing a system on purpose

Well, saying we killed it is a bit dramatic. We put it in maintenance mode. 

The system worked, consumers were starting to get used to it, and it already had widespread adoption across the platform. But a motion had been passed in engineering to modernise our frontend architecture. Replacing something broken is easy, but replacing something successful requires showing that the success against old requirements might be the wrong measure. 

Simultaneously, the company was starting to pivot to an AI-first operating model. The system needed to become machine-readable – and the existing component APIs weren’t playing nice. On top of that, the frontend architecture we were working in had numerous circular dependencies, which meant experimenting in that space with AI got extremely slow. 

So we made the decision to rebuild the web design system, and put it the current one in maintenance mode. The next decision was: do we use a library base, and customise it to match our existing components, or take it off the shelf with minimal theming and accept a slight visual shift? Our major constraint was time, so a complete custom rebuild was not on the cards. 

We ended up taking the second path, which would go against my very instinct as a designer. I didn’t want to have to fight a library at every edge case, or give up owning the styling layer.

But there were things we valued more: 

Speed. 
Components scaffold in minutes, and we hit 90% parity with our previous system in a 3 week spike.

Visually constrained, but structurally composable.
The library is more visually constrained, but we chose to treat that as a positive. It made generated output predictable. In a climate where the business needed to move faster than ever, we judged that as acceptable. But it also comes with a significant loosening of structure. The components are less opinionated, and non-monolithic. New layouts can be built from existing primitives, rather than props and variants.

We traded maturity for speed. We’ll have two systems running concurrently while we work on migrating features over. We chose to go backward on the curve to go forwards on architecture, because we recognise that high level maturity on the wrong foundations is a far more expensive place to be stuck at than low level maturity on the right one.