Saturn Heavy

Real-user performance · CrUX field data

Saturn HeavyvsGargantua

Two equivalently-sized brands measured side by side.

mobiledesktop

Largest Contentful PaintLCP

3.9 s1.8 s

−54%

First Contentful PaintFCP

3.4 s1.0 s

−71%

Time to First ByteTTFB

3.3 s0.7 s

−79%

TL;DR

Multi-brand design system

One system, twelve brands

Saturn Heavy is more than a component library, a set of token or collection of guidelines or patterns, it's well-thought through, meticulously designed and developed design system that allows brand configuration with kernelTheme as a base that saves tons of headaches, and allows creating brands with differentiation, while keeping core architecture exactly the same.

Saturn Heavy allows configuration of 12 brands so far, but was built to host 100+ brands, that would be build in weeks instead of months.

kTkernelTheme

• PSRPolestar
• GEMGemini
• ORNOrion
• MERMercury
• VEGVega
• KERKepler
• SRSSirius
• ARMArtemis
• STRStratos
• PHEPhoenix
• ANDAndromeda
• NTLNautilus

Intro

Just right before restructuring, two things happened:

• after years of persuading Figma procurement was finalized,
• Terraform, the frontend transformation programme got announced.

Years of accumulated work on a legacy platform - Gargantua - had reached the point where patching it cost more than replacing it. The Operator after seeing one of 2024 hackathon projects, gave a green light for new platform built around principles set during said hackathon.

Goals

Key results of Terraform have been agreed. Five areas of improvement have been established, each with concrete outcomes the programme would be measured against.

Terraform · Key results

1. Web performance

   Every page migrated off Gargantua should land with LCP under 2.5s. This was a hard deck.

2. Flexibility

   The Operator can use Saturn's Library as any other UI Library, and be able to extend Saturn on its own.

3. Extensibility

   Thanks to agnosticity of Saturn Heavy the Operator should be able to connect any CMS to the platform.

4. Time to market

   A new brand should be shipped in two weeks. All product verticals can be turned on a on turned off on daily basis.

5. Operator autonomy

   The Operator should be able to create, modify and manage components, layouts and themes autonomously end-to-end.

Out of scope

• Vertical UX/UI

  Saturn Heavy should not make changes to UX nor UI of the brands.

• Third-party integrations

  Analytics, A/B testing and the rest of the features of that nature should stay in their current form.

Team Evolution

A team was assembled with two co-leads at its spearhead - an engineer lead and me as a design lead

First we were: 1 designer, and 4 engineers with support from 2 architects. Our initial task was to set up the environment. I drafted a comprehensive proposal that sketched parts of the system, workflows, and process, as well as governance, and future evolution. Everything we needed to stop building in waterfall, and start shipping quality with agile principles, faster than ever before. Based on my data by the mid-2025 we were delivering design ~14x faster than before Saturn Heavy

Once we got our environment going, whole team involved in the hackathon project (codename: Wargs) was assigned to Terraform, alongside initially 1 product manager, and later 2 more, that made the Product team. Thanks to this we had almost 20 people on-board.

Once MVP was released with great feedback from the Operator, and green light lit for transferring all brands to Saturn Heavy, I was able to on-board 5 more designers to help with Saturn, through kicking-off new project: Titan (more about it later).

Next move of leadership team was to assign another team (codename: Foxes), that actually originated from Wargs. No long later, our design team grew as well, with new recruitments we had 15+ designers including DesignOps on-board. At the same time, additional several internal and external, 3rd party, teams were added to the roster. At its peak Saturn's dynamic duo managed 110+ people.

Designers

Engineers

Architects

PMs

Internal teams

External teams

MVP

The next quarter had two effective months in it. Christmas and New Year ate the rest. The MVP cut-off was non-negotiable, and Figma had only landed in October. There was no time to rebuild an Adobe XD design library from to clean Figma file before the deadline. Especially that MVP was a real working brand.

So I did the unfashionable thing. We shipped the MVP using XD. It was MER's homepage, yet due to its complexity it wasn't to be an easy task, and we learned that pretty quickly.

