Building a design system across legacy products

Why I built it

Qube had multiple products, most of them legacy. I was the designer working across all of them, and the pattern was obvious: every product looked and behaved differently, engineering rebuilt the same components from scratch each time, and our users had to relearn interactions for every tool.

I needed a shared system. Not just for consistency, but for speed. We were a small team. Without reusable foundations, every new project felt like a humungous task, and every project took longer than it should have.

Getting buy-in

I started by building the token and component foundations within the design team. Once we were aligned internally, I pitched the system to stakeholders across the organization.

The buy-in came with hesitation. People liked the idea but were skeptical about the time it would take to build from scratch. "How do we migrate?" "What about the old products?" "This is going to slow us down."

That's when I suggested it was also okay to start with an existing component library and override the styling. We evaluated options and found BlueprintJS — a well-built system that matched our use cases and had components that behaved the way we needed. It wasn't the holy grail though. We still built a lot of custom components based on specific use cases. Tables, for example, needed to handle cinema-specific data patterns that no off-the-shelf library could.

I worked with engineering to create a practical plan: use the new system for anything new. No big bang migration. Just a clear decision framework for every new piece of work.

Building it

I built the design system alongside Qube Slate, our new cinema advertising platform. This gave the system a real product to serve from day one, not a theoretical exercise.

On the design side, I refactored the system multiple times as Figma shipped updates that enabled better token architecture, variants, and component structures. I documented everything: foundations, detailed variants, props, guidelines, and usage examples.

On the engineering side, it was a constant push. Changes in the dev team structure caused the system to get deprioritized more than once. I kept at it.

The hard part

Qube's product landscape was the biggest challenge. Multiple products, and a full redesign of all of them was never happening. The design system had to coexist with legacy interfaces, sometimes within the same product.

I did a lot of planning with the dev team to figure out where to draw the line on each project. Full page rebuilds used the new components. Small patches stayed as they were. It resulted in users seeing two different styles in one product, and that was the trade-off I decided to make.

Documentation changed everything

The design system initially didn't have documentation. It was only a component library with tokens. That worked for a while, but it became very difficult to maintain consistency even within the design team. Design debt started to increase, resulting in reworks.

So we decided to properly work on foundations and documentation — usage guidelines, component specs, dos and don'ts, edge cases. It made it very easy for any developer or designer to get started with the system without needing to ask someone.

Every component was documented across five tabs. An overview with purpose, variants at a glance, and best practices. Usage guidelines with side-by-side do/don't examples showing the component in real product context, not abstract samples. A variant matrix covering every combination of state, size, and type. A props table listing every configurable property, its type, accepted values, and defaults. And content guidelines with writing rules and tone guidance, so every piece of text in the product felt intentional.

Towards the end of my tenure, we even started documenting the system using NotebookLM, making it accessible to everyone whenever they had a doubt. Ask a question, get an answer grounded in the actual system documentation.

What made it stick

The documentation was genuinely useful. Not a design showcase, but a practical reference. Developers could find what they needed without asking a designer.

It proved itself on a real product. Qube Slate was built entirely with the system, and the speed benefits were visible to everyone.

Someone kept pushing. That was me. Design systems don't maintain themselves. Having someone who believed in it and wouldn't let it die was the main reason it survived.

The payoff: quality improved drastically across products, and design-to-dev feedback cycles dropped by 50-60%.