• # Design Game Design User Experience Best Practices // Ultimate Guide

UX for Games

After more than 10 years as a Game Designer in very successful companies (Senior Game Designer at Matific, Lead Game Designer at TabTale, Owner at Lookandfeel Games), I had — and still have — the privilege and the opportunity to utilize data from hundreds of millions of users around the world. Now’s my time to share my knowledge with the world.

For a long time, game designers utilized data through playtesting, usability sessions, data, and reports in order to ensure the best experience for their players — and their products. The great thing about working in big game companies is to have a dedicated data-analysis team to analyze the games’ data and tell me their pros and cons, including interesting insights and trends.

## Sorry to disappoint — your idea didn’t work.

To disappoint? Hell no! Thanks for the opportunity to tell me I should rethink my design so I won’t continue to think that I nailed it, while in reality I didn’t. How can I improve otherwise? How can I gain mastery otherwise? Based on data-driven insights, good ideas are being duplicated and leveraged in my next projects, and the ‘trial balloons’ are being adjusted or dropped accordingly. Here’s my best practices bible with lessons learned from +250 games — proven by data to improve your monetization, retention, user experience & engagement.

## UI POSITIONS

Speaking on mobile games, considering that most players are right-handed, the devices have comfort-to-reach area and hard-to-reach area depends on their orientation:

Now take a look at the below examples from various mobile games:

As you can see, in the most comfort-to-reach area,

the best practice is to place interactive elements which can lead to monetization:

Store button

More apps

Users are likely to interact with these elements — unfortunately even by mistake. Those mistakes are what we call a dark-UX, but it’s proven to maximize revenues. Note that for bottom ads, you must include at least 10 pixels margin from the ad to the interactive content in order to follow ad-serving guidelines in most of the platforms.

## SLIDERS

Because the screen’s real-estate is limited, and the content in games is just getting bigger, sliders become a very handy component to expose many options to the users regarding extra content, without the need to navigate away from the main scene.

Here are five examples of different slider designs which offer horizontal or vertical sliding, used in world-selection, shop, landscape categories\items selection, portrait categories\items selection, and avatar customization:

Because the slider’s content expands outside the screen, we need to help the users understand there’s more content inside. Here are the best practices for sliders:

Partly visible items: Make sure that content which expands outside the screen’s border will still be partially visible on screen, so users will understand there’s more of it.

Animate from end to start upon launch: When introducing the slider to the users, either by automatic event or by a user-initiated event, make sure to launch it on its end-of-content, and scroll-reverse automatically to the beginning of its content. If your slider contains lots of content (i.e. 10 steps to scroll from beginning to end), you can just start from “step three” of the slider and then animate scrolling to “step 1”. This will show the users that there’s more content on the other side.

## POP-UPS

Pop-ups are a good game component for delivering abstract and informational messages to users. Here are some useful best-practices:

Associate visible UI with hidden UI via animations: When pop-ups are opened due to user-initiated action on an interactive item\button, animate their launch from the triggering button (i.e. scale up a store-pop-up from the store-button, and scale down the store-pop-up back to the store button upon closing). This way users will associate the pop-ups with their initiators better.

Have a semi-transparent dim background behind popups: Because they often require a user-action, and might be big in size on screen, we should help the users understand that their session is paused, but still reachable. Pop-ups should be seen over a dim background that will allow the users to see a bit of their session behind (the dim background should animate quick fade-in parallel to the pop-up open animation, and fade-out parallel to its closing animation).

Avoid the X: Many pop-ups contain a default design choice of an “X” button to close them. Most users recognize this “X” button as a pattern of an ‘annoying’ content and closing the pop-up instantly. If your pop-up contains valuable content to the users, and you’d like to increase the probability that they’ll read this content, make sure that the “Close” button will be designed as one of the user’s choices and not as an “X” button. Note: Don’t have duplicate options with the same meaning (i.e. both “X” and “Close” in the same pop-up; users will just tap the “X”).

Pro tip #1: Tapping the dim background should close the popup as if tapping “cancel”, unless it’s a store popup — then only closing via “X” will close the store.

