FUSION DESIGN SYSTEM
TL;DR / Summary.
Fusion is a multi-brand, multi-product Design System built from scratch by a two-person core team, reaching production maturity in under two years, whilst simultaneously supporting the PokerStars Network's most strategically significant partner projects.
What started as a restart of a stalled initiative became the central source of truth for PokerStars products across 6 brands, comprising 38 core components, 12 Snowflake components, 7 content patterns, 10 recipes, 457 design tokens and Figma variables, 25 typography styles, 213 icons, and 10 documented processes, with full Storybook integration for design-to-development handoff.
The impact of Fusion's adoption was immediate and measurable. A task that previously took product teams an average of 3 sprints to complete manually, updating the Primary Button text colour to meet accessibility standards, was resolved, developed, and released to production in 1-2 days following Fusion's adoption by the first team. Fusion has since been used as the source of truth across the PokerStars Network by Sisal, Snai, FanDuel, Betfair, Pragmatic, Salesforce, and Jungalee, with Paddy Power and Sky Bet and Gaming soon to follow. Over a single year, Fusion recorded over 38,000 component insertions, 45,000 typography insertions, and 318,000 variable insertions in Poker alone, spanning ideation, exploration, and final designs for developer handover, demonstrating deep, sustained adoption across the organisation.
Through rigorous tokenisation, scalable component architecture, and a governance model flexible enough to serve multiple product teams without sacrificing consistency, Fusion enabled faster design delivery, stronger brand alignment, and seamless partner theming across the PokerStars Network. In recognition of my leadership across Fusion and the wider Network initiatives, I was promoted from Senior UI Designer to Principal Designer.
The Brief.
Following the arrival of a new Director of Design, the Design System initiative was revisited. Aware of my leadership on the PokerStars.it Design Style Guide, I was appointed as lead designer to restart and drive it forward.
I partnered with a Mid-weight UI Designer to establish the initial foundations, supported by a wider team including developers and a Senior Product Owner. From the outset, I focused on building effective collaboration and cadence; introducing weekly sessions that evolved into daily stand-ups, presenting in Design Show and Tells that led to company-wide Town Hall meetings, and developing roadmaps, processes, and workshops to structure and govern the work both internally and with partner brands.
The Design System, later named Fusion, was conceived as the central source of truth for design attributes including colour, typography, dimensions, responsive grids, and UI components. These attributes would be encapsulated as design tokens, used to construct a library of core components across PokerStars' products, including Poker, Casino, Sports, Marketing, and Player Accounts. The initial focus was the web platform, with plans to extend support to native desktop and mobile applications as adoption grew. Alongside components, Fusion would provide documentation and prototypes to define behaviour and usage for design, development, and product teams.
Research and Foundations.
Operating within an Agile framework, we adopted three-week sprints to manage delivery. Our initial focus was research into Design System best practices, dedicating significant time to reviewing articles, videos, and established systems from organisations such as Google, Atlassian, Uber, and Shopify.
We also drew on the expertise of partner companies, collaborating with designers from BetFair, FanDuel, Tombola, and Sisal, to understand proven approaches, common pitfalls, and practical insights, which directly informed the development of our own Design System.
Consolidation of Design Style Guide components on a FigJam file
In-depth evaluation and considerations of components
Component Mapping.
Using the Sisal Design Style Guide as a precursor to the Design System, we reviewed existing components to identify those that would form the library of Fusion's core components. We consolidated shared attributes such as colours, sizes, spacing, borders, radii, and other reusable properties, and categorised the components using Brad Frost's Atomic Design methodology; Atoms, Molecules, and Organisms, as a guiding principle.
Once our findings were communicated to and agreed upon by the wider Design System team, we set our sights on building the Atoms first, followed by Molecules, to ensure a solid and scalable foundation.
Consolidated list of Atomic components for inclusion in Fusion
Token Architecture and Strategy.
Before building the first components, we aligned on a token strategy to ensure Fusion would be consistent, scalable, maintainable, and accessible from the ground up. Following extensive research across existing design systems, partner brand insights, and requirements gathering, we defined three token types: Global, Alias, and Component. Global tokens covered colours, typography, gradients, opacity, and dimensions. Alias tokens abstracted reusable values such as spacing, sizing, and borders, applied as broadly as possible to maximise scalability. Component tokens were reserved for design attributes specific to individual components. After building the first components, we identified opportunities to refine the token structure and introduced a second version, which remains in use today.
Accessibility was embedded as a core principle throughout, rather than treated as an afterthought. We defined standards aligned with WCAG guidelines, covering contrast ratios, typography, interaction states, and design patterns, ensuring Fusion components were usable by the widest possible range of users regardless of ability or context. Clear visual signifiers were introduced for both informational and non-informational elements, and interaction states were designed with keyboard navigation and assistive technologies in mind. This commitment to inclusive design permeated every component, creating a consistent and equitable experience across all of Fusion's products and partner brands. Compliance was validated by developers using accessibility tooling integrated into Storybook, creating a shared responsibility between design and development that reinforced Fusion's quality standards at every stage of delivery.
Design token initial research
Using Sam Gordashko's token building template
Design token definitions
Centralised spreadsheet to consolidate design token application
Theming and Brand Flexibility.
Theming was a foundational consideration from the outset. Components were designed to support both Light and Dark modes from day one, ensuring adoption across products with differing colour-mode requirements whilst maintaining consistent, accessible colour scales throughout.
As Fusion evolved to support the PokerStars Network, brand-specific themes were introduced within the token library, beginning with Sisal and later extending to Snai, BetFair, and beyond. Each theme is built through a structured, version-controlled process, evaluated, reviewed, and validated before being published to Fusion's component libraries, ensuring every new theme meets the same quality and consistency standards as the core system.
This approach means that adding a new partner theme is a structured, repeatable process rather than a bespoke effort each time. What previously required weeks of manual design work can now be achieved in days, enabling significantly faster partner onboarding across the Network. For designers, the experience is seamless; switching between PokerStars, Sisal, Snai, BetFair, and other brand themes in Figma is a single interaction, with all components, interaction states, and documentation updating instantly to reflect the active theme.
The result is a system that scales with the business. As the PokerStars Network continues to grow, new partner themes can be onboarded quickly, consistently, and without compromising the integrity of the core system.
Theming research and process considerations
Storybook: highlighting new token structure for fill and border colours
Date Picker component: different interaction states and theming
Date Picker component documentation, outlining behaviour and usage
Button component: different interaction states and theming
Component Creation and Craft.
As the component library grew, I formalised a clear and repeatable component creation process, with UX designers involved at key stages to ensure usability and alignment with industry standards.
The process defined end-to-end workflows covering Jira ticket progression, the use of Figma branching to protect the main library from exploratory work, and clear decision paths for when new design tokens were required versus reuse of existing ones. It extended to prototyping, documentation, and structured UI reviews to validate parity between design and development, verify token usage, and ensure consistency before components were published. Progress was communicated regularly to the wider Customer Experience Design Team, product teams, and the business throughout.
When building components, I focused on best practices to create simple, robust, and scalable solutions, drawing on advanced Figma training and years of hands-on experience. This meant designing components that were easy to use correctly, hard to use incorrectly, and flexible enough to serve multiple products, device contexts, and platforms without requiring custom overrides.
End-to-end component building process
UX testing: Fusion components in a cash deposit user journey
Date Picker: usage guide for designers
Governance and Operations.
As Fusion matured, additional processes were defined to support component editing, theming, and day-to-day design team workflows, maintained as living documents and evolving in line with changing requirements and broader organisational priorities. Governance extended beyond documentation; as the custodian of Fusion, I actively reviewed product designers' work, answered questions, and referred teams to the relevant processes to ensure consistent and correct implementation. I collaborated closely with developers, Senior Product Owners, and Directors to understand challenges, resolve problems, and adapt Fusion accordingly, ensuring the system remained relevant, practical, and aligned with the evolving needs of the business.
I introduced a 'Proposed Amendments' process to formally capture issues and improvement opportunities relating to tokens, components, or accessibility, identified through design work, collaboration, or feedback from stakeholders, designers, and developers. Each amendment was reviewed to define minimum requirements, assess impact, and prioritised appropriately with the development team and Senior Product Owner, before being estimated and scheduled into sprint cycles.
Increasing interest from designers, developers, product teams, and leadership prompted the creation of an Onboarding File, documenting everything a designer needed to understand and contribute to Fusion; from Atomic Design principles and Figma setup through to components, tokens, themes, processes, and learning resources. Over time it expanded to include component versioning, the Pattern Library, and Snowflake components.
Looking ahead, we are exploring the integration of AI tooling to further streamline Fusion's workflows and accelerate design delivery. Early steps are already underway, including the use of Figma's AI tool, Figma Make, to assist in the creation of component documentation, reducing manual effort and enabling the team to focus on higher-value design and governance work. As AI capabilities within design tools continue to evolve, Fusion is well positioned to adopt and benefit from them without compromising the quality and consistency standards the system was built upon.
Process: exporting tokens to Figma styles and variables
Process: updating core components in conjunction with Snowflakes
Example of a 'Proposed Amendment' for the Chips component.
Onboarding File: slide showcasing variables and styles information
Icon Library.
As the component library grew, it became necessary to introduce a cohesive icon set to support branding and provide clearer visual signifiers within components. The Icon Audit I conducted shortly after joining the company helped to consolidate the disparate icon sets used across the different product teams. This audit formed the foundation for a centralised Icon Library within the Design System’s Figma workspace, established as the single source of truth for product teams.
Icons were redesigned for scalability across sizes and stroke weights, with naming conventions standardised. I delegated this work to a designer within the wider Customer Experience Design Team, who later produced an Icon Creation Guide to support the consistent creation of future icons.
I built an Icon Button component to consume icons directly from the library to be reused by other components as required. The component supported multiple sizes, interaction states, and theming for Light and Dark modes, as well as brand-specific colour application for PokerStars and partner brands.
A formal Icon Creation process was introduced to ensure consistency in design, naming, and implementation. This process detailed how new icons could be requested, the design constraints (including keylines, sizes, and interaction states), approval responsibilities, and the location of final icon assets. This has seen a reduction in the number of ad-hoc requests received by the team, and an increase of Jira tickets created.
Icon Library: icons and change-log
Icon Library: icon creation guidelines
PokerStars Network.
As the initiative progressed, the Design System became a key enabler of the company’s primary strategic objective, the PokerStars Network, allowing partner companies to host the Poker product on their own platforms and domains.
While broader product implications were considered, it was decided that Fusion would primarily support the flagship Poker product and Marketing, while remaining available as a reference for partner teams building associated products such as Casino, Sports, and Player Accounts.
At the same time, as I led design work across both FanDuel and Sisal projects, Fusion served as a consistent point of reference, ensuring strong alignment with the PokerStars brand and preserving brand integrity through consistent application of design attributes, component usage, design patterns, and information hierarchy.
To enable a successful adoption of Fusion into the flagship Poker product, the Fusion and Poker design teams collaborated closely to align on workflows, expectations, and responsibilities. The initial focus of this transition was the Poker Web Lobbies.
Poker Web Lobbies.
Our cross-team collaboration began with an evaluation of the current Poker Web Lobbies, identifying which Fusion components could replace existing ones. Existing components were categorised into three groups: ‘Use Fusion’, ‘Amend Fusion’, and ‘Create Snowflakes’, allowing us to assess both impact and workload as we entered the Design System’s adoption and governance phase.
This phase marked an unprecedented point for Fusion and Poker. We carefully considered how the Poker product could adopt Fusion while still incorporating unique design nuances and functionalities that differed from core components. Through detailed reviews of each Web Lobby, we established clear design, development, and product plans - identifying accountability for specific areas and confirming who would provide sign-off. I led and facilitated multiple cross-team conversations between Fusion and Poker, aligning design, development and product priorities, fostering clear communication, and defining new collaborative workflows.
We recognised that Poker designers would benefit from some dedicated guidance, and organised an in-person Fusion onboarding workshop. The workshop demonstrated Fusion’s components, processes, and Ways of Working, providing hands-on activities to familiarise the team and ensure smoother implementation. During the workshop, a recurring theme of ‘governance vs. flexibility’ emerged, which provided me with questions to take back to the Fusion team with.
Evaluation of components in an existing web lobby
Comparison of existing lobby design and Fusion component exploration
Onboarding workshop in progress
Snowflakes.
Following the onboarding workshop, the Fusion team explored methods to maintain governance whilst giving product design teams the flexibility to execute their product-specific work effectively.
The solution was the introduction of Snowflake components; specialised, unique components that could not be fulfilled by core components and required modifications. Snowflakes enabled teams to use core components as a baseline, making necessary adaptations for their specific needs whilst retaining ownership and responsibility for their maintenance.
Research into best practices indicated that excessive Snowflakes could be detrimental to Fusion, so we established a clear process to identify when a Snowflake was required, what alternatives could be used, and how it could be promoted to the core library when appropriate. To manage these components, I created the Snowflake Library, inheriting design tokens, core components, styles, and variables from the Foundations Library. Once created, Snowflakes were documented and prototyped in line with the Component Creation process, ensuring consistency and quality standards were maintained across all product-specific adaptations.
Snowflakes research and application considerations
Top left: existing Cash Games design. Top right: Fusion's Table component.
Bottom left: Component evaluation of existing design
Design elements for the new Cash Games Table component
New Cash Games Table design in-situ - Light and Dark themes
Cash Games Table: designer usage guide
Cash Games Table: designer usage guide
Beyond Components: Patterns, Recipes and Templates.
Snowflake components proved effective for enabling product-specific customisation, but we recognised that not every design challenge warranted the creation of a new component. This prompted deeper exploration of the governance versus flexibility challenge, and led to the development of a broader set of governance utilities to complement the core and Snowflake libraries.
The result was a suite of additional solutions, including Design Patterns, a Pattern Library, Recipes, Organisms, and Templates; each designed to address a specific point in the spectrum between rigid governance and total flexibility. Rather than forcing teams to choose between creating a new component or going off-system entirely, these utilities gave designers a structured middle ground; a way to compose consistent, on-brand solutions using existing Fusion foundations without unnecessary overhead.
To support adoption, I defined a clear process outlining when and how each utility should be used, clarifying ownership, accountability, review points, and publishing workflows. This ensured Fusion remained a practical, living system that served the real-world needs of design, development, and product teams, without compromising the consistency and quality standards at its core.
Pattern Library research and exploration into application
Definitions for additional governance utilities, including examples for each
Process: Using Snowflakes across product teams
Component Versioning.
Over the lifecycle of components, updates were periodically required to support evolving team needs, enhance functionality, improve accessibility, and implement Proposed Amendments.
We conducted research into industry best practices for component versioning and applied these learnings to Fusion’s setup. This was supplemented by guidance from design system practitioners at partner brands, whose insights were documented and shared with the Fusion team.
A traffic-light versioning model was introduced: green indicated the current Ready for Dev version, yellow marked components scheduled for deprecation within a defined period (two weeks), and red denoted components that were no longer supported and had been archived.
Clear and consistent communication underpinned this approach, with regular coordination between the Fusion and product design teams to ensure smooth adoption of updates and continued use of the latest component versions in active design work.
Example of component versioning for the Checkbox component
Building a Design System Culture.
From the earliest stages of Fusion to its current iteration, clear and consistent communication has been a priority. I established a culture of transparency, ensuring critical information was shared to provide clear visibility of our progress and direction. This enabled teams to understand Fusion’s impact, align more closely with the design system, raise questions or concerns, and contribute where possible. Given Fusion’s central role across products and teams, regular communication was essential to maintain alignment, encourage feedback, and ensure ideas and perspectives were considered.
Internally, daily stand-ups were used to discuss workflow, review the status of Jira tickets, and surface new information or questions across design and development, including the Senior Product Owner. Within our Agile framework, sprint planning sessions were held to prioritise and plan upcoming work based on team needs. In parallel, dedicated Slack channels enabled ongoing communication and more detailed design-related updates.
Externally, communication channels were equally robust. I hosted regular meetings with product teams to understand upcoming initiatives, surface dependencies, and provide a forum for discussion and clarification. Dedicated Slack channels were also established to keep product designers informed of updates, alongside a monthly, high-level Slack update shared with designers, department heads, the Director of Design, and UX teams.
For the wider business, communication was supported through regularly scheduled Design Newsletters, which included summaries of Fusion updates alongside contributions from other design teams. In addition, Town Hall sessions provided an opportunity to present Fusion updates to a broader audience, raise awareness, answer questions, and strengthen the connection between the design system, product teams, and end users.
What Fusion Became.
Fusion is no longer just a Design System; it's the design backbone of the PokerStars Network. Built from scratch by a two-person core team over 18-20 months, it has reached a level of maturity that now supports the majority of components required to effectively serve PokerStars' flagship products and its growing portfolio of partner brands.
Poker and Marketing teams have been working exclusively within Fusion for over six months. Over the past year, adoption has been reflected in over 38,000 component insertions, 45,000 typography insertions, and 318,000 variable insertions in Poker alone, spanning ideation, exploration, and final designs for developer handover. Fusion has served as the source of truth across the PokerStars Network for Sisal, Snai, FanDuel, Betfair, Pragmatic, Salesforce, and Jungalee, with Paddy Power and Sky Bet and Gaming soon to follow.
Governance is maintained through a consistent suite of branded components, design attributes, and 10 documented processes, providing sufficient flexibility for product teams to create the solutions they need, without compromising consistency, accessibility, or brand integrity. Fusion continues to be actively maintained and evolved, with new components, patterns, and partner themes added as the Network grows.
In parallel with leading Fusion, I successfully led design work across the FanDuel, Sisal, Jungalee, and Salesforce projects, and collaborated closely with BetFair's designers to curate and implement the BetFair theme within Fusion. In recognition of my leadership, organisation, delegation, and communication across these initiatives, my Director of Design supported my promotion from Senior UI Designer to Principal Designer.