That sounds like a step back, yet every component had to be Figma-portable from the first frame. It was already planned that right after delivery of the MVP, we will move all our work including Saturn Heavy to Figma.

The Operator was the other shape of the constraint. They would not move on layout or visual design, CMS had to stay as it was. They reserved the right to inject HTML and CSS into content pages on their own, and they refused to give that right up, even after we offered to absorb the redo work ourselves.

We started with 4 basic components, and 1 composite component, while setting up foundations: typography, spacing, colors, grid system, icons, elevation, shadows, borders and radii.

MER's brand was audited, and its foundations were harmonized. Three-tier tokens taxonomy was introduces (Primitive / Meta / Component) with the 80% at Meta level. That decreased potetntially number of tokens from 36,600 to ~200 tokens. Said ~200 tokens were tested with MER to PSR re-skin.

We wanted to make sure that said token taxonomy will last, after sbsequent loops of token mapping. Having all secured on MER and PSR, I went extra mile, and tested the taxonomy and mapping outcomes on other 10 brands we had in our roadmap, and shipped the updates.

It meant additional extra effort, yet that way we were able to coin system, that would not change that much along the way, and make solid foundation for the finalized Saturn Heavy design system, and extracting Component Level Tokens.

Thanks to that strategy, in such short period of time, we were able to ship 20+ components with all possible variants to cover scenarios in the homepage, as well outside it. This made a great head-start for finalizing MER, and to start work for rest of 11 brands.

Saturn Heavy

Getting to the most interesting part of the project. Once we got green light to transfer all brand to Saturn all extra work done during MVP paid off.

But before we will take a deep dive, let's first look at Saturn's high level architecture.

Saturn Heavy · High-level architecture

Brands were divided into parts. These part were audited. List of components was delivered - making separate batches that was distributed to the teams in engineering, and to separate designer in the Titan team.

Context and later on feedback was given during kick-off workshop, as well as during periodic stand-ups, and thematic meetings.

Our new procedural workflow was divided into 8 stages, that were loops not lines of work, with a procedural Peer Checks after each smaller, incremental delivery.

Progressive Design Model · CI/CD for design

1. 01Monitoring the Fundamentals
2. 02Continuous Integration
3. 03Continuous Stewardship
4. 04Continuous Feedback
5. 05Integration Testing
6. 06Continuous Delivery
7. 07User Acceptance Testing
8. 08Quality Assurance

Project Titan running simultaneously, delivered all necessary documentation templates, guidelines, rules and pattern in Figma. Meaning all these stages where happening via Figma and Dev Mode as medium. Nonetheless, all communication was brought to lower level, where any engineer could direct its question or doubts to dedicated Mattermost channels, thus fulfilling the Agile paradigms.

This communication system worked like a charm, and allowed both Saturn and Titan teams to be ahead of their respective roadmaps. Such way accumulated extra manpower could be driven for additional improvements, internal tool development, for the benefit to the design system, and final outcome of Terraform.

Another thing that worked, was decision to reduce amount of mockups delivered to absolute minimum. My philosophy was that reliable Saturn docs in Figma paired with quick responses on MM should be enough, to execute any PRD.

Both through Saturn and Titan projects I've promoted the idea, persisted and persuaded product managers to not request mockups, but allow engineer to take ownership of their line of duty, and if necessary supplement them with very lo-fi outline of the task paired with written specs. It was a bumpy road, I must admit, yet in the end it paid off 10x.

Central point, and heart of the Saturn Heavy Design System is Storybook as a single source of truth, and embodiment of Halo UI that give the visual aspect of Jupyter that builds all components with SSR (server-side rendering).

By the end of Terraform, only essential mockups were delivered. Core of the delivery was reduced to design decisions inside Figma's Halo UI counterpart, Design Tokens in JSON format, and code snippets, like in case of grid system, buttons, and other sophisticated parts of design that had to be tested beforehand.

Panda CSS was chosen for three reasons. It allowed building components based on specific design tokens. It only generates classes that are actually used, so the bundle stayed small even after 12 brand themes were live. And it treats theming as a first-class config — default and _dark semantic tokens, dynamic runtime switching. The three-tier model lived in the design documentation and in the Panda config under exactly the same names and naming convention.

It is worth mentioning, that engineering squad outside standard lint, prettier, etc. written its own tests, to make sure that each piece of code contributed to fulfilling the Main Goals of Terrafrom.

Halo UI

Due to complexity of brands' own UI, a few new concepts were implemented in Halo UI to be able to hit best mark at performance, flexibility and extendability of the Saturn Heavy platform.

Backgrounds vs. Surfaces

In a nutshell a surface is the base layer a UI sits on. A background is the fill of a component on that surface. They can share a HEX code by default, yet behave completely differently when their environment changes.

The whole point of implementing such concept allowed very token-cheap switch between brands, whether they are predominantly light- or dark-themed, or whether user would switch from light-mode to dark-mode.

Through such sneaky tactical approach of defining a layer as a surface or a background, all the design decision are made automatically without an intervention of a designer or an engineer, UI decides on it's own.

This allows immediate shipping of new UIs into any brand, at any mode, while guaranteeing accessibility, contrast and legibility of all UI elements themselves.

lightdark

MERPSRGEM

Page

Sidebar

Card

Saturn Heavy in production

12 brand themes shipped from a single token spine — zero one-off overrides.

SaturnLaunch Saturn Heavy

Surface

OKLCH(0.277 0 0)

Surface

OKLCH(0.339 0 0)

Surface

OKLCH(0.45 0 0)

Background

OKLCH(0.83 0.18 160)

Tones Color System

Tone concept is a tool to provide optimal legibility of UI Elements placed upon Surfaces and Backgrounds.

Tones are categorizing a color based on its luminance (lightness or darkness), to allow different treatment at scale.

The answer was a classification we called Tones. Every brand colour landed in one of three luminance bands — lightTone, evenTone, or darkTone — and each band declared which foreground tokens it would accept.

In order to determine colors Tones, the APCA methodology was used, where Luminance (L) is measured and Contrast (C) is compared between pairs of colours.

Color Tonality Classification

Color

Opacity100%

Background

Rendered

Label

Composed sRGB

#29EA9E

R'=41 · G'=234· B'=158 (fg blended onto bg at α=1.00)

L = 0.2126·41 + 0.7152·234 + 0.0722·158

L = 187.48 → evenTone · brand · override

darkTone

evenTone

lightTone

L=0L=64L=191L=255

Similarly to backgrounds and surfaces, such approach of defining a color as a lightTone, evenTone, or darkTone, all the design decision are made automatically without an intervention of a designer or an engineer, UI decides on it's own.

This also allows immediate shipping of new UIs into any brand, at any mode, while guaranteeing accessibility, contrast and legibility of all UI elements themselves.

In this demo, you can see the difference of WCAG and APCA methodology, and see for yourself why we picked APCA.

Contrast method

apcawcag

Surface Deck Levels

Defining exact surfaces color for each deck level, simplifies building complex UI and automates design decision about UI components and elements placed atop said surface.

Number of deck should be limited. In this example it stop at 5th deck. What is more important, if necessary after last level deck the pattern repeats itself.

3

lightdark

surface · deck 0 (page)

surface · deck 1

surface · deck 2

surface · deck 3

Saturn Heavy in production

12 brand themes shipped from a single token spine — zero one-off overrides.

SaturnLaunch Saturn Heavy

Meta Tokens Heavy Lifting

One of the major goals I've put forward in Saturn and Titan design pods was to minimise the amount of tokens that set up a brands.

Most of design system out there are fully tokenized, that's a standard, but also most of them have thousand token saved as design decisions.

Halo UI was suppose to be different Meta Tokens — a thin layer of tokens that don't describe a value directly, but a meta-decision that is taken based on systemic thinking. Those smart choices amounted only to ~200 tokens that driven close to 80% of the design.

