Game UI Design: A Practical Guide

Game UI design is the discipline of building every screen, menu, overlay, and heads-up element a player reads while they play — and reading is the operative word. Unlike a website, a game interface competes with motion, particle effects, and a player whose eyes are locked on the action, not your panels. The job is to deliver the right information at the right moment without ever pulling attention away from the game itself.

This guide covers the working principles practitioners use: the diegetic-to-non-diegetic spectrum, HUD clarity under motion, designing for controller versus touch versus mouse, TV safe zones and resolution scaling, accessibility, and the tools and handoff workflow that get a UI from Figma into an engine. It is the hub of our game and entertainment design cluster, so each section links out to a deeper companion piece.

UI vs UX vs HUD: getting the vocabulary right

These terms get used loosely, so pin them down before you design anything. UX is the whole shape of the player’s experience — how a flow feels, how many taps to start a match, whether a menu makes the player feel lost. UI is the visual and interactive layer that delivers that experience: buttons, panels, type, icons, motion. The HUD (heads-up display) is the subset of UI that stays on screen during gameplay — health, ammo, mini-map, objective markers, timers.

A useful mental split: menus are where the player makes deliberate decisions with full attention, and the HUD is where the player absorbs information with almost no attention to spare. The two demand different rules. A settings menu can be dense and text-heavy; a HUD element a player glances at for 200 milliseconds mid-firefight cannot.

The diegetic spectrum: four classes of game UI

The most influential framework in game UI comes from a 2009 talk by Erik Fagerholt and Magnus Lorentzon, who classified interface elements along two axes — whether the element exists in the game’s fiction (the narrative) and whether it exists in the game’s geometry (3D space). That gives four practical categories every designer should be able to name:

• Diegetic UI — exists inside the game world and the fiction. The ammo counter on the side of a gun in a shooter, or the wrist device a character physically looks at. The character can “see” it too.
• Non-diegetic UI — the classic HUD overlay drawn on top of the screen, outside the fiction and outside 3D space. A health bar in a screen corner. The player sees it; the character does not.
• Spatial UI — drawn in 3D space but not part of the fiction. Floating objective markers, enemy outlines, or a path line on the ground that the character is not aware of.
• Meta UI — part of the fiction but not represented in 3D space. Blood splatter on the screen edges to signal damage, or rain on a “camera lens.” It belongs to the world’s logic but lives as a full-screen effect.

You will mix all four in a single game. The framework is not a style rule — it is a decision tool. When a stakeholder asks for a new on-screen element, deciding which class it belongs to immediately tells you where it should live, how immersive it can be, and what trade-offs you are making between fiction and clarity.

HUD clarity: designing to be read in 200 milliseconds

The core constraint of a HUD is that it is read peripherally. The player’s focus is on the center of the screen and on the threat; your panels sit at the edges and must communicate at a glance. A few principles that consistently hold up:

• Hierarchy by urgency. Health and immediate threats get the strongest contrast and the most stable position. Cosmetic or low-frequency info (currency, season XP) gets quieter treatment.
• Shape over text. A radial cooldown, a depleting bar, or a changing silhouette is read faster than a number. Reserve precise numbers for cases where exact values matter.
• Stable anchoring. HUD elements should not jump around. Players build muscle memory for “health is bottom-left.” Animate appearance and changes, never the resting position.
• Earn every pixel. Every persistent element is a tax on immersion and attention. If something can be shown only when relevant (ammo when reloading, objective when it updates), fade it in and out.

Readability under motion is the brutal test. A label that looks crisp on a static mockup can vanish over a bright sky or a snowfield. The reliable fix is a treatment that survives any background: a subtle drop shadow, a semi-transparent scrim behind text, or an outline/stroke on key glyphs. Test every HUD element over your brightest and busiest scenes, not over a flat gray comp.

Type and color for gameplay legibility

Type in a HUD is functional, not decorative. Favor a clean, high-x-height sans with clearly differentiated numerals — players read a lot of numbers in games, and a 6 that reads as an 8 is a real bug. Geometric and humanist sans faces in the spirit of Inter or a sturdy condensed sans work well because they hold up at small sizes and under motion. Save the stylized display face for the logo, the title screen, and big moments; keep gameplay text boring and legible.

Color carries meaning in games — red for damage, green for friendly, yellow for objective — so it has to be designed deliberately and never relied on alone. Pair every color signal with a second cue (shape, position, icon) so the message survives both a chaotic scene and a colorblind player. We cover the symbol layer of this in depth in our companion piece on game icon design for store and in-game use, where silhouette and consistency do most of the work.

Designing for input: controller vs touch vs mouse

Input device dictates layout more than any aesthetic decision. The same screen on a controller, a touchscreen, and a mouse is effectively three different designs.

Concern	Controller / TV	Touch / Mobile	Mouse + keyboard
Navigation model	Directional focus, one element highlighted at a time	Direct tap, no focus cursor	Free pointer, hover states
Target size	Spacing matters more than size	Large — fingers occlude, ~44px+ targets	Small targets acceptable
Reach	N/A	Thumb zones — bottom corners are prime	Whole screen reachable
Feedback	Focus highlight + sound + rumble	Touch state + haptics	Hover + cursor change
Density	Lower — viewed from across a room	Medium	High density OK

