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 nervous about implementation. "How do we migrate?" "What about the old products?" "This is going to slow us down."
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.
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%.