Pro tip #2: Popups with rich text (such as intro story popups) should show their “X” or “Continue” button only after 2 seconds delay. This way users will be more likely to read the important content of the pop-up rather then instantly close it.

## USER CHOICES (VIA POP-UPS)

As I mentioned above, lots of pop-ups require user-action as they are offering the users to take a decision. Here are several examples of pop-ups which asks the users how to proceed — do you see a pattern?

As you may see, the rule of thumb here is as follow:

User decisions which are good for your game are placed on the right side of the popup — As a game designer you want your players to confirm a purchase, you want your players to share the game, you want your players to spend in-game currency… etc. :

User decisions which are bad for your game are placed on the left side of the popup —As a game designer, you won’t want your players to quit the game, disconnect, reset progress… etc. :

Although you might think that this is considered as a dark UX, it can actually help the users a lot — you don’t want your users to accidentally reset their progress, do you? Anyhow, the key here is to lead the users to take a decision you want, which is good for your game’s KPIs (IAP, retention, engagement, viral exposure, sharing and so on).

Tip: Associate a button color with its function (negative is red, positive is green, neutral can be blue).

## REWARDED VIDEOS

Rewarded-video ads become an industry standard in the past years, as part of a freemium model in mobile-games, which boost revenue and considered as a “win-win” situation (the users who cooperated with the offering to watch an ad, will receive an actual in-app reward in return).

The best icon to represent rewarded video ads should look like a film clapper board with a play icon on it (we’ve tested lots of different icons and this one worked best).

Here are several examples of rewarded video offering in different mobile games:

As a game designer, you should think carefully what the prize is going to be, how to reward it and for ‘how long’. The main scenarios are:

Permanent — Once the ad is watched, the users receive the prize for an unlimited time (i.e. get an item which is added to their inventory and stays there for good).

Per Session — Once the ad is watched, the users receive the prize and it’s available to be used anytime during their current session. Once quitting the game and getting back on a later time — the prize is not there anymore. This can be helpful in order to increase session time.

Per Scene — Once the ad is watched, the users receive the prize and it’s available to be used only at the current level (i.e. getting a booster, or ‘another try’).

The rewarded video prizes should be significant and not ‘little things’ — otherwise, users won’t want to waste their time on the ad. As a game designer, you should think about what your users will want from your game.

Pro tip: Don’t tell users what reward they’re getting, to make the reward more exciting (motivate their curiosity and surprise — and increase the probability that they will watch the ad).

## DRAGGABLE OBJECTS

An intuitive game mechanic on mobile is ‘dragging an item’,

though many times it can harm the game experience if not done right. When exporting game assets such as PNGs, the design can be very creative, while ‘behind the scenes’ of the device they are all rectangles with some transparent area.

The default anchor points for rectangles are either the top left corner or the exact center. As a game designer, try to demonstrate how the object should be dragged as if dragging it in the real world — where the actual holding point of the item should be positioned for the user:

Default anchors are often outside of the dragged object (top left corner). Even when centered, the dragging won’t make sense to the user most of the time.

Here are important best practices for draggable objects:

Set a custom anchor-point offset on draggable objects so the user’s finger will not hide them: Most of the times the default anchor points will have to be adjusted and get a custom offset so the draggable item will be visible despite the user’s finger on the screen.

The grab area of small draggable items should be larger than their actual canvas size.

The dragged item should be in front of other items when dragged (Z-index wise). In special cases (i.e. inserting an object inside another object) this should be customized.

Use glow or dashed-outline for drop-zone areas. Don’t expect the user to understand immediately where the dragged item should go to. The best case is when having an intuitive ‘drop-zone’ (i.e. dragging a food item to a mouth) — in this case, no need to highlight the mouth, but just animate it ‘open wide’ when the food item is dragged. Users will know what to do.

Pro tip: In general, pulling is easier than pushing (i.e., for right-handed users, dragging from left to right is easier than dragging from right to left ). If your game is designed for kids, try to have pulling over pushing by design.

## RATE US DIALOGS

