Designing a UI system to power a casino game studio’s games

Designing a UI system to power a casino game studio’s games


🗓 Completed in Q4 2021


🏢 Company overview

MrQ is a UK based online casino acquiring 10,000 new depositing customers month on month at the time of writing.

The company owns its own game studio - Goosicorn. In Q4 2021 I was tasked to design a single game UI system to power all of Goosicorn's games.

👥 Team & responsibilities


  • 1 Game developer
  • Product designer (myself 🙂)


  • Competitor analysis research
  • Interaction design
  • UI design
  • Prototyping
  • Design language
  • User testing and reporting
  • Development speccing

🎯 Objectives

A single game UI system to power all Goosicorn games

Goosicorn games share a pool of features and vary for the most part in their theme and art direction. A single game UI system would remove the necessity for game artists to create UI’s for each game. This in turn would reduce lead times and also keep games familiar to users.

A UI solution that accommodates users on any device

Our data suggested people used a multitude of devices to play. Catering for all screens was a must in order to provide a competitive experience.

A solution that blends visually into each game

The game UI had to adapt to look like a part of each game in question, rather than a generic and detached UI applied on top. This would ensure a more immersive experience.

A solution that’s technically easy to configure

Reducing game art lead times would be pointless if lead times would be increased elsewhere. The system had to be designed to be quick to implement on each game.

📚 Researching what constitutes a game UI

Approximately 10 games were researched.
Approximately 10 games were researched.

I kick started my journey by researching what constitutes a game UI. I played around 10 games and complied a list of views and functions they shared in common. I later ran the list of views by the team in order for us to align on what should be in scope.

Game intro

Opening sequence to the game while it loads

Bet amount
Allows user to select a bet amount for each spin
Sound control
Allows user to turn sound on and off
Game rules
Runs through game features and possible ways to win
Play game
Allows user to start playing game

Heads up display (HUD)

A persistent bar throughout the game with frequently used controls

Spin button
Triggers the next round of play
Quick spin
Removes animations from each round of play
Allows user to play game rounds hands-off
Main menu
Reveals game rules, pay table, play history and option to leave game
Sound control
Allows user to turn sound on and off
Indicates funds in user's account
Bet amount
Allows user to select a bet amount for each spin and indicates the current amount
Win amount
Indicates total winnings

Game menu

A menu with extensive information about the game in question

Game rules
Runs through game features and possible ways to win
Pay table
Runs through all game symbols and winning combinations
Play history
Reveals ID, time stamp, bet amount, amount won and balance for each spin
leave game
Allows user to exit the game


Modals triggered on events were users cannot continue playing

Connection lost
Triggered when internet connection is lost
Out of funds
Triggered when the user runs out of funds to play with
Session expired
Triggered when no activity is detected for a while

🖥 Researching commonly used screen resolutions

Unlike most digital experiences were contents may be scrolled, casino slots must display everything within a single view. To find out what space users had at their disposal, I pulled a 'Screen Resolution' report from Google Analytics.

Popular screen resolutions taken from Google Analytics
Popular screen resolutions taken from Google Analytics

🕹 Beginning to design were users would begin playing

Slot machines feature a bar (normally at the bottom of the screen) with all of the main controls - this is called a ‘heads up display’ or a ‘HUD’. Since the HUD is users’ main point of interaction, it made sense to begin designing from there.

I began by fleshing out rough HUD designs for mobile and desktop. What I wanted to explore was how the HUD might:

  1. Adapt to devices to cater for different modes of interaction?
  2. Adapt to devices to make the best use of screen space?
  3. Remain recognisable to users across devices.

A day later over a Slack Huddle with the game developer, we were able to assemble my prototype in code with breakpoints based on the screen resolution report. The prototype used the dimensions below as breakpoint indicators:

Width in px
Break point
320 - 567
Mobile - portrait
568 - 926
Mobile - landscape
927 upwards

Here's how the prototype looked:

Above: HUD adapting across mobile-portrait, mobile-landscape and desktop.

✍️ Designing the game UI views

By this point the HUD was ‘good enough’. It was time to consider all other points of interaction and figure how everything would tie in together.

This portion of the process involved designing views such as the games rules page, pay tables, autoplay settings menus, modals and more.

Throughout this portion of the process, my challenges were to:

  1. Be mindful of user mental models and industry standards.
  2. Ensure a familiar UI for users who played on multiple devices.
  3. Ensure great ergonomics with comfortable tap targets.
  4. Ensure that contents scaled well across resolutions for great accessibility.

I decided to tackle mobile first given that 90% of users played on that device and that space was most scarce there. Once mobile was covered, I adapted the design to tablet and desktop.

👀 A closer look at some design differences across breakpoints

The HUD and overlays were the two main aspects of the game UI which differed the most across breakpoints.

Differences in the HUD

HUD: Mobile-portrait

The HUD was designed to allow users to reach all main controls using one thumb.

HUD: Mobile-portrait

HUD: Mobile-landscape

The HUD was adjusted so that users wouldn't need to make big thumb stretches, instead they'd be able to use both thumbs on either side of the screen to operate the game.

HUD: Mobile-landscape

HUD: Tablet-portrait

