🗓 Completed in Q4 2021

Contents

🏢 Company overview

👥 Team & responsibilities

🎯 Objectives

📚 Researching what constitutes a game UI

🖥 Researching commonly used screen resolutions

🕹 Beginning to design were users would begin playing

✍️ Designing the game UI views

👀 A closer look at some design differences across breakpoints

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

🔭 Observing users play

⚡️Actioning user test findings

🏁 Final designs

🏢 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

Team

• 1 Game developer
• Product designer (myself 🙂)

Responsibilities

• 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

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

Heads up display (HUD)

A persistent bar throughout the game with frequently used controls

Game menu

A menu with extensive information about the game in question

Modals

Modals triggered on events were users cannot continue playing

🖥 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:

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:

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:

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-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: 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-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: 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.

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-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: 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-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: 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.

🧩 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

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:

💬 Let's get in touch