Well-designed Meta Tokens with Surfaces/Backgrounds, the Tones colour system, and Surface Deck Levels already programmed into the chain collapse those thousands of permutations into a handful the design system can actually resolve.

The payoff: a new brand lands in production in a week with perfect contrast, accessibility and craft quality, and enough visual differentiation from the other eleven to feel like its own product. An why new brand adoption became matter of a week? Becasue Halo UI resolved all design decision on its own from the get-go.

PSRMERAND

Primitive

color-blue-500

oklch(0.58 0.17 240)

Meta

surface-action

color-blue-500

Component

• button-primary-bg

• link-primary-text

• tab-active-bg

  surface-action

Renders as

Every component below consumes surface-action

Button

Primary action

Link

Learn more

Tabs

OverviewReportsInsights

Composite Components

It was imperative, that all basic component would be designed in a way to be able to compose a very complex and specialized composite component. And even though it seems like an easy task, you'd change you mind when you'd have to design a sports coupon in a very niche sport with thousands of possible permutations.

Composite Components future builds had to be audited beforehand and implemented on the basic-component-level. That demanded a lot of research and testing, which unfortunately, never come up as tangible results, that can be shown to stakeholders.

lightdark

MERPSRGEM

Legacy CupQ1 2025

SATSaturn

vs

GARGargantua

11.40X8.00212.00

Brand BracketMER · PSR

MERMER

vs

PSRPSR

12.10X3.6022.40

Engineering CupQ3 2025

WARWargs

vs

FOXFoxes

11.95X3.8022.60

Component-Level Dark Mode

Component-level dark mode was a solution to technological constraints, where part of the UI had to sit in the old architecture or due to specific Operator's decision. Instead of extending CSS, and component-level tokens, over all possible components to sit in the always-light-mode parts of UI, I came up with a method, where UI would only turn light mode for that particular part.

A component knows whether it is regardless of the mode it lives on; its surface/background drives all design decisions. And what is most important, there are no overrides, and no need for their upkeep when brand changes. New brand doesn't have always-light-mode UI part - boom - Component-level dark mode is turned off.

Section 1 · mode: dark

Standard feature card

Foreground tokens cascade from this card's mode.Action

Section 2 · mode: light

Inverted promo strip

Foreground tokens cascade from this card's mode.Action

Section 3 · mode: dark

Continuation card

Foreground tokens cascade from this card's mode.Action

Titan

Titan ran on its own roadmap, its own roster, and its own cadence. It was symbiotic with Saturn Heavy. Saturn answered "what does a component look like in this system". Titan answered "how does a component get there, how it is built, what variants has, etc.".

The migration itself was the surface job. Sixty-plus components from the legacy library had to be redone against the colorTones system, Token Mapping, Backgrounds vs. Surfaces and Surface Deck Levels, and served in batches while Saturn was moving forward.

We squeezed last juices from Figma. Almost a year ahead of updates, we had separate Variables Collections working, to serve out mutli-brand design system.

I cannot share any file here, due to the NDA, yet I'm very proud of what we have built together as a Titan team. And I'd love to show it you, so you can appreciate all feature of our Titan documentation has.

Scaling

The Operator green-lit the full 12-brand migration, the engineering count went from 14 to 100+, and most of the new headcount was outsourced. Differentn 3rd party companies, different timezones, different working hours, different defaults for what DoD and DoR meant.

A team of few can hold a shared working culture in a Mattermost channel. A team of a 100+ across multiple entities cannot. It needs governance and structure.

The honest version of this chapter is that we got the cultural part wrong before we got it right. The first month with the expanded engineering footprint, components started landing that passed the peer-check on the surface and broke the system underneath. Styling was added on the Halo UI level instead of Jupyter level. Tons of debugging, constant questions on support channels.

There was a point were support became majority of task handled by design pod and core engineering pod. But it all worth the hustle. Question never landed into a void, each designer had an assigned line of support duty, and it brought results. I'd argue that getting so close to all engineers, with those thousands of messages exchanged on a weekly basis, made the design system implementable in the way it was intended.