Generally speaking, users hold tablets in this orientation with two hands, with thumbs located approximately in the mid section of the screen. Although splitting the HUD to have half to the left and half to the right sounded like an option, it was a terrible idea.

Imagine desktop users resizing their browser to a small size and hitting this breakpoint, and having the HUD split in two. This would have been awkward to view and use with a mouse cursor. The safest solution was therefore one that would be comfortable to use with thumbs or a cursor.

HUD: Tablet
HUD: Tablet-portrait

HUD: Tablet-landscape

Similar to tablet-portrait the HUD was designed to be operated with two thumbs and work equally well for desktop users. Another reason for keeping the design the same was so users could rotate the tablet and still enjoy a familiar UI.

HUD: Tablet
HUD: Tablet-landscape

HUD: Desktop

On desktop, information and controls are easily lost when stretched across screens. For this reason, and also because users wouldn't need controls sitting under their thumbs, a new solution was designed featuring a compact HUD pinned to the centre of the screen.

An added benefit of this solutions was that of leaving more room for game art.

HUD: Desktop

Differences in overlays

Overlays: Mobile-portrait

Overlays were designed to take over the screen and scale vertically depending on the amount of content present. All actions inside overlays were placed at the bottom making them easy to reach.

Upon accessing an overlay, the HUD would remain visible to allow users to navigate, however the spin button was hidden as it makes little sense to play a game while it’s hidden.

Overlays: Mobile-portrait

Overlays: Mobile-landscape

In this orientation, actions on top of overlays were moved to the sides of the screen for easy access. The content container was widened to avoid the need for scrolling.

Overlays: Mobile-landscape

Overlays: Tablet-portrait

Tablet-portrait posed the same challenges faced with the HUD. Keeping that in mind, I went with the following solution which was designed to be operated with two thumbs but which would work equally well for desktop users hitting this breakpoint.

Overlays: Tablet
Overlays: Tablet-portrait

Overlays: Tablet-landscape

Tablet-landscape completely overlapped with tablet-portrait in terms of user needs and design challenges. For this reason the design was kept the same.

Overlays: Tablet
Overlays: Tablet-landscape

Overlays: Desktop

On desktop, screen space is more abundant and covering up an entire game merely to display a few items makes little sense. Therefore, one of the main differences in the desktop design is that overlays were designed to remain contained.

Overlays: Desktop

🧩 Building a design language to facilitate exploration and make the UI ‘theme-able’

The need for a design language came about for a few reasons:

  1. Facilitate design exploration.
  2. Think about how UI components would be themed to blend into different games.
  3. Have a space to communicate component-specific updates.
  4. Keep the game UI easy for designers and developers to maintain.

Facilitating design exploration

By assembling a basic design language, I was able to make as many design explorations and updates as necessary within the allocated time frame. Each exploration contributed to making the language more robust and further reduced lead times.

Making the UI 'theme-able'

The solution I designed proposed configuring 2 colours for each game. These colours would theme the entire game UI so that it felt like a part of the game in question.

Accent colour

An accent colour would be picked from the game’s art and would be used to colour the main controls, as well as and controls in their selected state.

Background colour

This would also be picked from the game’s art and would be used to colour menu bars, overlay sheets and modal curtains primarily.


White would be the default colour used across all games for text, iconography, action backplates and table zebra stripes primarily.

How the colour system themed the UI

Picking an accent and background colour for each game produced the following results.




🔭 Observing users play

Instead of testing a click through prototype, I had users play through a real slot made by our competitors, which shared many fundamental similarities with my design. I figured that this way I could test something that was fully functional and as a result, observe nuances in user behaviour. My goal was to learn what the competition did right and where they fell short, and then proceed accordingly.

User testing key findings

Here are just a few key findings that impacted some areas that were within the scope of this project:

  • 5/5 users didn't understand how to begin playing after landing inside a slot.
  • 5/5 users missed the spin button and didn't know they need to click it to play.
  • 5/5 users thought the spin button was a 'refresh game' button.

User struggles to figure out how to play slot machine

User testing documentation

Find the full test documentation and video clips below 👇

Inexperienced users making sense of slots - an observational study

⚡️Actioning user test findings

The HUD before user testing

The spin button was clearly confusing users with its misleading iconography, which resembled a ‘refresh’ icon. Moreover, the metaphors for quick spin and auto play were so metaphorically detached from each other that the three functions didn’t help explain one another. This was ironic given that they would all in fact be different modes of the same thing - spinning the reels.

The HUD icons
The HUD icons before user testing

The HUD after user testing

To address the issue, I explored iconography for the ‘spin’ button that might be more universally understandable. I decided to begin with this icon as it would be the main ‘call to action’ once users jumped into a game. After some back and forth I decided to go with what looks like a ‘play’ icon.

One advantage of using a ‘play’ icon is its wide spread use. Another advantage is that ‘play’ icons are normally accompanied by ‘pause’, ‘stop’, ‘fast-forward’ icons and the like, all of which are well known metaphors and therefore great candidates to fix up the - iconic mess 😜

The HUD icons
The HUD icons after user testing

🏁 Final designs

Wrapping up all of the above, here are the final designs for each view on each device:

💬 Let's get in touch

(+356) 7920 0774