Dice Design System | iGaming | Fintech | Gamification

Structure

New Figma Libraries Structure

To modernize and streamline our multi-brand design workflow, I defined a new Figma libraries architecture for the Dice Global Design System. The goal was to create a scalable token-driven foundation that supports multiple brands (Entain & BetMGM) while maintaining strong consistency across shared components.

1. Brand-Specific Reference Tokens

The system begins with a set of Ref Tokens for each individual brand (A, B, C, D, E).
These tokens represent brand identity at its core—colors, typography scales, spacing primitives and other foundational values.
Each brand maintains its own reference layer, ensuring that identity-specific attributes remain isolated and easy to update without affecting the rest of the system.

2. Shared Semantic Tokens

Above the brand layers sits a unified library of Semantic Tokens.
This layer translates brand-specific primitives into shared meaningful roles (e.g., primary-button-bg, surface-elevation-1, text-subtle).
Semantic tokens allow all components to remain brand-agnostic while preserving a consistent logic across the entire design ecosystem.

3. Global DS Library

At the core is the Global Design System library managed jointly by the Entain & BetMGM Global DS team.
This library includes:

• Component Tokens

• Shared Atoms

• Cross-brand Components

By building components that rely purely on Semantic Tokens, we ensure that the same component adapts instantly to any brand simply by switching token libraries.

4. Local Brand Libraries (Entain & BetMGM)

Below the global layer, individual brand design teams extend the system with brand-specific variants or custom needs:

• Entain DS Team

• BetMGM DS Team

These libraries sit closest to delivery, enabling teams to consume the Global DS components while adding brand-specific patterns or product-centric components as needed.

---

Outcome

This new Figma library structure establishes a clear hierarchy that is:

• Scalable — easily supports new brands and future expansions

• Token-driven — ensures consistent UI across all platforms

• Efficient for teams — updates flow smoothly from reference tokens → semantic tokens → global components

• Collaborative — empowers both the centralized Global DS team and individual brand teams

This architecture serves as a solid foundation for building a truly global multi-brand design system with flexibility and long-term maintainability at its core.

Structure

Token Architecture Deep Dive

To support a scalable multi-brand ecosystem, I introduced a refined token architecture for the Dice Design System. The new structure improves clarity, flexibility and consistency by organizing tokens into three focused layers.

1. Reference Tokens — Brand Foundations

Reference tokens define raw values such as colors, spacing and typography primitives. Each brand has its own isolated reference set to preserve identity and prevent cross-brand conflicts. This layer acts as the single source of truth for brand-specific styling.

2. Semantic Tokens — Meaningful, Consistent Roles

Semantic tokens translate raw values into purpose-driven roles like button-primary-bg or text-subtle. They enable consistent behavior across brands and themes while ensuring one token can adapt to light mode, dark mode and multiple brand identities.

3. Component Tokens — UI-Level Precision

Component tokens define styling at the component level without hardcoding values. They allow cross-platform consistency and controlled overrides while keeping component structures clean and scalable.

Outcome

This streamlined token hierarchy creates a predictable and flexible system that supports multi-brand theming, improves collaboration between designers and engineers and ensures consistent UI across the entire Dice Design System.

Structure

Overcoming Figma’s 40-Mode Limitation: Scalable Token Architecture for 40+ Brands

As the Dice Design System expanded across dozens of brands, we faced a critical technical constraint: Figma’s hard limit of 40 modes per file.
Our semantic layer relied on one file with one mode per brand, which worked at first but quickly became impossible to scale. Once we crossed 40 brands we could no longer add new modes, maintain consistency, or support new markets. The design system had outgrown the tooling.

This limitation became a major blocker for multi-brand growth across Entain’s global portfolio.

---

The Problem With the Previous Structure

Our earlier model placed all brand modes inside a single semantic token file.
This meant:

• No room to onboard new brands

• Semantic growth frozen by tooling

• Engineering and design unable to adopt new mappings

• The system constrained by Figma, not by strategy

We needed a new architecture that could scale infinitely.

---

The Solution: Distributed Semantic Files

To break free of the 40-mode limit, I introduced a modular multi-file semantic architecture.
Instead of one huge file, we split the semantic layer into smaller grouped modules:

• semantic-betmgm