Second step was tightening the governance. We ran recorded the answers and decision, and built internal tools (like Semantic Atlas) that structured tasks, and introduced certain level of automation to mundane chores, reducing errors and bugs. The point was to reduce the human cost of doing the right thing, the right way.

In the end Terraform had absorbed an order of magnitude more people than it had been designed for, and after all hard work organizing it, it held its ground.

Growth

Saturn Heavy became a well-oiled machine — motivated people, clear goals, a shared strategy, and a roadmap everyone could read off the same page. Cross-collaboration was the engine of it. Design and engineering pulling in the same direction, week after week.

By the time I went on paternity leave, the system shipped that week. And the week after. And every week since. I had the privilege of helping set the conditions for that. The Saturn and Titan teams kept it running.

That was the point. A design system that needs its lead in the building every day is not a system, it is a person standing in for one. Saturn Heavy was built to outlive my hands on it. The documentation template, the peer-check gate, the semantic-tier discipline, the PDM pipeline. All of it was designed so the answer to "should we ship this" lived in the system, not in me.

Also whole point of planning in first phases, was to design a system, that had most design decision already in it. I what I'm most proud of, the vision of automation became a reality.

Though if I'd start again tomorrow:

1. I'd push more for a Panda-CSS-compliant UI Lirabry instead of building all components from scratch, even the most basic ones. Specificity of our products needed solution like Panda CSS - hands down. Yet, we could ahve easily outsourced basic components to an already established UI Library. That way we only would need to commit to a rework, that would be less costly. I was in the room, when decision was made, I should have pushed even more.

2. I'd push even more to switch to lo-fi wireframes , alongside written specs in all tickets, to save time and manpower for other design task. I really felt that a lot steam was blowing into that whistle, and the rain that came from that cloud was just a drizzle.

Every designer, every engineer, every architect, every PM across Saturn, Titan, Wargs, Foxes, and the outsourced partners that made up the rest of the Terraform crew: thank you.

The individual craft is what built the system, the collaborative pull is what holded it together.

Credits

Saturn Heavy would not exist without the people I collaborated with through the research, the implementation, the refinements and the month of great cross-collaboration that followed. Recognition is more than due, both for individual and collaborative efforts. The names below link to LinkedIn.

Project info

Role. Principal Product Designer and joint Head of Project alongside the Principal Software Engineer. End-to-end ownership of the design system from MVP through twelve-brand migration to handover.

Expertise. Design systems, multi-brand theming, design-engineering collaboration, leadership through organisational upheaval, governance at scale, agile process design. Coined the systems language Saturn Heavy runs on: Surfaces vs. Backgrounds, Tones, Token Mapping, Surface Deck Levels, Meta Tokens, Composite Components, Component-Level Dark Mode, and the Progressive Design Model.

Platforms. Web (mobile and desktop), regulated multi-brand iGaming and sportsbook portfolio. 12 brand themes shipped from a single token taxonomy, with new brands landing in production in less than 2 weeks.

Affiliation. The Operator and The Workshop (under NDA).

Tools. Figma (Saturn Heavy proper), Adobe XD (MVP only), W3C design tokens in JSON, Halo UI Storybook as the single source of truth, React, Next.js build, Panda CSS for runtime theming and semantic-tier tokens, Mattermost for cross-team engineering channels, internal CI/CD pipeline for design (the Progressive Design Model).

Team. 5-person design pod supporting 12 brands, in cross-collaboration with engineering scaling from initial 14 to 100+ engineers. Dynamic-duo operating model with the Engineering Principal; peer-check process embedded in the Titan and Saturn teams' working week. Cross-collaboration efficiency lifted 4.5× after introducing Agile in Design Team alone.

Outcomes. Mobile real-user wins on the migrated brand vs. the legacy brand: LCP −54%, FCP −71%, TTFB −79% on CrUX field data. 60+ components re-authored through Project Titan. zSaturn Heavyz continued to ship without me from the first week of paternity leave onward — the goal from day one.