About UI friction, or ‘Death of the Title Screen’

March 13, 2017 No Comments

I love UI and UX. It’s quite hard to design, and takes a long time to get right, but it’s so satisfying when you ultimately get it right. I’m currently working on the UI of my precision platformer Mobility, and I’ve seen a lot of both good and bad examples lately, so I thought I’d write about the subject more in-depth.

The goal of most UI, no matter if it’s for an application, a game menu, the interface of an operating system, or whatever, it’s to get the user from A to B as fast as possible. That means it’s both obvious to the users/players which actions they need to take in order to accomplish their goal, as well as having as little steps between A and B as possible. In the context of a game, this usually means that the player can get from booting the game to actual gameplay as quickly as possible, and for bigger games, that users can comfortably navigate inventory, shop and trade menus.

Let’s just focus on that first one for now: from the moment you start up the game, until the moment the actual gameplay starts. Here are a lot of things that could possibly happen in that period of time:

There are actually a few more when a player starts up the game for his first time:

Some games use all of them. Especially when booting up the game for the first time, it can take a long while before you are actually playing the game.

Here’s the crux– if players have paid for the game, they won’t really care about all this– they’re already committed to invest effort into the game because they’ve invested money into it. Most of the items on the list are standardized and recognizable for the game literate. Unless you’ve done a really bad job, no one will notice nor care.

But if you make a free game, or your target audience are people not familiar with games, you are going to lose them even before they’ve even played the actual gameplay. I’ve already seen this behavior a few times myself, when I was required to log in to play a game. Is it really necessary to go through levels of menus before you can start playing? Enter The Witness: you start the game, open the launcher, press launch, wait on the loading screen, and then transition to the location where you left off last time you played. It can be that simple. Everything else is on the launcher or in the pause menu.

I really dislike Pokemon’s UI. There’s a lot of functionality, with a lot of interface associated to it, and it’s often very bloated and messy. The latest entry fixes a lot of the points of criticism I had against the series’ user interface, but there’s still a lot of bad stuff in there. Here’s the sequence from the moment you encounter a wild Pokemon until you can flee, which takes about 15 seconds at best:

Or you could just use a repel, but that’s not much better and has about an equal amount of steps needed to activate. Not to mention, you always have these in a limited quantity, while you can always run from battle, although it’s success is not always guaranteed.

Okay. My point: You could say that, in the Witness, you barely experience any friction between you and the UI. In Pokemon, its everywhere, and the friction is very high because even the most mundane tasks require you to wade through levels of menus, so there’s a lot of friction to accomplish the task you want to do. Thus, we can define friction as ‘getting from A to B in a user interface’. It is quite similar to game theory, which is about getting the player from the start to the goal in a level in the most engaging way possible.

This doesn’t specify whether or not UI is unnecessary– that depends on your design goals and intentions behind it, and, like we described above, the willingness of the user to put up with it. Friction can be measured in a variety of units: the amount of screens, the amount of button presses, or time needed to complete a certain task. Let’s look at all three.


In most cases, you want to have as little screens as possible. A screen on the UI should always serve a purpose, preferably multiple. You should think really hard whether or not the screen is absolutely necessary. Maybe you can combine them. Put the save file selection on the main menu, instead of putting them on seperate screens. Combine title and loading screen. Disguise loading screens as gameplay. Or just take the players to gameplay immediately, don’t show them menus at all. It surprises me that there aren’t really any games that have a button on the title screen that’s like ‘just load the next unfinished level so I don’t have to wade through five levels of menus to do something that a player is 90% likely to want to do every time he/she loads the game’.

That said, putting too many options on one screen can lead to an overdose of information, and thus, choice paralysis. You’ll need to find a delicate balance, and determine the most important pieces of information to display.