• semantic-entain-AtoF

• semantic-entain-GtoO

• semantic-entain-PtoZ

• …and additional modules as new brands are added

Each module contains:

• A manageable number of brand modes

• Identical semantic structure

• Mappings that connect directly to each brand’s reference tokens

This allows the system to scale without ever hitting a technical ceiling.

---

The New Architecture

1. Reference Files (per brand)

Each brand keeps its own reference tokens for color, spacing, type, radius
These remain the stable foundation for all brand-specific values.

2. Semantic Modules (grouped by brand ranges)

Multiple semantic files, each with 10–15 modes
Same structure across modules
Different reference mappings per brand

3. Central Semantic File (Unified Access Point)

All modules connect into a single unified semantic experience
Designers switch brands from one place without noticing the underlying distribution.

4. Component Files (Token-Driven)

Components rely purely on semantic tokens
Brand variations happen instantly when switching modes
No hardcoded values buried inside component structures

---

Outcome

This distributed architecture transforms a tooling limitation into a scalable system that supports 50+ brands and growing. It is:

• Infinitely scalable — new brands plug in seamlessly

• Future-ready — no technical ceilings

• Organised — semantic modules stay lightweight and maintainable

• Consistent — designers experience one unified semantic layer

• Stable — reference values remain isolated and safe

This solution ensures the Dice Design System can continue expanding globally without friction.

Structure

Rebuilding Our Colour System: A Story About Chaos, Clarity & Craft

When I joined the project, our design system already supported multiple brands, themes and color modes. At first glance, everything seemed solid — we had palettes, tokens and component libraries.
But the moment I started working with real components, something immediately stood out.

Buttons that were supposed to look identical behaved differently across brands. States didn’t follow the same logic. Colors that passed accessibility in one brand failed in another. The deeper I looked, the more obvious the pattern became.

We didn’t have a color problem.
We had a color system problem.

---

01 — The Moment It Became Clear

While reviewing component states across three brands, I noticed something unusual:

• In one brand, “hover” was one shade lighter

• In another, it was nine shades darker

• “Active” sometimes moved up the scale… and sometimes moved down

There were no patterns. No shared rules. No semantic relationships.
Each brand had developed its own isolated logic for color states.

The cost of this inconsistency was significant:

Every time a color changed, designers had to manually test hundreds of component combinations to ensure nothing broke.

It was clear that our color architecture would never scale unless we completely restructured the system.

02 — The Emotional Pain of Manual Accessibility

Accessibility checks were happening… but painfully.

Designers were testing every colour against every text colour, then testing every state, then repeating the entire process for each component and each brand.

It wasn’t just slow — it was impossible to maintain.

We needed a way to guarantee accessibility before colours even reached designers’ hands.

That idea became the seed of a new system.

---

03 — Rethinking Colour From the Ground Up

I explored how other systems approached colour. Material Design offered inspiration but still showed inconsistencies in how states were defined.

So instead of copying a model, I asked a different question:

What if we stop choosing colours
and start generating them through rules?

That question changed everything.

---

04 — Building a Shared Language

I introduced a numerical colour scale from 0 to 140 —
0 representing white, 140 representing black.

This created:

• A universal scale

• Predictable steps

• Cross-brand consistency

• A simple mental model for designers and engineers

From there, I built a semantic layer:

Primary → On Primary → Container → Outline

Each semantic token followed strict rules:

• Hover = +1 shade

• Active = +2 shades

• Inverse variants stayed accessible by definition

For the first time, a Primary button in Brand A behaved exactly like a Primary button in Brand B.

We finally had a shared visual language.

05 — Accessibility Becomes a Formula Not a Guess

Manual contrast checks were slowing everyone down. Designers had to test every colour against every text value then repeat the process for each state and each brand.

I replaced guesswork with measurable thresholds:

• AAA (4.5:1) → colours must differ by 70 points

• AA (3:1) → colours must differ by 60 points

No surprises. No rework. Accessibility became predictable long before colours reached the UI.

---

06 — The Big Idea: Automate Everything

Once the rules were defined, it became clear that no designer should build a palette manually ever again.

So I designed a tool that could:

• Generate all 14+ grades from a single base colour

• Validate contrast automatically

• Export in Hex RGB and HSL

