Club Tie Design System
From two systems to one product
Project type
Design System
Year
2024
Client
Club
My role
Head of Design — Product & Design Systems
We were building a new product, but designing it twice. When I joined, development had just started. This was the new Brandbassador, still early and moving fast. But the product didn’t run on one design system, it ran on two. Club Jacket for the platform, and Club Tie for the app. At first, it seemed reasonable. Different platforms, different systems. But it didn’t take long before it showed. Two systems for one product didn’t scale.
Problem
The system didn’t break all at once.
It started to drift.
As we built more features, the same flows appeared in both the platform and the app.
But they weren’t built the same way.
Different components.
Different patterns.
Two design systems.
So every time we solved a problem, we solved it twice.
That’s when it became clear.
The system wasn’t scaling.
Insight
The issue wasn’t technical.
It was structural.
We had built systems around platforms, not around the product.
But users don’t experience platforms.
They experience one product.
Reframing
Instead of maintaining two systems, we needed one shared foundation.
We didn’t merge everything.
We started over — using Club Tie as the base, since it was the most mature system.
From there, we shaped something that could support the entire product.
My role
My role was to take the system and make it scale across the product.
I focused on how the system behaved in real use — from how features are structured in the platform to how they are experienced in the app.
I designed flows and helped define the templates needed to support real product workflows.
I identified gaps and introduced new components.
I reviewed and refined components across the system.
I helped align app and platform behavior.
And I extended the system into web surfaces through HubSpot CMS.
The system structure was defined by a design system designer, focusing on the foundational layers — tokens, components, and overall architecture.
Together, we defined the template layer that connected how features are set up with how they are experienced, and ensured it was implemented consistently with frontend teams.
System
The foundation followed atomic design.
Tokens, components, and patterns structured the system.
Components were built and documented in:
Storybook for React
Widgetbook for Flutter
This gave us a shared reference across platforms.
But the real value came from how the system was used.
Evolving the System
As the system matured, we changed how we worked with it.
In 2025, we started building components directly using Cursor instead of relying entirely on frontend teams.
This reduced the gap between design and implementation.
We could test ideas faster.
Refine details directly.
And have more control over the final quality.
It didn’t replace developers.
It removed friction.
What Changed
Before:
Features were designed twice
Systems diverged
Iteration required multiple handoffs
After:
Flows were reused across platforms
Components evolved based on real needs
Design and implementation moved closer together
Templates made it possible to assemble screens instead of redesigning them.
The system started to reflect the product.
Result
Work became more focused.
Less duplication across teams.
Faster iteration.
More consistent patterns.
The product started to feel like one system again.
Impact
Reduced duplicated work across platforms
Faster design and development cycles
Better alignment between design and code
Increased control over quality and polish
More consistent experience across app, platform, and web
Key Insight
A design system shouldn’t be built around platforms. It should be built around the product. This wasn’t about merging two systems. It was about rebuilding the foundation so the product could scale without breaking.