Another way is having shortcuts, that reduce the amount of screens the player normally has to go through just by pressing one or two buttons. Taking Pokemon as an example, you can go into the items menu to assign a shortcut to it, and then in the overworld, you only have to press the shortcut button, and then the button the item is assigned to, to use it. It feels a bit tacked on, but it does achieve reduce the amount of screens, plus the users themselves can decide what they wants to have quick access for, to suit their specific needs. Other examples are the Wii U quick start menu, where you can bypass the OS menu and just load a recently played game directly, and basically every modern desktop operating system.

Think hard about what goals the user might want to achieve. There’s a difference between the initial startup and the startups afterwards. New and skilled players. Free players and paid players. The initial startup is especially important, especially for a free game, because you’ll have to strike a good first impression to make them keep coming back– or, to keep your retention high. Overall, you should aim for a lesser or equal amount of screens during the initial startup compared to subsequent startups, instead of more. That can be hard to achieve, especially if you want players to log in or do a tutorial right away. Attempt to find a way around that. In jumpNULL for mobile I identified this problem, so the game just skips the title screen and drops you immediately in the game.


Directly influenced by the number of screens, in most cases. Often, players will complain about long loading times regarding this type of friction. So, optimizing loading times for a game would reduce friction, even though the amount of screens is identical.

You could also spread out the task of loading smartly. Does your game play a movie or logo sequence when it starts up? If so, you could already start loading the game while that is playing. Instead of loading the entire level at once, load it in chunks. For mobile devs: please don’t make me update the game the very moment I want to play it. Do you want to be the person that decided all Windows computers update after booting up, instead of just before shutting down? Make the update run in the background, or just use the app store’s update functionality.

Also, take into account the player might get lost in the UI, taking a wrong step, that causes him to take longer to reach his goal. As such, you should make it as obvious as possible where the player needs to go to achieve a certain action, by giving him suggestions, using clear signposting, or if you’ve really got a lot of options, a search functionality. Another thing to note is that when the user knows where to go, but makes a mistake: like pressing a directional button one time too often, or tapping instead of swiping, can still end up selecting the wrong option, and does or doesn’t notice that a mistake was made. On mobile, you should make buttons as large as possible, make the actual clickable areas of said buttons even larger, and allow users to undo or confirm particularly important choices.

Button presses/individual inputs

Doing a single action might require multiple presses, taps, or swipes. For game controllers, this means using the left stick or dpad to put the cursor on top of a specific setting, then pressing A to confirm the selection. Menus of games are often placed in a list, but often it’s better to put all options in a grid to reduce the number of button presses. Another cheap trick is making the cursor wrap around the screen: so if your cursor is at the lowest entry, and you press down, the cursor goes to the topmost entry.

Or you can freestyle the menu, by scattering the buttons all across the screen. The most important ones are large and have the brightest colors. Less important ones are smaller, sometimes even just icons. It also takes less button presses to get your cursor to the largest buttons. Most of the menus in the games by Sakurai (the Smash. Bros, Kid Icarus Uprising, and Meteos producer) feature buttons you can drag around on the screen. It’s intended more as an easter egg, but imagine a game where you could just build your own main menu to suit it to your needs?

Mobile games are a tad harder. In most cases, apply KISS: Keep It Simple, Stupid. A lot of settings have standardized icons in the mobile space, like the share button and restore purchases, and the same goes for a lot of controls, like swiping and double tapping, as well. Avoid text if you can and use icons, since these are more universally understood.


Reduce the amount of steps, time spent, and individual inputs from A to B in your UI. To do this, you can reduce or mask loading times, combine several UI screens into one, put menus in grids instead of lists, signpost the UI, use icons in addition/instead of text, or just drop the player into the game right after loading, no menu necessary– thus, ‘Death of the Title Screen’.

Here’s how I’m planning to do it in Mobility, from startup to gameplay:

I like it. After booting the game (I didn’t list it here, but it’s so fast it’s not really an issue), gameplay is only one press away. When entering a level, it’s a matter of two button presses, selecting difficulty, and then starting right away. I’ll probably talk about it in depth when I’ve nearly finished the UI for Mobility.

Hope this help you out approaching UI to be as unobtrusive as possible.

Leave a Reply

Your email address will not be published. Required fields are marked *