Seven HUD mistakes that make players quit

What a HUD is actually for

Before the mistakes, the standard they are being measured against. A HUD has exactly three jobs, and everything on screen should be doing one of them.

1. Answer the question the player is about to ask. Am I in danger? Can I use this yet? Where am I going? If an element does not answer a question the player actually has at that moment, it is decoration.
2. Confirm that the game heard the input. Every press, hit, purchase and pickup needs an acknowledgement, and it needs to arrive immediately.
3. Stay out of the way the rest of the time. The game is the thing the player paid for. Interface is rent charged against it, and the rent should be low.

Almost every mistake below is a failure of one of those three, usually the third.

1. The HUD competes with the game

Opaque panels, heavy borders and saturated colours in the corners. Every element wins its local fight for attention and the whole screen loses. Meanwhile the world your art team built is fighting a bezel.

Why it happens: elements are designed one at a time, each on its own artboard, each made to look good in isolation. Nobody ever evaluates them together over real gameplay, so twelve individually reasonable decisions add up to an unreasonable screen.

The fix: the interface should be the quietest thing on screen until it has something to say. Drop opacity, remove the container entirely wherever the content can survive without it, and reserve your accent colour for state changes rather than decoration. If you cannot delete a panel background without losing legibility, the real problem is contrast, not the panel.

How to test it: screenshot a busy moment, then desaturate it. If the interface is still the first thing your eye lands on, it is too loud, because you have removed the one advantage colour gave the game world.

2. Information with no fixed home

Ammo sits bottom-right in gameplay, mid-left in the vehicle, and top-centre in the boss fight. Every relocation costs the player a fraction of a second of search, and those fractions are the difference between an interface that disappears and one that nags.

Why it happens: each mode gets designed by whoever built it, at the time they built it, and the layout is optimised for that mode alone. It is a coordination failure rather than a design failure, which is why it survives so long.

The fix: assign each information type a permanent screen region and defend it across every mode. On Astro Protocol resource counters live in a fixed top bar and primary confirmations sit bottom-right on every single screen, so players stop hunting and start planning. Consistency is worth more than local optimisation, every time.

How to test it: print one screenshot per mode and lay them side by side. Any element that moves between them needs a reason better than "it fitted here".

3. Everything is the same size

Health, ammo, score, minimap, quest tracker, currency, buff icons, all rendered at roughly the same weight. With no hierarchy, the player's eye has to read the entire HUD to find one number.

Why it happens: every system owner wants their system represented, and equal size feels like the fair answer. Fairness between systems is not a player-facing value.

The fix: rank your elements into three tiers, and be ruthless. Tier one is what the player checks under pressure, usually one or two things. Tier two is glanceable. Tier three is available on demand and does not need to be on screen at all. Then make the differences in size, contrast and position obvious rather than polite.

4. Designed at 100 percent zoom on a 27-inch monitor

The designer sits two feet from a large display. The player is on a handheld, or ten feet from a TV, or on a phone in daylight. Text that felt generous in Figma becomes unreadable, and touch targets become a coin toss.

Why it happens: the design tool shows the layout at a comfortable size on a comfortable screen, and nothing in the process forces a check at the real one.

How to test it: whichever platform you ship on, check at the lowest resolution you officially support, not on your dev machine. Then check it again in a bright room.

5. Feedback that arrives late, or not at all

The player presses a button and nothing acknowledges it for 200 milliseconds while a system resolves. In that silence they press again. Now they have bought two, or cancelled the thing they wanted.

Why it happens: feedback is treated as a consequence of the action rather than a response to the input. The engineering is correct and the experience is wrong.

The fix: acknowledge input immediately and separately from resolving it. A press state, a sound, a small movement, anything within about 100 milliseconds. Then show the result when it arrives. Damage, cost and reward all need to register at the moment they happen, not in a summary screen afterwards.

How to test it: record gameplay and step through it frame by frame at the moment of a press. If nothing on screen changes within a handful of frames, you have found the problem.

6. Numbers where a shape would do

Health as 847 / 1200 forces arithmetic during combat. Players do not do arithmetic during combat, they estimate, and a bar answers "am I in trouble?" in a glance while the number does not.

Why it happens: the number is what the code has. Rendering it is the shortest path from data to screen, and it never gets revisited.

The fix: use shape and colour for anything the player judges by feel, and reserve exact numbers for decisions that genuinely need precision, like costs and inventory counts. If you need both, make the shape primary and the number secondary in size and contrast. The same logic applies to cooldowns, ammo reserves and progress towards a goal.

7. Never tested in motion

This is the one that catches almost everyone. A HUD is reviewed as a still image, in a slide, sitting still. Then it ships into a game where the camera shakes, the background is bright one second and black the next, and the player is at 200 km/h.

Why it happens: stills are how design work gets reviewed and approved everywhere else, so that is how it gets reviewed here too.

The fix: review HUD work as video, over real gameplay, at real speed, on the worst-case backgrounds. Snow levels, explosions and white skyboxes destroy more HUDs than any other single factor. This is exactly the constraint the Nocturne Drive HUD was built around, and it is why the layout decisions look conservative in a still frame and work in motion.

How to test it: capture sixty seconds across your brightest and darkest levels, then watch it at half speed with the sound off. Anything that disappears, vibrates or fights the background is a fix, not a preference.

Genre changes what belongs on screen

There is no universal HUD. What earns permanent screen space depends entirely on what the player is deciding, and how fast.

Accessibility is a HUD problem first

Most accessibility complaints about games are complaints about the HUD, and most of them are cheap to prevent while it is being designed.

• Never encode meaning in colour alone. Roughly one in twelve men has some form of colour vision deficiency. Pair every colour cue with a shape, an icon or a position.
• Contrast against the worst background, not the average one. The snow level is the real test, not the grey box scene.
• Give text a scale option. A HUD text size setting is one of the highest-value accessibility features per hour of work.
• Do not rely on motion alone to signal something important. Pair it with a persistent state change.
• Let players toggle elements off. Individual toggles cost little if they are planned for, and they turn a divisive HUD into a personal one.

None of this is a substitute for a good default. Most players never open settings, so the default layout is still the design.

A ten-minute HUD audit

Record sixty seconds of real gameplay and run through this list. It costs nothing and it usually finds three of the seven.

1. Pause on a busy frame. Count the elements. Can you name what each one is for in under a second?
2. Blur the frame. What survives? Is that what should survive?
3. Find your brightest, most saturated pixel. Is it interface or is it game?
4. Play the clip and watch only the corners. Does anything move, jitter or overlap?
5. Pause on your brightest background. Is every element still legible?
6. Desaturate the frame. Does anything become ambiguous? That element is encoding meaning in colour alone.
7. Press three buttons. Does each acknowledge you before the result resolves?
8. Switch to a controller. Can you reach everything without a cursor?
9. Scale the window to 50 percent. What becomes unreadable first? Fix that one thing.
10. Ask someone who has never played to point at their health. Time it.