For controller and TV play, the single most important thing is an explicit, always-visible focus state: exactly one element is “selected,” and D-pad/stick movement walks predictably between elements. Plan the navigation graph deliberately. For touch, respect thumb reach — put primary actions in the bottom corners and keep destructive actions away from where a thumb rests. Many of these layout fundamentals — grids, spacing, component states — carry over directly from app and product UI, so a structured UI kit pays off here too.

Safe zones, resolution scaling, and the TV problem

A game ships across phones, laptops, 1080p TVs, and 4K monitors, often on the same build. Two technical realities shape every layout:

• Title and action safe zones. Televisions overscan — they crop the edges of the image. The convention is to keep important UI inside a “title safe” area (roughly the inner 90%) and never place critical elements in the outer margin. Anchor HUD elements to screen edges with a safe-zone offset so nothing critical gets eaten by overscan.
• Resolution and aspect independence. Design in a resolution-independent way: anchor elements to corners and edges rather than absolute pixel positions, and let panels scale with the canvas. Test 16:9, ultrawide 21:9, and tall phone aspect ratios. Ultrawide in particular punishes center-anchored HUDs by flinging elements to the far edges of the player’s vision.
• DPI / scale settings. Offer a HUD scale slider. What is comfortable on a 27-inch monitor is illegible on a handheld and oversized on a 65-inch TV viewed from a couch.

Accessibility is a core requirement, not a feature

Accessible UI is now an expectation, and much of it is straightforward to build if you plan for it early. The high-impact areas:

• Colorblind support. Roughly 1 in 12 men has some color vision deficiency. Provide colorblind modes and, more importantly, never encode critical information in color alone — back it with shape, icon, or pattern.
• Text scaling and readable defaults. Subtitles and UI text should scale up, with adjustable size and a high-contrast background option. Generous default text size is a kindness to everyone, not just low-vision players.
• Reduced motion and reduced flashing. Offer toggles to dampen screen shake, motion blur, and flashing — important for vestibular sensitivity and photosensitive epilepsy.
• Remappable controls and HUD options. Let players move, hide, or resize HUD elements. Flexibility in the UI layer is one of the cheapest accessibility wins available.

Tools and the design-to-engine handoff

Most game UI is designed in Figma (for layout, components, and flows) or Photoshop and Illustrator (for raster textures and vector marks). The interface is then built in the game engine — typically Unity or Unreal — by a UI programmer or technical artist. Designers don’t usually own the engine implementation, but designing with the engine’s constraints in mind avoids painful rework.

Practical handoff habits that save weeks:

1. Build a real component library with defined states (default, focused, pressed, disabled) — the focus state is non-negotiable for controller games.
2. Design at a base resolution but document anchor points and scaling behavior for every element, not just static positions.
3. Export icons and decorative marks as crisp vectors or correctly-sized rasters; specify the asset set rather than hoping engineers slice it correctly.
4. Annotate motion: durations, easing, and what triggers each transition. “Fade in over 150ms” is a spec; “make it feel snappy” is not.
5. Define the type and color tokens once and reuse them, so a balance change doesn’t require touching fifty screens.

The rest of the cluster

Game UI sits alongside the other surfaces a game presents to the world. The marks and identity matter as much as the in-game interface, so explore the companion guides: game logo design tips and examples for the title-screen wordmark and emblem, esports logo design for mascots and marks when a competitive team or community grows around the game, video game poster and key art design for the marketing hero image, and board game design graphics and components for the analog cousin of all this — iconography, card layout, and physical legibility. For the symbol layer specifically, the game icon design guide goes deep on store icons and in-game inventory sets.

Frequently Asked Questions

What is the difference between diegetic and non-diegetic UI?

Diegetic UI exists inside the game’s fiction and world — an ammo counter physically on the gun that the character could also see. Non-diegetic UI is the standard overlay drawn on top of the screen, like a corner health bar, which only the player sees. Most games blend both depending on the moment.

What makes a game HUD readable?

Readable HUDs use urgency-based hierarchy, communicate through shape and color rather than text where possible, stay anchored in stable positions, and apply a treatment (shadow, scrim, or outline) so elements survive bright and busy backgrounds. Test every element over your most chaotic scene, not a flat gray mockup.

How do I design game UI for both controller and touch?

Treat them as separate layouts. Controller UI needs an explicit focus state and a predictable navigation path between elements; touch UI needs large targets in thumb-reachable bottom corners and no reliance on hover. Plan the controller navigation graph deliberately rather than relying on automatic focus.

What are safe zones in game UI?

Safe zones are the inner region of the screen where critical UI should stay because televisions overscan and crop the edges. Keep important HUD elements inside the title-safe area (roughly the inner 90%) and anchor them with a margin offset so overscan never hides health, ammo, or objectives.

Which tools do game UI designers use?

Layout, components, and flows are usually built in Figma; raster and vector assets in Photoshop and Illustrator. The interface is then implemented in a game engine such as Unity or Unreal by a UI programmer. Designing with engine anchoring and scaling in mind prevents costly handoff rework.