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

March 13, 2017

I love UI and UX. It’s quite hard to design, and takes a long time to get right, but it’s so sat­is­fy­ing when you ulti­mate­ly get it right. I’m cur­rent­ly work­ing on the UI of my pre­ci­sion plat­former Mobil­i­ty, and I’ve seen a lot of both good and bad exam­ples late­ly, so I thought I’d write about the sub­ject more in-depth.

The goal of most UI, no mat­ter if it’s for an appli­ca­tion, a game menu, the inter­face of an oper­at­ing sys­tem, or what­ev­er, it’s to get the user from A to B as fast as pos­si­ble. That means it’s both obvi­ous to the users/players which actions they need to take in order to accom­plish their goal, as well as hav­ing as lit­tle steps between A and B as pos­si­ble. In the con­text of a game, this usu­al­ly means that the play­er can get from boot­ing the game to actu­al game­play as quick­ly as pos­si­ble, and for big­ger games, that users can com­fort­ably nav­i­gate inven­to­ry, 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 actu­al game­play starts. Here are a lot of things that could pos­si­bly hap­pen in that peri­od of time:

There are actu­al­ly a few more when a play­er starts up the game for his first time:

Some games use all of them. Espe­cial­ly when boot­ing up the game for the first time, it can take a long while before you are actu­al­ly play­ing the game.

Here’s the crux– if play­ers have paid for the game, they won’t real­ly care about all this– they’re already com­mit­ted to invest effort into the game because they’ve invest­ed mon­ey into it. Most of the items on the list are stan­dard­ized and rec­og­niz­able for the game lit­er­ate. Unless you’ve done a real­ly bad job, no one will notice nor care.

But if you make a free game, or your tar­get audi­ence are peo­ple not famil­iar with games, you are going to lose them even before they’ve even played the actu­al game­play. I’ve already seen this behav­ior a few times myself, when I was required to log in to play a game. Is it real­ly nec­es­sary to go through lev­els of menus before you can start play­ing? Enter The Wit­ness: you start the game, open the launch­er, press launch, wait on the load­ing screen, and then tran­si­tion to the loca­tion where you left off last time you played. It can be that sim­ple. Every­thing else is on the launch­er or in the pause menu.

I real­ly dis­like Pokemon’s UI. There’s a lot of func­tion­al­i­ty, with a lot of inter­face asso­ci­at­ed to it, and it’s often very bloat­ed and messy. The lat­est entry fix­es a lot of the points of crit­i­cism I had against the series’ user inter­face, but there’s still a lot of bad stuff in there. Here’s the sequence from the moment you encounter a wild Poke­mon until you can flee, which takes about 15 sec­onds at best:

Or you could just use a repel, but that’s not much bet­ter and has about an equal amount of steps need­ed to acti­vate. Not to men­tion, you always have these in a lim­it­ed quan­ti­ty, while you can always run from bat­tle, although it’s suc­cess is not always guar­an­teed.

Okay. My point: You could say that, in the Wit­ness, you bare­ly expe­ri­ence any fric­tion between you and the UI. In Poke­mon, its every­where, and the fric­tion is very high because even the most mun­dane tasks require you to wade through lev­els of menus, so there’s a lot of fric­tion to accom­plish the task you want to do. Thus, we can define fric­tion as ‘get­ting from A to B in a user inter­face’. It is quite sim­i­lar to game the­o­ry, which is about get­ting the play­er from the start to the goal in a lev­el in the most engag­ing way pos­si­ble.

This doesn’t spec­i­fy whether or not UI is unnec­es­sary– that depends on your design goals and inten­tions behind it, and, like we described above, the will­ing­ness of the user to put up with it. Fric­tion can be mea­sured in a vari­ety of units: the amount of screens, the amount of but­ton press­es, or time need­ed to com­plete a cer­tain task. Let’s look at all three.

Screens

In most cas­es, you want to have as lit­tle screens as pos­si­ble. A screen on the UI should always serve a pur­pose, prefer­ably mul­ti­ple. You should think real­ly hard whether or not the screen is absolute­ly nec­es­sary. Maybe you can com­bine them. Put the save file selec­tion on the main menu, instead of putting them on seper­ate screens. Com­bine title and load­ing screen. Dis­guise load­ing screens as game­play. Or just take the play­ers to game­play imme­di­ate­ly, don’t show them menus at all. It sur­pris­es me that there aren’t real­ly any games that have a but­ton on the title screen that’s like ‘just load the next unfin­ished lev­el so I don’t have to wade through five lev­els of menus to do some­thing that a play­er is 90% like­ly to want to do every time he/she loads the game’.

That said, putting too many options on one screen can lead to an over­dose of infor­ma­tion, and thus, choice paral­y­sis. You’ll need to find a del­i­cate bal­ance, and deter­mine the most impor­tant pieces of infor­ma­tion to dis­play.

