Game UI: Types, Patterns, and a Tiny-Team Workflow
Game UI is every on-screen element a player reads and interacts with: health bars, inventories, maps, menus. This guide covers the four UI types, pattern choices per genre, and a production workflow for a 2-8 person crew, covering scoping, handoff formats, and iteration loops that fit a tiny team's milestone.
What is game UI and how does it differ from UX in games?
Game UI is the visible interface layer: the HUD, menus, prompts, inventories, and health bars a player sees on screen. Game UX is broader: the entire experience of interacting with your game, from how controls map to actions to how quickly a player understands a system. UI is a component of UX, not a synonym for it.
UI is the surface, UX is the system
A clean HUD can sit on top of a confusing inventory flow, and players will still bounce off your game. The UI is what they see; the UX is whether the underlying loop makes sense. Browsing patterns by genre on the Game UI Database shows how many distinct interface conventions exist, which is why treating UI as a checklist of screens undersells the work.
Why the distinction matters more when you have no dedicated UX person
On a tiny crew, nobody owns UX full time, so it gets folded into whoever builds the screen. That works if you plan for it and fails if you discover flow problems at milestone crunch. Scoping UI work alongside the rest of your build, with the whole pipeline visible in one place like Inferno, is how you catch a broken flow before the build is locked, not after.
What are the main types of game UI (diegetic, non-diegetic, spatial, meta)?
Game UI falls into four standard types, defined by where the interface lives relative to the game's fiction. The type you pick changes art cost, engineering cost, and how much your tiny crew has to maintain per screen.
Diegetic: the interface lives in the world
The UI exists inside the fiction: a health gauge built into the character's suit, as in Dead Space, or a physical map your character holds. It's memorable and immersive, but every element needs 3D modelling, animation, and camera-aware design. Highest production cost of the four.
Non-diegetic: the classic HUD overlay
Health bars, ammo counters, minimaps rendered flat on screen. Cheapest to build, easiest to read, and the default for most genres. The tradeoff is immersion: the player is always reminded they're playing a game.
Spatial: projected into the game space
Markers floating over objectives and nameplates above players. It lives in the world but isn't a physical object. Usually 2D sprites or billboards in 3D space, so it's cheaper than diegetic but needs depth testing and scaling rules.
Meta: rendered on the screen but outside the fiction
Pause menus, character sheets, skill trees. The player acknowledges them as game constructs. Cost sits between non-diegetic and diegetic since they're screen-space but often content-heavy.
| Type | Immersion | Build cost for a tiny crew | Typical examples |
|---|---|---|---|
| Diegetic | Highest | High (3D + animation) | Armor health meter, in-world map |
| Non-diegetic | Lowest | Low (flat HUD) | Ammo counter, minimap |
| Spatial | High | Medium (world-space sprites) | Objective markers, nameplates |
| Meta | Medium | Medium (screen-space, content-heavy) | Pause menu, skill tree |
For a 2-8 person crew, a sensible default is non-diegetic HUD plus meta menus, with spatial markers where they cut friction. Reserve diegetic elements for one or two signature moments rather than a full pipeline of in-world assets. Whatever mix you choose, log the decision on the UI backlog so scope creep doesn't sneak in mid-milestone, and keep the plan visible in one shared board (your Inferno workspace policy stays simple: see the Privacy Policy for how task data is handled).
How do you choose the right UI pattern for your game genre?
Match player expectations first
Roguelike players expect dense non-diegetic readouts: health, cooldowns, and inventory states on screen at all times. Sims players tolerate heavy meta UI because the game is partly about managing systems. Shooters lean spatial (world-space markers) plus minimal non-diegetic HUD, while narrative games reward diegetic elements, like a diegetic inventory rendered on a character's body or a paper map in-world. The GDC Vault hosts many developer postmortems covering these choices, including talks on diegetic UI in shipped titles. Whatever you pick, track it as scoped tasks alongside art and code milestones rather than a side conversation; a kanban built for game pipelines helps, and we break down how Inferno compares to Codecks for that workflow.
When breaking the pattern is worth the risk
Break convention deliberately, not accidentally. Alien-style horror games drop HUD elements entirely to build dread; roguelikes occasionally diegetize ammo counts for tension. The test: does the break serve the core loop, or does it just cost players information they need mid-sprint? Prototype the break early, before your vertical slice locks scope.
What does a game UI production workflow look like for a small indie team?
A tiny crew ships UI fastest with a four-step loop: inventory every screen, greybox in-engine, art pass with full state coverage, then wire it up and log feedback where the rest of the build lives. No dedicated UI department needed, just discipline about ordering.
Step 1: list every screen and HUD element before art starts
Open a doc and enumerate everything: main menu, pause, inventory, settings, each HUD widget, every dialogue box. For each one, note its states (default, disabled, hover, error, loading). This inventory becomes your backlog, and it catches the screens everyone forgot, like the failure state of the save system, before they ambush you at a milestone.
Step 2: greybox in-engine, not in Figma
Build placeholder UI directly in Unity or Unreal with default rectangles and text. In-engine greyboxing surfaces the real problems immediately: does the HUD overlap the play area at 16:9 and 21:9, is the inventory readable on a Steam Deck screen, does the menu flow make sense with a controller? A mockup in a design tool can't answer any of that, and porting polished art later costs more than moving rectangles now.
Step 3: art pass and state coverage
Once layout is proven, your artist skins the greybox. The rule: no element ships until every state from Step 1 has final art. A health bar with no empty state, or a button with no pressed sprite, is a bug you'll find during your vertical slice demo at the worst possible moment.
Step 4: wire it up and log feedback in one place
Hook the UI to real game data, then playtest and log every piece of feedback as a task attached to the screen it concerns. Scattered notes in Discord die; a shared board where the UI inventory, art states, and playtest findings live next to the rest of the build keeps a tiny crew honest. If you're currently splitting this across Trello and chat, that's the exact gap covered in Inferno vs Trello.
How do you scope and track UI tasks alongside the rest of game development?
Decompose one screen into a task set
Take a single pause menu and break it until every card is one discipline and one sitting. Example: layout mockup (design), background art pass (art), button wiring and focus handling (code), confirm sound (audio), safe-area check on 16:9 and 21:9 (code), controller-only usability pass (design). That's six cards, each shippable in a day, instead of one "build pause menu" card that sits in your backlog for two weeks.
Resolution and safe-area work deserves its own card because it touches engine settings, not just your mockup. The Unity manual covers canvas scaling and reference resolution separately from layout work, so treat it as its own unit of scope creep.
Keeping UI work visible next to code and art
UI dies when it lives on a separate board. If your artist can't see that the dialogue box they're painting depends on a font that isn't licensed yet, you find out at the milestone. Put UI cards on the same kanban columns as code and art, tag them by discipline, and link the mockup card to the wiring card so dependencies are visible without opening Discord.
Running Inferno through the same criteria honestly
Inferno puts the whole build on one board, so a pause menu sits next to the build-break fix and the boss music, and our approach is built for exactly this single-board setup. Where it falls short: there's no built-in mockup annotation or image markup, so design review still happens in your image tool, and engine-specific fields like safe-area presets aren't tracked natively. HacknPlan and Codecks both go deeper on game-specific metadata; if discipline-level reporting matters more to you than one shared board, that's a fair trade.
What tools and file formats do game UI designers hand off to developers?
Sprite formats: 9-slice, atlases, and state variants
Hand off 9-slice sprites for anything that resizes: panels, buttons, tooltips. Export the corner insets as numbers, not vibes. Pack shared sprites into an atlas so the programmer loads one texture instead of forty files, and name state variants explicitly (button_idle, button_hover, button_pressed) so nothing gets wired to the wrong frame. The Unity documentation covers 9-sliced sprites and atlases in detail if you need a reference to point your artist at.
The one-page spec that prevents rework
Write down four things: target resolutions and safe areas per platform, font files with fallback weights, animation timings for transitions, and which elements scale versus reflow. A designer who ships a Figma frame and a folder of PNGs without this is handing the programmer a guessing exercise. One page in your shared workspace beats a Monday archaeology dig through chat history.
Comparing lightweight tool stacks
Most tiny crews pair a design tool with their existing board. If you track UI tasks in Codecks, HacknPlan, or plain Trello, attach the spec page and atlas exports directly to the task so handoff lives where the build lives.
How should indie studios playtest and iterate on game UI?
Watch hands, not faces
When a playtester tries your UI, watch their hands and cursor, not their face. Hesitation before opening the map or inventory tells you more than any verbal reaction. Ask them to think aloud, but trust the pauses: a two-second stall before every menu interaction is a readability bug, not a preference.
The three-question readability check
After each session, ask three things: What did this screen tell you? What did you try to do first? What did you never notice? If testers can't answer the first two within a few seconds, the hierarchy is wrong. If nobody notices an element, either it doesn't matter or it's buried.
Cutting UI scope before a vertical slice
Before a milestone, cut every UI element that doesn't serve the core loop of your vertical slice. A tiny crew ships a tighter build with five polished screens than fifteen half-built ones. Park the rest in your backlog, tag it post-milestone, and resist scope creep on settings menus nobody reads at 11 PM before a build deadline.
FAQ
Is a HUD the same as game UI?
No. The HUD is one component of game UI, typically the non-diegetic overlay showing health, ammo, or minimaps during play. Game UI also covers menus, inventories, dialogue boxes, skill trees, and settings screens, plus spatial and diegetic elements. Treating the HUD as the whole job is how teams end up shipping a polished overlay on top of half-built menus.
Do I need a dedicated UI artist for an indie game?
Not necessarily, but someone must own it. On a 2-8 person crew, UI work usually splits between whoever handles art and whoever wires screens in-engine. What matters is that the screens are inventoried, greyboxed in-engine, and given full state coverage before the art pass. A dedicated artist helps most when your game leans on many meta screens or a signature diegetic element.
What resolution should I design game UI at?
Design at a reference resolution, then verify scaling at 16:9 and 21:9 and on handheld screens like the Steam Deck. Greybox in-engine first so you catch overlap with the play area before art exists. Resolution and safe-area handling touches engine canvas settings, so scope it as its own task rather than folding it into layout work.
How much of my game budget should go to UI?
There's no fixed percentage, but UI is easy to underestimate because it touches every screen and state. Budget enough for the four-step loop: inventory, greybox, art pass with every state covered, then wiring and playtest iteration. A practical anchor: five polished screens beat fifteen half-built ones, so fund fewer screens fully and park the rest post-milestone.