Lots of game designers are using the ‘rate us’ dialog too soon — calling the users to rate their experience before they actually formed an opinion about your game. When done right, using the ‘rate us’ dialog helps to achieve better ratings on the stores and helps organic promotion. So how to do it? The ‘rate us’ dialog should meet the user on the following scenarios:

After a big achievement or big satisfaction point (i.e. defeating a boss, completing a world, winning a major challenge, etc.).

After accumulating small satisfaction points (i.e. win 10 badges).

To maximize the probability that users will rate your game, the ‘rate us’ dialog should be designed as follow:

Have a relevant presenter, looking at the user.

”Rate button” should be with positive color (i.e. green) and more noticeable than the ‘later’ button. Also, if you followed the best practices mentioned in the ‘user decisions’ section above, you should know by now that its position should be on the right side.

Tip: Never use “5 stars” reference — it’s against Apple’s guidelines.

## STORE DIALOG

The design of your store dialog is critical to your selling. Many times the store dialog will offer some ‘full version’ deal along with some other in-app purchase options. Here are a few examples:

To maximize the purchases of the full version, you can follow these guidelines:

Make sure that the ‘full version’ button includes a presenter from the game, with noticeable eyes (preferably looking at the user).

The ‘full version’ button should be stronger in color, larger and more attractive rather than the other in-app offerings.

Add a ‘breathe’ animation to the full-version button(scaling up to 104%, then back to 100% two times, then stop for another 6 seconds before repeating the animation).

The title of the full-version button should be bigger than its inline content.

Have a clear “Discount” or “Best Deal” ribbon on the full-version button.

Pro tip: If you are selling content such as extra levels, worlds, etc.., allow the users to enter the locked content screen and only then open the store dialog with a dim background behind it (rather than opening the store dialog ‘outside’ when clicking the locked content on the level-selection screen).

## WRAP-UP

I’m glad to take the opportunity to share my knowledge with this community and I hope that this info will provide value to lots of game designers, game developers, and product owners. This best practices bible for game design UX is formed from big data (and I mean — BIG — TabTale alone has more than 2 billion downloads and ranked among the top 10 publishers in the world several years in a row), but I also watched it executed for real with more than 500 users (at Matific I have the privilege to watch more than 500 users play my games in large scale events by the Israeli Ministry of Education where kids from all around the country are competing in a yearly Math-Olympics session). One thing I’d like you to remember along the way is that these are not ‘rules’, these are best practices. I recommend you to adopt them in order to get a better starting point, but don’t expect them to magically turn your game into the next hit. Now you are ready!

Senior Game Designer at Matific (2016 to date)

Lead Game Designer at TabTale (2013–2016)

Owner at Lookandfeel Games (est. 2009)

Lecturer at Mentor College (Metagame & Game Design course).

Report Article

## User Feedback

I'm curious, are there any metrics on how mobile players actually hold their phones? For instance, I am right handed but always hold my phone in my left hand and use my right index finger to play. This is irrespective of screen size.Is it really more common for players to play one-handed and use their thumb?

##### Share on other sites
On 10/4/2019 at 7:00 PM, JoeKlemmer said:

I'm curious, are there any metrics on how mobile players actually hold their phones? For instance, I am right handed but always hold my phone in my left hand and use my right index finger to play. This is irrespective of screen size.Is it really more common for players to play one-handed and use their thumb?

Hi Joe,

For mobile casual games, most of the users are playing with the same holding hand. There are always exceptions. We gathered most of the info from observations, and as written we watched thousands of users. Also, not all of the games are portrait orientation, many are landscape, and then users are using two hands to hold the phone but still the bottom area of the screen is the 'easy-to-reach' one.

##### Share on other sites
On 10/6/2019 at 6:23 AM, Lookandfeel Games said:

For mobile casual games, most of the users are playing with the same holding hand. There are always exceptions. We gathered most of the info from observations, and as written we watched thousands of users. Also, not all of the games are portrait orientation, many are landscape, and then users are using two hands to hold the phone but still the bottom area of the screen is the 'easy-to-reach' one.

