Unifying Overwolf’s product ecosystem with a shared design-system foundation
Overwolf's three product domains repeatedly recreated similar components, while hybrid pages that combined product and marketing lacked a shared token vocabulary. I co-led the foundation, defining tokens, color, typography, grids, and reusable components to enable consistent cross-team development.
System scope
Core + Semantic tokens
168 + 157
Primitives feeding a context-aware semantic layer
Platforms × Modes
4 × 2
Overwolf, CurseForge, Tebex, Nitropay
in Dark and Light
Products across 3 domains
17
6 Marketing, 5 Apps Platform,
6 CurseForge
Operational effect
One shared core token vocabulary across all products.
Phased rollout that preserved user predictability.
Faster shipping for web teams. Observed qualitatively, not instrumented.
Adoption beyond web products remained partial due to constraints in the development environments.
Project Snapshot
TIMELINE
Foundation built from July 2024 to July 2025. Adoption ongoing
ROLE
Senior Product Designer (co-owner of the shared foundation layer)
TEAM
Co-led the foundation with an Art Director (visual direction) and an Engineer (token implementation)
PLATFORM
Marketing Web (desktop & mobile) / Apps Platform Web (desktop & mobile), Console (desktop & mobile), Client (desktop) / CurseForge Web (desktop & mobile), Consoles (desktop & mobile), App (desktop)
USERS
Marketing & Product Designers, Engineers
challenge
Three design languages across one ecosystem
Marketing sites, the Apps Platform, and CurseForge products each maintained their own visual systems. Gamers moving between the Overwolf client, the App Store, and the CurseForge mod pages encountered three distinct products.
"Products started to feel like separate entities across platforms, with inconsistent visual and interaction patterns."
Alon Rabinovitz, CPO
Teams repeatedly rebuilt the same components across products, yet no one truly owned them. Legacy gray palettes varied across domains. Hybrid pages lacked a shared vocabulary across marketing and product contexts, and engineers working in different environments translated custom designs into ad hoc code.
When a new Art Director arrived with a plan to refresh the brand, there was no system in place to support it. Overwolf’s design principles provided alignment vocabulary, but the underlying structural foundation was missing.
What I couldn't change, and what I had to protect
Hybrid products
Some products combine marketing and product components on the same page, so the semantic layer needs to serve both contexts from a single source.
Different development environments
Because products use different technology stacks, the token system needed to be universally compatible.
Guardrail
Users shouldn't feel they're using a different product overnight.
Where we started
No shared tokens existed. Each domain maintained its own colors, typography, and components, and there was no instrumentation to measure design velocity, adoption, or consistency. That gap ended up mattering, and I'll come back to it.
dESIGN TOKENS
0
Each domain maintained its own design source of truth
DISCOVERY
Benchmarks and standards studied, three recurring patterns
Before making any changes, I reviewed Material Design, Atlassian, Polaris, Fluent, Carbon, eBay Playbook, Ant Design, Vibe, and the W3C token standards. My central question was how to build a system that could serve multiple products without becoming overly rigid or overly fragmented.
The benchmarks converged on a recurring pattern: a primitive layer feeding a semantic layer, sometimes with component tokens above. They handled product surfaces well.
The hybrid marketing and product context that reshaped the architecture
For example, the constraint surfaced in the App Store. A single product detail page featured a promotional hero and media assets at the top and an app review functionality below the fold. Promotional and functional content share a single frame. Other products did the same combination.
This wasn't named in the original specifications. It emerged from analyzing legacy library files, real product pages, and team feedback, and it reshaped every decision below.
Separating marketing and product semantics would force context switching in hybrid files and create parallel systems indefinitely.
Solution
Build what serves the team now
Each decision addresses the same issue, the absence of a shared foundation, but approaches it from a different perspective: architecture, alignment, a context-aware semantic layer, and handoff.
While tokens provided the architectural framework, the foundation also includes palettes, typography, icons, components, templates, grids, and a knowledge session to support adoption. The four decisions below shaped all subsequent elements.
Ship two tiers, not three
The question was not whether a three-tier architecture (Core, Semantic, Component) is theoretically superior, as it is in a mature system. Instead, we needed to determine whether it is the best choice for our current needs.
I selected a two-tier structure: Core (168 primitive tokens) and Semantic (157 context-aware tokens used directly by components). I presented the three-tier model during the knowledge session for conceptual clarity, but did not implement it.
Component tokens add an additional layer for designers and engineers to manage. At that stage, introducing a third tier would have been premature and would have increased daily complexity without immediate value.
I chose the simplest architecture that matched the team’s current needs.
Three legacy gray palettes became one
Each domain, including Marketing, Apps Platform, and CurseForge, maintained its own gray palette. This resulted in different hex values for similar neutrals and inconsistent Dark and Light coverage across products.
I consolidated them into a single Gray scheme: 17 neutral grays stepping from neutral/0 (#FFFFFF) to neutral/128 (#000000) in 16-unit intervals, and adapted it to 14 for both marketing and product. Each neutral was converted into a token that resolved to Light and Dark mode values through the semantic layer.
Building the semantic layer during consolidation allowed products to avoid duplicate migration costs. As each product adopted the new tokens, the unified Gray scheme was implemented. The two-tier architecture supported consolidation without requiring remapping for each product.
One shared gray scheme reduced duplication and made consistency scalable across products.
Let the semantic layer serve both product and marketing
The hybrid-context constraint revealed two options. Product-only semantic tokens would force marketing components into one-off styling. Separate semantic layers would require designers to switch contexts mid-file on every hybrid page and maintain parallel systems indefinitely.
I built one semantic layer that resolves correctly in both contexts. For example, a unified semantic layer. --color-surface-brand-ow resolves to the correct Overwolf red in both a CTA button and a hero banner, and --color-text-primary works in a data table and a marketing paragraph. The 4 platforms — Overwolf, CurseForge, Tebex and Nitropay. Each have brand token families that resolve through the same layer.
I built one shared semantic layer instead of fragmented parallel systems.
Hand off through a spreadsheet, not a pipeline
"Different development environments" meant we couldn't assume every team could use a modern token pipeline. A Style Dictionary setup or a Figma Tokens plugin would have been cleaner for the web, but would have delivered no value to the desktop client or to consoles built on the React admin framework.
I created a Google Sheet listing each token name with its Light and Dark hex values. Web developers could copy these into CSS custom properties, while non-web teams used the sheet as a shared reference, even if their technology limited full implementation.
This approach ensured all teams could access and use the information.
Adoption mattered more than technical elegance. I chose a handoff every team could actually use.
RESULTS
What shipped, verified at source
core primitive tokens
168
Color, Typography, Spacing
semantic tokens
157
Light/Dark mode support
platform brand families
4
Overwolf, CurseForge, Tebex, Nitropay
Products across 3 domains
17
6 Marketing, 5 Apps Platform,
6 CurseForge
The foundation was more than tokens
Color pallets
The system let Marketing roll out the brand refresh without product-by-product negotiation of visual direction. In the Apps Platform, the design of current and upcoming features could benefit from using shared tokens rather than one-off styles.
Typography system
The system let Marketing roll out the brand refresh without product-by-product negotiation of visual direction. In the Apps Platform, the design of current and upcoming features could benefit from using shared tokens rather than one-off styles.
Grid system
The system let Marketing roll out the brand refresh without product-by-product negotiation of visual direction. In the Apps Platform, the design of current and upcoming features could benefit from using shared tokens rather than one-off styles.
Component, and template library refactor
The system let Marketing roll out the brand refresh without product-by-product negotiation of visual direction. In the Apps Platform, the design of current and upcoming features could benefit from using shared tokens rather than one-off styles.
Shared tokens turned brand alignment into default behavior
The system let Marketing roll out the brand refresh without product-by-product negotiation of visual direction. In the Apps Platform, the design of current and upcoming features benefits from using shared tokens rather than one-off styles.
Impact evidence is qualitative because baselines weren't instrumented
Token counts were measured directly. The velocity claim is based on observation, as no baseline was established at the project’s outset. No A/B test was conducted. The attribution is based on team feedback collected over 6 months.
"We can build and ship things faster than we used to."
Miriam Moshinsky, Art Director
Tokens gave me a clear vocabulary for mapping designs to code, reducing one-off values and saving implementation time.
Ben Koren, Front End Developer
One foundation feeding three domains
Component refactoring continues across all three domains on the semantic foundation.
rEFLECTION
What I’d do differently
Validate engineering in discovery
If we had identified "different development environments" earlier, the foundation could have supported universal adoption rather than just the web. The web-first compromise remains my main regret about this project.
Instrument baselines before writing the first token
No before-and-after metrics were measured. Even using rough proxies, such as feature ship time or the number of hardcoded colors, would have provided more defensible results than relying solely on qualitative outcomes. For a year-long systems project, this represents a missed opportunity.
What I took from this
Let’s collaborate
Senior, Lead, or Founding Designer roles.
Complex B2B preferred. AI-augmented teams welcome.
On-site or hybrid. Israel-based.
