Back to Blog
uihuduxgame design

What Belongs on the HUD: An Information Audit for Your Game's UI

Most HUDs show twenty things and communicate four. Run a three-question audit on every on-screen element, then push what survives into the world, the audio or an on-demand screen.

GameDesignerX TeamOctober 4, 20267 min read

A playtester once died in front of me with three unused health kits in her inventory. The prompt telling her she could heal was there the whole time — bottom-right corner, 14px grey text, behind a damage vignette, competing with a quest tracker, an ammo counter, a stamina bar and a minimap. She wasn't bad at the game. She just never looked at the one pixel-cluster that mattered.

That is an information design failure, not a player failure, and it is the most common kind of bug that never gets filed because nothing crashed. The fix isn't "make the prompt bigger." It's an audit: a pass where you list every piece of information your game displays, prove each one earns its place, and decide where it should actually live. Here's how to run it in an afternoon.

Start with an inventory, not a mockup

Pause your game at a busy moment and screenshot it. Then write down every distinct element on screen — not categories, individual elements. A typical action game produces a longer list than people expect: health bar, stamina bar, ammo in magazine, ammo in reserve, equipped weapon icon, grenade count, three ability cooldowns, minimap, compass bearing, objective text, distance marker, crosshair, hitmarker, damage direction indicator, interaction prompt, currency, XP bar, level number, buff icons, subtitle line, speaker name.

Twenty-one elements. If your screen looks like this, players are not reading twenty-one things. They are reading about four and ignoring the rest — and you don't get to pick which four.

The three questions

For each element, answer these in one line each. Be strict — "it's useful" is not an answer.

1. What decision does this inform? Not "what does it tell the player" — what does the player do differently because of it. A stamina bar informs the decision to sprint or hold back. An XP bar informs almost nothing moment-to-moment; it informs a session-length decision about whether to keep playing. Those two facts do not belong in the same place.

If you cannot name a decision, the element is either flavour — fine, but let it be quiet — or cargo-cult UI copied from a genre template.

2. How often does the player need to check it? Three honest buckets:

  • Continuous — needed multiple times per second, during pressure. Health in a shooter. Stamina in a soulslike.
  • Periodic — needed every few seconds, usually between threats. Ammo reserve, cooldowns, objective direction.
  • On demand — needed when the player chooses to think about it. Currency, inventory contents, quest log, level.

3. What happens if they miss it? Death, wasted resource, mild confusion, or nothing. This is your priority ranking, and it is usually not the ranking your current HUD expresses.

Put it in a table — one row per element. The pattern usually jumps out immediately:

Element Decision it informs Cadence Cost of missing it Belongs
Health Retreat / heal / push Continuous Death Screen edge + world/audio redundancy
Stamina Sprint / dodge timing Continuous Death Near the character or crosshair
Ammo in mag Reload now or after Periodic Wasted trigger pull Weapon model or near crosshair
Ammo reserve Change weapon, scavenge Periodic Mild Small, corner
Heal prompt Use the item Periodic Death with items unused High-contrast, near centre, transient
Currency Nothing in combat On demand None Shop / inventory screens only
XP bar Keep playing or stop On demand None End-of-encounter summary

Note what just happened: currency and XP left the combat HUD entirely, and the heal prompt moved from "grey corner text" to the most expensive real estate you have. Same amount of information, redistributed by cost of failure.

Four places information can live

The HUD is the laziest of four options, and most teams reach for it first.

On the HUD. Cheap to build, but every element you add taxes every other element. Reserve it for continuous information.

In the world (diegetic). Dead Space puts health and stasis charge on the spine of Isaac's suit. Celeste shows whether your dash is available by the colour of Madeline's hair — red when charged, blue when spent — so the information sits exactly where your eyes already are. Mirror's Edge paints the route itself red instead of drawing a path on a minimap. Diegetic display costs art time and buys back a clean screen.

In audio. A low-health heartbeat, a dry-fire click, a cooldown-ready chime. Audio is the only channel that works when the player's eyes are elsewhere, which is exactly when continuous information fails. If your health bar is the only signal that health is low, you have a single point of failure.

In animation and camera. A character who limps is a health bar. A weapon that visibly hangs empty is an ammo counter. Desaturation at low health works peripherally, which numerals never do.

The strong version of the rule: anything continuous should exist in at least two channels. Health gets a bar and a sound and a colour shift. Everything else gets exactly one channel, and preferably not the HUD.

Numbers worth deciding on purpose

Pick these values once, write them in your spec, and hold the line:

  • Safe margin: keep nothing critical closer than 5% of screen width to any edge. Broadcast-era convention, still the right call — it survives overscan, phone notches, Steam Deck bezels and ultrawide letterboxing.
  • Minimum text height: target roughly 2% of screen height for anything the player must read under pressure. At 1080p that's ~22px. If your current prompt is 14px, that is the actual bug.
  • Transient duration: 2–4 seconds for a pickup or prompt notification. Under 2s and players in combat never see it; over 4s and three of them stack.
  • Simultaneous transients: cap it at two, with a queue behind. Decide the eviction rule now (newest wins? highest priority wins?) rather than discovering it in a playtest.
  • Contrast: check your HUD against your brightest and darkest level. White text on a snow level is a classic. An outline or a subtle scrim costs nothing.
  • Colour redundancy: never encode a state in hue alone. Roughly 1 in 12 men has some form of red-green colour vision deficiency, so pair every colour cue with a shape, position or icon change.

Test the audit, don't trust it

Three cheap tests, all runnable in one playtest session:

  1. The freeze-frame test. Screenshot a random combat moment and show it to someone for two seconds. Ask what the player should do next. If they can't tell, your priority ranking is wrong.
  2. The mute test. Play with audio off. Note everything you suddenly cannot tell. That list is your missing redundancy.
  3. The occlusion test. Cover each HUD element with tape (literally, on the monitor) and play a full encounter. Anything you didn't miss should probably move off-HUD or be cut. This one is brutally effective and nobody runs it.

Record what testers did, not what they said. "I didn't see the prompt" is a report you can act on; "the UI felt cluttered" is not.

The checklist

  • Every on-screen element is listed individually
  • Each element names one concrete player decision
  • Each element is tagged continuous / periodic / on-demand
  • On-demand information has been removed from the combat HUD
  • Every continuous element exists in two or more channels
  • No state is encoded in hue alone
  • Minimum text size and 5% safe margin verified at your lowest target resolution
  • Transient cap and eviction rule written down
  • Freeze-frame, mute and occlusion tests run with at least two outside testers

Keep the decisions somewhere findable

HUDs bloat because elements get added by whoever is building a feature that week, and nobody owns the whole screen. Six features each add "just one indicator" and the budget is gone.

Give the screen an owner and a spec. In GameDesignerX, the audit table slots naturally into your mechanics docs — each mechanic's entry states which channel communicates its state — while the transient cap, safe margins and text sizes live alongside your control schemes as a UI contract any new feature has to fit inside. When you cut an element, log why in the decision log so it doesn't get re-proposed next sprint, and attach freeze-frame screenshots to the relevant playtesting session.

A HUD is not a dashboard. It's a budget. Spend it on the decisions that kill players, and push everything else into the world, the sound, or a screen the player opens on purpose.