Thanks for the response.  I agree that the usage area breakout you have is probably the best layout for usability, regardless of how you hold your phone.

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 0
• 0
• 4
• 3

• 16
• 11
• 23
• 42
• 75
• ### Similar Content

• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?

• The full interview with Pixelbite was originally published on the LocalizeDirect's site.
The creators of the “amazingly animated” Space Marshals, Reckless Racing, and Xenowerk, Swedish studio Pixelbite is launching its tactical mobile strategy game Xenowerk Tactics today. LocalizeDirect briefly talked to Pixelbite co-founders Mattias Olsson and Anders Blom about their new game, game localization secrets, and their ad-hoc game testing on the couch.
LocalizeDirect: Tell us a bit about your new game - Xenowerk Tactics.
Anders: It’s sort of a mix between our previous games Space Marshals and Xenowerk. It’s built on the story of the Xenowerk but Xenowerk was more of a shooting and action game, this one is a bit more strategic and tactical. There is a strategy element where you manage a basecamp, upgrade and recruit new operatives, and then you send then into the field, and in the field it becomes a tactical game for you.
What inspired you?
Mattias: It’s a mix of many games. We were inspired by games like Darkest Dungeon and XCOM, especially for the base management and recruitment parts. If we could get the player to care for the recruits the same way we did when playing those games it would be great. To hopefully achieve this we added unique traits and mutations to make each recruit feel more unique and valuable. For the combat side of things, we took inspiration from various RTS games and old-school RPG games like Baldur’s Gate.
What markets performed best for your game Space Marshals?
Mattias: We don’t know why but Chinese market liked us. We had some publishers looking at us before we were listed (1st and 2nd round), and they told our game and the theme wouldn’t work in China. And then we were nominated for the game of the year on the App Store. Now China is one of our best regions in the world. We also hope it’s gonna be success for Xenowerk Tactics.
Space Marshals was a P2P game. Besides China, what are other regions that performed best in terms of revenue and downloads?
Mattias: The US, Russia, South Korea, Germany, China are definitely top 5 for us.
To continue, check out the entire conversation.
Images: Xenowerk Tactics, Pixelbite

View full story

• The full interview with Pixelbite was originally published on the LocalizeDirect's site.
The creators of the “amazingly animated” Space Marshals, Reckless Racing, and Xenowerk, Swedish studio Pixelbite is launching its tactical mobile strategy game Xenowerk Tactics today. LocalizeDirect briefly talked to Pixelbite co-founders Mattias Olsson and Anders Blom about their new game, game localization secrets, and their ad-hoc game testing on the couch.
LocalizeDirect: Tell us a bit about your new game - Xenowerk Tactics.
Anders: It’s sort of a mix between our previous games Space Marshals and Xenowerk. It’s built on the story of the Xenowerk but Xenowerk was more of a shooting and action game, this one is a bit more strategic and tactical. There is a strategy element where you manage a basecamp, upgrade and recruit new operatives, and then you send then into the field, and in the field it becomes a tactical game for you.
What inspired you?
Mattias: It’s a mix of many games. We were inspired by games like Darkest Dungeon and XCOM, especially for the base management and recruitment parts. If we could get the player to care for the recruits the same way we did when playing those games it would be great. To hopefully achieve this we added unique traits and mutations to make each recruit feel more unique and valuable. For the combat side of things, we took inspiration from various RTS games and old-school RPG games like Baldur’s Gate.
What markets performed best for your game Space Marshals?
Mattias: We don’t know why but Chinese market liked us. We had some publishers looking at us before we were listed (1st and 2nd round), and they told our game and the theme wouldn’t work in China. And then we were nominated for the game of the year on the App Store. Now China is one of our best regions in the world. We also hope it’s gonna be success for Xenowerk Tactics.
Space Marshals was a P2P game. Besides China, what are other regions that performed best in terms of revenue and downloads?
Mattias: The US, Russia, South Korea, Germany, China are definitely top 5 for us.
To continue, check out the entire conversation.
Images: Xenowerk Tactics, Pixelbite
×