Anoth­er way is hav­ing short­cuts, that reduce the amount of screens the play­er nor­mal­ly has to go through just by press­ing one or two but­tons. Tak­ing Poke­mon as an exam­ple, you can go into the items menu to assign a short­cut to it, and then in the over­world, you only have to press the short­cut but­ton, and then the but­ton 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 them­selves can decide what they wants to have quick access for, to suit their spe­cif­ic needs. Oth­er exam­ples are the Wii U quick start menu, where you can bypass the OS menu and just load a recent­ly played game direct­ly, and basi­cal­ly every mod­ern desk­top oper­at­ing sys­tem.

Think hard about what goals the user might want to achieve. There’s a dif­fer­ence between the ini­tial start­up and the star­tups after­wards. New and skilled play­ers. Free play­ers and paid play­ers. The ini­tial start­up is espe­cial­ly impor­tant, espe­cial­ly for a free game, because you’ll have to strike a good first impres­sion to make them keep com­ing back– or, to keep your reten­tion high. Over­all, you should aim for a less­er or equal amount of screens dur­ing the ini­tial start­up com­pared to sub­se­quent star­tups, instead of more. That can be hard to achieve, espe­cial­ly if you want play­ers to log in or do a tuto­r­i­al right away. Attempt to find a way around that. In jump­NULL for mobile I iden­ti­fied this prob­lem, so the game just skips the title screen and drops you imme­di­ate­ly in the game.

Time

Direct­ly influ­enced by the num­ber of screens, in most cas­es. Often, play­ers will com­plain about long load­ing times regard­ing this type of fric­tion. So, opti­miz­ing load­ing times for a game would reduce fric­tion, even though the amount of screens is iden­ti­cal.

You could also spread out the task of load­ing smart­ly. Does your game play a movie or logo sequence when it starts up? If so, you could already start load­ing the game while that is play­ing. Instead of load­ing the entire lev­el 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 per­son that decid­ed all Win­dows com­put­ers update after boot­ing up, instead of just before shut­ting down? Make the update run in the back­ground, or just use the app store’s update func­tion­al­i­ty.

Also, take into account the play­er might get lost in the UI, tak­ing a wrong step, that caus­es him to take longer to reach his goal. As such, you should make it as obvi­ous as pos­si­ble where the play­er needs to go to achieve a cer­tain action, by giv­ing him sug­ges­tions, using clear sign­post­ing, or if you’ve real­ly got a lot of options, a search func­tion­al­i­ty. Anoth­er thing to note is that when the user knows where to go, but makes a mis­take: like press­ing a direc­tion­al but­ton one time too often, or tap­ping instead of swip­ing, can still end up select­ing the wrong option, and does or doesn’t notice that a mis­take was made. On mobile, you should make but­tons as large as pos­si­ble, make the actu­al click­able areas of said but­tons even larg­er, and allow users to undo or con­firm par­tic­u­lar­ly impor­tant choic­es.

Button presses/individual inputs

Doing a sin­gle action might require mul­ti­ple press­es, taps, or swipes. For game con­trollers, this means using the left stick or dpad to put the cur­sor on top of a spe­cif­ic set­ting, then press­ing A to con­firm the selec­tion. Menus of games are often placed in a list, but often it’s bet­ter to put all options in a grid to reduce the num­ber of but­ton press­es. Anoth­er cheap trick is mak­ing the cur­sor wrap around the screen: so if your cur­sor is at the low­est entry, and you press down, the cur­sor goes to the top­most entry.

Or you can freestyle the menu, by scat­ter­ing the but­tons all across the screen. The most impor­tant ones are large and have the bright­est col­ors. Less impor­tant ones are small­er, some­times even just icons. It also takes less but­ton press­es to get your cur­sor to the largest but­tons. Most of the menus in the games by Saku­rai (the Smash. Bros, Kid Icarus Upris­ing, and Meteos pro­duc­er) fea­ture but­tons you can drag around on the screen. It’s intend­ed more as an east­er egg, but imag­ine a game where you could just build your own main menu to suit it to your needs?

Mobile games are a tad hard­er. In most cas­es, apply KISS: Keep It Sim­ple, Stu­pid. A lot of set­tings have stan­dard­ized icons in the mobile space, like the share but­ton and restore pur­chas­es, and the same goes for a lot of con­trols, like swip­ing and dou­ble tap­ping, as well. Avoid text if you can and use icons, since these are more uni­ver­sal­ly under­stood.

Conclusion

Reduce the amount of steps, time spent, and indi­vid­ual inputs from A to B in your UI. To do this, you can reduce or mask load­ing times, com­bine sev­er­al UI screens into one, put menus in grids instead of lists, sign­post the UI, use icons in addition/instead of text, or just drop the play­er into the game right after load­ing, no menu nec­es­sary– thus, ‘Death of the Title Screen’.

Here’s how I’m plan­ning to do it in Mobil­i­ty, from start­up to game­play:

I like it. After boot­ing the game (I didn’t list it here, but it’s so fast it’s not real­ly an issue), game­play is only one press away. When enter­ing a lev­el, it’s a mat­ter of two but­ton press­es, select­ing dif­fi­cul­ty, and then start­ing right away. I’ll prob­a­bly talk about it in depth when I’ve near­ly fin­ished the UI for Mobil­i­ty.

Hope this help you out approach­ing UI to be as unob­tru­sive as pos­si­ble.