🗓 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
- Design language
- User testing and reporting
- Development speccing
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
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.
Opening sequence to the game while it loads
Allows user to select a bet amount for each spin
Allows user to turn sound on and off
Runs through game features and possible ways to win
Allows user to start playing game
Heads up display (HUD)
A persistent bar throughout the game with frequently used controls
Triggers the next round of play
Removes animations from each round of play
Allows user to play game rounds hands-off
Reveals game rules, pay table, play history and option to leave game
Allows user to turn sound on and off
Indicates funds in user's account
Allows user to select a bet amount for each spin and indicates the current amount
Indicates total winnings
A menu with extensive information about the game in question
Runs through game features and possible ways to win
Runs through all game symbols and winning combinations
Reveals ID, time stamp, bet amount, amount won and balance for each spin
Allows user to exit the game
Modals triggered on events were users cannot continue playing
Triggered when internet connection is lost
Out of funds
Triggered when the user runs out of funds to play with
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.
🕹 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:
- Adapt to devices to cater for different modes of interaction?
- Adapt to devices to make the best use of screen space?
- 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
320 - 567
Mobile - portrait
568 - 926
Mobile - landscape
Here's how the prototype looked:
✍️ 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:
- Be mindful of user mental models and industry standards.
- Ensure a familiar UI for users who played on multiple devices.
- Ensure great ergonomics with comfortable tap targets.
- 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
The HUD was designed to allow users to reach all main controls using one thumb.
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.
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.
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.
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.
Differences in overlays
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.
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.
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.
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.
🧩 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:
- Facilitate design exploration.
- Think about how UI components would be themed to blend into different games.
- Have a space to communicate component-specific updates.
- 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.
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.
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 testing documentation
Find the full test documentation and video clips below 👇
⚡️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 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 😜
🏁 Final designs
Wrapping up all of the above, here are the final designs for each view on each device: