A system created for future products so design and engineering could reuse the same foundations, behaviours and production patterns instead of rebuilding similar products from scratch.
Problem
Duplicated design and development effort
Ownership
Led system architecture and delivery
Collaboration
Worked directly with developers & product owners
Applied to
Plinko · Roulette · Mines · Tower
PROBLEM
Before I joined Incentive Games there was no shared design system. Similar products could look and behave differently because each designer was making the same foundational decisions again.
The cost was bigger than visual inconsistency. Developers were repeatedly rebuilding UI structures and interaction patterns that could have been created once and reused. That made delivery slower and created more opportunities for behaviour and implementation to drift.
The product problem
How do we give future games enough flexibility to feel distinct without asking design and engineering to rebuild the same foundations every time?
goals
Standardise what should be consistent. Preserve flexibility where the product needs it.
I did not want a system that forced every game to look identical. The goal was to separate reusable foundations from product-specific composition.
Reuse
Build shared foundations and molecules once.
Flex
Allow organisms such as betting panels to vary by game.
Align
Make Figma and development use the same language.
Foundations
A shared language before shared components.
I created the variables and foundations the rest of the system depended on, including colour, spacing and reusable values. I worked directly with development so naming conventions in Figma matched the language engineers were using in the product.
The system was never intended to be a design-only library. It needed to reduce translation during handoff and make intended behaviour easier to implement consistently.
Making the system usable beyond the design file.
I structured the Figma foundations around the same terminology development used in the product, so components, variables and implementation were describing the same concepts.
That shared language reduced interpretation during handoff. Developers could understand which values, states and patterns were intended to be reusable rather than treating every screen as a one-off specification.
The system therefore acted as more than a UI library: it became a common reference point between design and engineering as new game frameworks were created.
Flow templates
One example was How to Play. Each game needed onboarding, but the old pattern was constrained by the number of steps that could fit on one screen and became harder to read on smaller devices.
I proposed a reusable carousel: one focused visual and explanation at a time, swipe on mobile, arrows on desktop and no fixed limit on the number of steps. I worked closely with the product owner and developer on feasibility. Development confirmed the reusable version was quicker to build than recreating the previous approach for each product.
Old Design
The existing How to Play layout worked on larger screens, but it was difficult to scale. On mobile Safari, the browser controls reduced the available screen space, while longer headings or descriptions could easily break the intended layout. Adding more steps through scrolling would still leave each card dependent on tightly controlled content lengths, making the pattern harder to reuse consistently across different games.
New Design
The new template was designed to scale across different games, devices and content lengths. Teams can quickly update the game logo, add as many onboarding steps as needed and use longer explanatory copy without breaking the layout. The carousel works consistently across small and large screens, while the larger media area gives images, animation and video more space to remain clear and legible on mobile. This made the pattern more flexible, easier to reuse and better suited to future products.
Why this matters
The reusable unit is not always a button. Sometimes it is an interaction pattern or an entire flow.
Production Templates
I also removed repetition outside the product UI.
New launches required families of game-tile and promotional assets in multiple sizes. Rather than rebuild those files manually for every release, I created production templates that made the repeated structure reusable and left only game-specific artwork and copy to change.
Applied to products
The system was built against real products, not in isolation.
I created the variables, foundations and reusable components that the rest of the system depended on, including colour, spacing and shared interaction patterns. I worked directly with development so naming conventions in Figma matched the language engineers were using in the product, reducing ambiguity during handoff.
I then used the same system to design the UX and UI for four different games. Because colour and styling were controlled through variables, each product could be quickly re-themed or white-labelled without rebuilding the underlying experience. This allowed the games to feel visually distinct while continuing to use the same foundations, components and interaction logic.
Building the system alongside real products also meant I could continuously test whether it was flexible enough to support different mechanics and betting experiences, rather than creating a design library that only worked in theory.
How the system evolved across four games
The system became more useful as I applied it to real products. Early on, the focus was establishing shared foundations such as variables, spacing, naming conventions and reusable components. As I moved through the four games, repeated problems exposed opportunities to standardise larger interaction patterns and production workflows as well.
How to Play was a good example. Rather than continuing to adapt a constrained layout for each new game, I turned it into a reusable responsive flow that could support different amounts of content, media and onboarding steps without redesigning the experience each time.
By the later products, I was designing less from a blank canvas and spending more time on the parts of the experience that genuinely needed to be unique to the game.
outcome
A faster path from new-game idea to production framework.
The concrete outcome is that the same system was used to create the framework for four different games, with design and development working from shared naming, spacing, states and reusable patterns.
What Changed?
Future products no longer needed every foundational UI decision to start at zero. The team had reusable building blocks, reusable flows and production templates that could be applied and adapted to the game.
Four
New game frameworks created with the system
One
Shared language between Figma and development
Reusable
Components, flows and production templates
Creating the system demonstrated why reuse was worth changing the existing way of working. I discussed the reusable approach with the Product Owner and developer and this helped move the conversation away from design consistency alone and towards the shared product and engineering benefit: less repeated work, fewer implementation differences and a faster starting point for future games.
Reflection
What I would do differently
If I were establishing the system again, I would formalise its governance earlier.
The initial priority was proving that a shared system could work across genuinely different products. Once that had been demonstrated, I would introduce clearer contribution rules, usage guidance, ownership, versioning and accessibility criteria so the system could scale more easily as more designers and developers contributed to it.
I would also define a small set of measures from the beginning — such as time required to design and build a new game framework, reuse of existing patterns and the number of product-specific exceptions — so the operational value of the system could be measured as clearly as its visual consistency.