• Scale instantly across multiple brands

This tool became the foundation of a fully automated palette workflow.

---

07 — Designing the Figma Plugin

The plugin became the engine of the entire colour strategy.

With one input colour, designers can now:

• Generate a complete accessible spectrum

• Export all grades

• Apply it to any brand

• Build semantic tokens instantly

Accessibility is no longer a task. It is an automatic outcome of the system.

---

08 — The Results

With the new colour model in place:

• All brands follow the same colour logic

• Semantic tokens behave consistently

• Accessibility issues drop to zero

• Updating colours never breaks components

• Designers work faster with full confidence

• Entire palettes can be generated in seconds

What was once a fragmented process is now structured, predictable, and scalable.

---

09 — What This Work Taught Me

This project was more than a colour fix. It was a shift in how teams trust and use a design system.

Key learnings:

• Consistency comes from clear rules

• Accessibility improves when solved upstream

• Tools elevate systems

• Colour is functional, not decorative

• Scalability comes from logic, not volume

Structure

Rebuilding Typography for a Stronger Design System

Modernizing the Dice Design System

Typography shapes hierarchy, clarity, and brand expression. As the Dice design system expanded, its type structure became overloaded with too many styles, unclear naming, and inconsistent usage across products. This created friction for designers and uncertainty for developers.

To address this, I redesigned the entire typography architecture.

Identifying the Challenge

The old system included separate stacks for headings, paragraphs, links, CTAs, and bold variants. It was detailed, but it came with several problems:

• Redundant styles with overlapping purposes

• A visual hierarchy that lacked clarity

• Names tied to components instead of meaning

These issues made interfaces feel inconsistent and slowed teams down.

Designing a Simpler, Smarter Type Structure

The new typographic model is organized by purpose rather than component type. It introduces four clear categories:

• Titles — expressive and high-impact

• Headings — structural and flexible

• Body — optimized for readability

• Labels — compact and functional

This simplification reduces clutter, improves hierarchy, and makes the system easier to use. The naming is now semantic, scalable, and developer-friendly.

The Outcome

The redesigned typography delivers:

• A clearer and more intuitive hierarchy

• Fewer, more focused styles

• Greater consistency across UI components

• Faster workflows for design and engineering teams

The new structure gives the Dice Design System a stronger foundation that supports long-term scalability and a more unified product experience.

Structure

Designing a Unified Input Text Field for the Dice Design System

The Input Text Field is one of the most frequently used components across our products—yet it was also one of the most inconsistent. Different brands, legacy patterns, and ad-hoc design decisions had created a fragmented experience that made implementation slow and user interactions unpredictable.

To solve this, I led the redesign of the Input Text Field within the Dice Design System.
The goal was simple: create a single, scalable, and accessible component that works across all brands, use cases, and platforms.

The work ranged from auditing existing patterns, defining semantic tokens, exploring variations and states, and collaborating closely with developers to ensure production-ready clarity.

The following screens walk through the evolution of this component—from initial analysis to token architecture, design rationale, and the final cross-brand implementation.

The Input Text Field is one of the most frequently used components across our products—yet it was also one of the most inconsistent. Different brands, legacy patterns, and ad-hoc design decisions had created a fragmented experience that made implementation slow and user interactions unpredictable.

To solve this, I led the redesign of the Input Text Field within the Dice Design System.
The goal was simple: create a single, scalable, and accessible component that works across all brands, use cases, and platforms.

The work ranged from auditing existing patterns, defining semantic tokens, exploring variations and states, and collaborating closely with developers to ensure production-ready clarity.

The following screens walk through the evolution of this component—from initial analysis to token architecture, design rationale, and the final cross-brand implementation.

Structure

Dice Design System — Education

Design systems only thrive when the people using them understand not just what to do, but why it matters. To support consistent adoption across teams, I created and led the Dice Design System Education Sessions—a structured learning program designed to empower designers, developers, and product partners to build with clarity and confidence.

This initiative transforms the design system from a static library into a shared language. Each session breaks down complex concepts into practical, actionable guidance—from multi-brand foundations and component anatomy to version control, governance, and real-world implementation.

The goal wasn’t only to teach the system, but to strengthen collaboration, reduce inconsistencies, and elevate the quality of every experience built at scale.