Back to homeI led the Design approach for XSITE, GiG’s new casino platform, replacing a legacy product with a more consistent, scalable and configurable foundation.
The challenge
WAND had supported GiG’s casino business for years, but as the product grew, several connected problems became increasingly difficult to solve within its existing foundations.
Over time, we identified and redesigned inconsistencies across pages, components and interaction patterns. However, limited Development resources meant that not all of those improvements could be implemented in WAND.
As the product continued to evolve, some inconsistencies therefore had to remain in the live platform.
New features and requirements had been added over several years to foundations that were not designed for the scale the product eventually reached.
Extending the platform while maintaining consistent patterns and behaviour was becoming increasingly difficult.
The platform had technical and maintenance constraints, while its original design foundations were no longer suited to the complexity of a growing multi-brand product.
I had advocated for improving or rebuilding WAND for years. When GiG decided to create XSITE, we finally had the opportunity to address those problems at the foundation instead of continuing to work around them.
My role
I joined the initial XSITE discussions with a Product brief in place. My role was to define how Design would approach the rebuild and lead it through to an implementation-ready solution.
I set the Design direction, reviewed the team’s work, challenged Product solutions when needed and worked with Engineering on technical constraints early.
I structured the Design work in Jira, linking Design Epics to Development Epics for a shared view of progress, and presented to directors weekly.
The approach
XSITE wasn’t approached as a collection of new screens. We needed to define how the product should work while creating foundations that could support different brands, new requirements and future product verticals.
Our overall process followed a simple product design cycle:
Product and Engineering were involved throughout the process. Proposals were reviewed against product requirements and technical feasibility before they became part of the platform or Design System.
32+Casino products in our reference set
We maintained a reference set of more than 32 casino products and expanded our research depending on the problem we were solving.
This covered areas such as navigation, search, game recommendation engines, promotions, bonuses, Cashier, filters, gamification and many other product patterns across the casino experience.
One designer was particularly focused on competitive and market research, allowing us to explore individual areas in depth rather than relying on a single general competitor analysis.
The goal wasn’t to copy existing products. We used the research to understand conventions, compare alternative approaches and inform the options we explored for XSITE.
combine a Top bar and a Sidebar.
use a dedicated Casino / Sports switcher.
place Search in the Top bar.
Mobile represented most of the usage across operators, so we solved flows mobile-first and defined their desktop behaviour in parallel: complete flows with their alternative states and edge cases, not isolated screens. The same foundations also shaped GiG’s mobile app, adding native Android and iOS components where each platform needed them.
The architecture of the Design work itself also needed to change.
Instead of keeping the entire product in one Figma file, we separated XSITE into two connected sources.
This solved the memory limitations we had experienced with larger Figma files and allowed both sides of the product to keep growing independently.
The component catalogue could continue expanding without competing with increasingly complex product flows. At the same time, the product architecture could accommodate additional verticals, such as Bingo or Lottery, without returning to the same scalability problems.
It also gave the team a clearer separation between system definition and product implementation.
Product decisions
Rebuilding the platform gave us the opportunity to question existing patterns and proposed solutions before they became part of the new foundation.
01 · Navigation
Navigation was one of the areas we researched most extensively.
We compared how different products structured primary navigation, mobile navigation and movement between product verticals before exploring alternatives for XSITE.
WAND supported two independent navigation models. For XSITE, we moved towards a unified structure combining a Top Bar + Sidebar, creating one navigation foundation for the platform.
02 · Casino + Sportsbook
A key question was how users would move between Casino and Sportsbook. We explored a sub-navigation, but it lacked space and clarity on mobile.
We aligned with the Sportsbook team to put Casino in their bottom navigation, and designed a Product Switcher for the sidebar that could host future verticals too.
03 · Challenging Product requirements
Product initially proposed opening the Cashier in a modal. Design challenged the solution and we aligned on integrating it into the right-side panel instead.
Similarly, an initial proposal to display all bonuses simultaneously evolved into a dropdown solution after Design review.
My role was to make sure important interaction decisions were questioned and discussed before becoming part of the platform.
White-label scalability
XSITE needed to support different casino operators without turning every new brand into a separate product.
That meant designing for three things at the same time.
We built the Design System around reusable components, documented behaviour and variables that could adapt the product to different brand configurations.
The same underlying system could therefore produce casinos with different visual identities without changing the product foundation underneath them.
Colour logic was the heart of it. We rebuilt it from primitives to semantic tokens, so any brand worked in light and dark mode.
Different casinos, one system underneath.
surface
background
background / primary
Design ↔ Development
A scalable white-label system also needed a better way to move configuration from Design into Development.
We built our own Figma plugin to export variables and configuration as JSON, ready for Development.
Standard brand setups no longer had to be translated by hand; only client-specific requests needed extra work.
The plugin wasn’t the point. Turning a recurring handoff problem into a scalable workflow was.
Documentation
Documentation was built into the system rather than added at the end.
Components included their behaviour, variants, states and intended use, giving Development a reference they could consult directly in Figma.
This made documentation part of the implementation workflow and helped keep the decisions made during Design visible when components moved into Development.
Keeping teams aligned
I kept XSITE moving across Design, Product and Engineering without losing sight of the bigger picture.
Design Epics in Jira, linked to their Development counterparts, made dependencies and progress visible across both disciplines. From that shared view I planned and reviewed the team’s work, and checked technical feasibility with Engineering before approval.
I worked closely with the Product Owner, Software Engineering Manager and Head of Frontend & Mobile, while weekly director reviews kept key decisions visible beyond the product team.
Where I left the project
By the time I left GiG, the core XSITE experience and the foundations needed to build it had been defined.
By the time I left, most of XSITE was already built in code. What we didn’t get to do was test it with real users, so there are no post-launch metrics to share.
Behind the work
Due to confidentiality and intellectual property restrictions, I can’t share XSITE’s full Design System and product documentation publicly.
I’d be happy to walk you through its Figma architecture, components, variables, documentation and key product decisions in an interview, and answer any questions you may have.
