Game UX design: what it actually is, and when your game needs it

UX is not UI, and the difference is expensive

UI is what it looks like. Type, colour, spacing, components, states, artwork. UX is what happens. What the player is trying to do, what they need to know, what order it comes in, and what goes wrong.

You can have a beautiful UI on top of broken UX, and it happens constantly: a gorgeous shop nobody can navigate, a stunning skill tree nobody understands, a main menu that looks like a film poster and takes four inputs to get past. The reverse is rarer and much less damaging. A plain interface with correct structure is a game people finish.

What a game UX designer actually delivers

UX output is less photogenic than UI output, which is exactly why it gets skipped. These are the artefacts worth paying for.

What players say, and what it means

Players are excellent at detecting problems and unreliable at diagnosing them. Almost every complaint below is a usability problem wearing a different hat, and a surprising number of them are a wording problem, which is the words in your game.

Onboarding is where the money is

If you only ever buy one piece of UX work, buy this. The first ten minutes decide refunds, reviews, wishlisted-then-forgotten, and whether a streamer keeps playing past the intro. What that stretch has to do, beat by beat, is in the first ten minutes.

1. Teach one thing at a time, then use it immediately. Anything taught and not practised within about a minute is gone.
2. Teach at the moment of need, not in a block at the start. A tooltip when the player first has a reason to care beats a tutorial screen they skipped.
3. Never explain what can be demonstrated. A level designed so the only path teaches the mechanic beats any amount of text.
4. Let them play in the first thirty seconds. Logos, menus and cutscenes before any input is the most common self-inflicted wound in indie games.
5. Make the first goal unmistakable. Players who do not know what they are trying to do read that feeling as boredom.
6. Reinforce, do not repeat. Show it again in a new context rather than showing the same popup twice.

On Astro Protocol this meant running the tutorial as contextual tooltips layered over live gameplay, with key terms linked so a player could drill into a concept and come straight back, rather than stopping the game to explain a dense 4X ruleset up front.

Navigation, and the menu-tree problem

The most common structural failure is depth. Every extra level a player has to descend costs comprehension, and menu trees grow by accident: each feature adds a screen, nobody ever removes one, and after a year the shop is four levels down. Flattening one, and the separate problem of players getting lost in the world rather than the menus, is in where do I go?.

• Three levels is a working ceiling for anything a player uses regularly. Deeper needs a very good reason.
• Back must always mean back. One consistent behaviour, everywhere, on every input. Nothing erodes trust faster than a back button that occasionally exits.
• Frequency decides position. The thing players do most should be nearest, even if it is not the most important-sounding.
• Name things as the player would. Internal names leak into interfaces constantly and mean nothing to anyone outside the team.
• Count the inputs to your most common action. If it takes more than three from the main menu, you have found a redesign worth doing.

Feedback is the UX half of game feel

Game feel is usually discussed as an animation and audio problem. Half of it is UX: the player did something, and the game has to say so, immediately and unambiguously.

Every action needs three answers: did it register, did it work, and what changed. Those are three separate signals and they arrive at different times. The press state answers the first within a frame or two. The result answers the second. The changed number, bar or inventory answers the third. Games that feel unresponsive are almost always missing the first one, which is also the cheapest to add. The timing budget, the layers and the audit are in how a game tells the player it heard them.

The in-gameplay side of this is covered in seven HUD mistakes that make players quit; the same rule applies in menus, where a shop purchase with no acknowledgement produces double-buys and support tickets.

Not all friction is bad

UX in games is not about removing every obstacle. The obstacles are the product. The distinction that matters is where the difficulty lives.

The test: is the difficulty in the game or in the interface to the game? Difficulty in the game is design. Difficulty in the interface is a tax, and players pay it in goodwill.

How to run a playtest that produces real data

Three playtests will tell you more than any amount of internal debate, but only if they are run properly. The single most common mistake is helping. The full method, from recruiting to the prioritised fix list, is in how to run a playtest that tells you something.

1. 01

   Find someone who has never seen it

   Not your team, not the friend you have described the game to. Genuine first exposure is the only kind that produces this data, and each person can only give it to you once.

2. 02

   Give them one sentence and then stop talking

   "Here is the game, play it." Every hint you offer replaces a finding you were about to get. The urge to help is enormous. Resist it.

3. 03

   Watch their hands and their face, not the screen

   You already know what is on screen. Hesitation, backtracking, repeated presses and the moment they lean back are the data.

4. 04

   Write down timestamps, not opinions

   "0:40 tried to click the logo", "3:10 asked what the blue bar was". Opinions collected afterwards are unreliable; observed behaviour is not.

5. 05

   Ask questions only at the end, and open ones

   "What were you trying to do there?" beats "Was the menu clear?", which invites politeness rather than information.

6. 06

   Fix what two of three people hit

   One person struggling might be them. Two out of three is your design, and it is worth the work.

Signs your game needs UX work now

• Playtesters ask what to do next, more than once.
• You find yourself explaining a screen while someone plays.
• Your tutorial has grown into a wall of text nobody finishes.
• The menu tree is more than three levels deep anywhere players go often.
• Reviews or feedback use the words confusing, clunky or unclear.
• Your team argues about interface decisions without any way to settle it.
• You added a feature and cannot decide where it goes.
• Analytics show a drop-off at a specific point and nobody knows why.

Two or more of those is a strong signal. The good news is that UX findings are usually cheap to act on relative to what they save, because they are found before the artwork exists.

What it costs and how long

A review is the highest-value first purchase for most teams: it is cheap, it is fast, and it tells you whether the rest of the work is needed at all. Full ranges across every kind of interface work are in what game UI/UX design actually costs.