Ask ten people on a game team what UI means and you will get answers that range from "the menus" to "the HUD" to "the stuff the art team makes at the end." All of those are partially right, which is exactly the problem. When a term is fuzzy, the work built on top of it gets fuzzy too, and the cost lands on the player.

This guide fixes the definition. Then it goes further than a dictionary entry, because knowing what UI stands for does not help you ship a better game. What helps is understanding the four categories of game interface, why the boundary between UI and UX matters commercially, and which decisions separate an interface players stop noticing from one they complain about in reviews.

What Does UI Stand For in Games? The Actual Definition

UI is an abbreviation of user interface. The concept predates games by decades. It comes out of human-computer interaction research and it describes the boundary surface where a person and a machine exchange information. The steering wheel is the user interface of a car. The dashboard is the user interface of a plane.

Games inherited the term but bent it into a shape the rest of software does not have to deal with. In a productivity app, the interface is the product. Nobody uses Figma for the pleasure of looking at the toolbar. In a game, the interface sits between the player and the thing they actually came for, which is the play itself. That creates a permanent tension. Every pixel of UI is a pixel not showing the game. Every millisecond a player spends reading a tooltip is a millisecond they are not playing.

So the working definition for game teams is narrower and more useful than the textbook one. Game UI is every on-screen element that exists to tell the player something or to let the player tell the game something, and which is not itself part of the simulated world. A tree in the forest is not UI. A marker floating over the tree telling you to chop it is.

That "not part of the simulated world" clause does a lot of work, and it is where most of the interesting design problems live. A tree is world. A marker is UI. But what about the ammo counter printed on the side of the gun your character is holding? What about the map your character physically pulls out of a backpack? Those are the edge cases that produced the classification everyone uses now.

UI Versus HUD: Not the Same Thing

People use these interchangeably and they should not. The HUD, or heads-up display, is a subset of UI. It is specifically the persistent information layer that stays on screen during active play: health, ammo, minimap, objective text, cooldown timers.

UI is the whole category. The HUD is one member of it. Your main menu is UI but it is not HUD. Your inventory screen is UI but it is not HUD, because it interrupts play rather than overlaying it. We go deep on the persistent layer specifically in our guide to game HUD design, because it has its own rules that do not apply to the rest of the interface.

The Four Types of Game UI Every Design Team Should Know

In 2014 a designer named Marcus Andrews published a framework at Gamasutra that stuck, and it has been the industry's shared vocabulary ever since. It sorts every interface element using two questions.

Question one: does this element exist in the game's fiction? Meaning, would the character know it is there? Andrews called this diegetic, borrowing the term from film theory, where diegetic sound is sound the characters can hear.

Question two: does this element exist in the game's 3D space? Meaning, is it rendered in the world with perspective and depth, or is it flat on the camera plane?

Answer both and you land in one of four boxes.

Non-Diegetic UI

Not in the fiction, not in the 3D space. This is the classic overlay: a health bar in the corner, a score in the top right, a minimap pinned to the edge of the screen. Your character has no idea any of it exists. It floats on the camera, unaffected by the world.

This is the default and it is the default for good reason. It is legible, it is cheap to build, it is easy to reposition for different screen sizes, and players have thirty years of trained instinct for reading it. The criticism is that it breaks immersion. That criticism is usually overstated. Players do not experience a health bar as immersion-breaking. They experience it as furniture.

Diegetic UI

In the fiction and in the 3D space. The character knows it exists and so does the camera. The ammo counter on the side of the weapon in Dead Space. The holographic display Isaac's suit projects. The wristwatch you check for the time instead of reading a clock in the corner.

Diegetic UI is the one everyone wants to build and the one that most often fails. It is beautiful in a trailer. It is frequently miserable at 3am when a player is tired and trying to read a number rendered at an angle in a dark room. The rule we apply: diegetic UI is a luxury you earn once the information is non-critical or the reading conditions are controlled. Put your critical, glanceable information somewhere legible and save the diegesis for the things a player can afford to miss.

Spatial UI

Not in the fiction, but in the 3D space. The outline that glows around an interactive object. The floating name tag above a teammate. The waypoint that hangs in the air at the correct distance and scales with perspective. Your character does not see the glow. The camera does.

Spatial UI is the quiet workhorse of modern game interfaces and it is underrated. It solves the single hardest problem in 3D games, which is telling the player where something is without making them read a map. It has grown enormously as a category over the last decade because it does immersion work without paying the legibility tax that diegetic UI charges.

Meta UI

In the fiction, but not in the 3D space. The blood spatter on the edge of the screen when you take damage. The rain droplets on the "lens." The screen distortion when you are poisoned. It exists in the character's world, the character is being rained on, but it is rendered flat on the camera rather than positioned in space.

Meta UI is the most efficient category by a distance. It conveys state without consuming a single square pixel of dedicated real estate, and it works pre-attentively, meaning the player registers it without having to look at it. Damage feedback is the obvious use. There are many more.

Why the Framework Actually Matters

The categories are not trivia. They are a decision tool. When your team argues about whether the quest log should be a menu or an in-world journal, what you are actually arguing about is diegetic versus non-diegetic, and the argument resolves the moment you ask the real question: how often does the player need this information, and how fast do they need to read it?

High frequency plus high urgency means non-diegetic, every time. Low frequency plus low urgency means you can afford diegetic and buy immersion with it. Most teams never ask the question and just default to whatever the art direction wants, which is how games end up with gorgeous, unreadable interfaces.

UI in Games Versus UX in Games: The Distinction That Costs Money

This is where the definitional question stops being academic.

UX, user experience, is the design of what happens to the player and in what order. It covers the flow from launching the game to their first meaningful success. It covers what gets introduced when, what gets withheld, where friction is deliberate and where it is a bug. It is a set of decisions about sequencing, information architecture, and cognitive load.

UI is what those decisions look like on screen. Type, colour, layout, hierarchy, motion, state.

The trap is that UI problems are visible and UX problems are not. When your UI is bad, someone on the team notices in a review. When your UX is bad, the game just quietly underperforms and everyone blames marketing. A studio can spend six months polishing an interface that is executing the wrong plan beautifully.

Here is the version that lands with executives. UI failure produces complaints. UX failure produces churn. Complaints are cheap. Churn is the business.

We have a full breakdown of the discipline in our guide to game UX design, but the short form is that UX comes first and UI serves it, not the other way round.

What Good Game UI Design Actually Does for the Player

Strip away the categories and the vocabulary and a game interface has four jobs.

It answers "what is happening." The player needs current state. How much health, how much ammo, what phase of the match, who is winning. This is the reporting function and it is the one most teams do adequately.

It answers "what can I do." The player needs to know their available actions and which ones are currently possible. Greyed-out buttons, cooldown sweeps, contextual prompts. This is where a lot of games get sloppy, presenting affordances that are technically visible but functionally invisible.

It answers "what should I do next." This is the hard one. It is the difference between a player who feels competent and a player who feels lost. Quest markers, progression signposting, tutorial pacing. Most retention problems in the first session are a failure of this question, not a failure of the game's mechanics.

It answers "did that work." Feedback. Confirmation. The hit marker, the sound, the number popping off the enemy. Jakob Nielsen's first usability heuristic, visibility of system status, was written for software but it is arguably more important in games, where the entire experience is a loop of act, observe, adjust.

An interface that answers all four without the player consciously reading it is a good interface. That is the whole bar. It is much harder to clear than it sounds.

The Cognitive Load Problem: Why Most Game UI Fails

The most common interface failure in games is not ugliness. It is volume.

Sidney Rhoads, a product designer on our team, put the underlying principle plainly in a conversation about applying psychology in UX design. She described cognitive load as the thing you are almost always trying to reduce, and explained that when there is too much stimulus or too much choice presented at once, the user gets fatigued and everything takes longer.

Games are uniquely bad at this because of an incentive problem. The team has spent two years building systems. Every one of those systems has a champion who wants it visible. The economy designer wants the currencies on screen. The progression designer wants the XP bar on screen. The social lead wants the friends list on screen. Nobody in that room is arguing for the player who has been in the game for ninety seconds and has no idea what any of it means.

Eric Lee Smith, a game designer who has shipped award-winning titles and worked on financial products used by millions, described the same dynamic to us on our Visionaries podcast. He put it as a general law: the longer a product is in development, the more complicated it becomes. He treated that as simply true, an outcome of the process rather than a failure of any individual.

Which means fighting it has to be deliberate. Nobody drifts toward simplicity. The interface gets more crowded every sprint unless someone with authority is actively removing things.

The practical antidote is progressive disclosure, a principle Nielsen Norman Group has documented extensively in their work on staging information across screens. You show the player the minimum required to take the next action. You unlock the next layer when they have earned the context to understand it. This is not dumbing anything down. Complexity is the reward, and revealing it in order is how you make it feel like a reward rather than an assault.

How Game UI Differs From App UI

Designers moving into games from product work usually make the same four mistakes, because four assumptions that hold everywhere else do not hold here.

The interface is not the destination. In an app, time on screen is often a success signal. In a game, time spent in menus is time not spent playing. The best game UI is the UI a player moves through fastest. Optimising for engagement with the interface is optimising for the wrong thing entirely.

The reading conditions are hostile. Your player is not calmly parsing a settings page. They are under time pressure, taking damage, tracking three things at once, possibly on a TV ten feet away, possibly on a phone in bright sunlight. Contrast ratios and type sizes that pass a desktop audit will fail in an actual match.

Input is not a mouse. Controller navigation is a directed graph, not a pointer. Every screen needs a defined focus order, defined wrap behaviour, and a defined default selection. Teams that design for mouse and retrofit for gamepad ship interfaces that feel broken on console, and it is very hard to fix late. Microsoft's Xbox Accessibility Guidelines are worth reading on this even if you never ship on Xbox, because they specify concrete minimums for text size and input that most teams are guessing at.

The aesthetic is not neutral. An app can be visually quiet and that is often correct. A game's interface is part of its identity. A survival horror HUD and a match-3 HUD are solving similar information problems and should not look remotely alike. The interface carries tone, and tone is part of why someone plays.

Common Game UI Elements and What They Are For

A quick reference for the vocabulary, since the terms get used loosely.

  • HUD: the persistent overlay during play. Health, ammo, minimap, objectives.
  • Main menu: the entry point. Its actual job is getting the player into the game with as little resistance as possible, which is why "continue" belongs at the top and everything else does not.
  • Inventory: the player's stuff, and the hardest screen in most games because it has to support browsing, comparing, sorting, and acting all at once. We cover the patterns in our guide to game menu design.
  • Loading screens: dead time you get to spend. Tips, lore, progress. A loading screen with no information is a wasted asset.
  • Onboarding and tutorial: the highest-leverage UI in the entire game, because it determines whether anyone sees the rest of it.
  • Store and economy screens: where trust is either built or destroyed. Hidden conversion rates and unclear pricing do measurable damage.
  • Settings: the screen nobody prioritises and every accessibility review starts with.

Who Owns Game UI on a Product Team

Structurally, this is where a lot of studios lose the plot. UI ends up owned by art, because it involves pictures, and art is measured on how it looks. That is a reasonable-sounding decision that produces a predictable outcome: interfaces optimised for the portfolio rather than the player.

The teams that get this right treat the interface as a product surface with a product owner. Art executes the visual layer. Someone else, with a research and product background, owns the questions of what appears, when, and why. Those are different skills and pretending they are one role is how you get a beautiful screen that tanks activation.

This is also why so much of the work is research-led rather than taste-led. Claudia Mérigo, a UX researcher on our team, described a gaming project where interviews revealed the client had misunderstood their own audience: the product had been designed for casual gamers, but the people who would actually use it were professional gamers, and those two groups have completely different behaviours, needs, and expectations. The research redirected the entire product. No amount of visual polish would have surfaced that.

We saw the same principle play out on Buildbox, a no-code game creation platform used by millions. The product was genuinely powerful. The original interface threw all of that power at new users the moment they signed in, and they left before they made anything at all. The value was real and completely invisible. Rebuilding the experience around a single meaningful first success, rather than a tour of the feature set, moved the number of users reaching that milestone by 41%. Nothing about the underlying product changed. What changed was what the interface chose to say first.

Game UI Design Standards Worth Knowing

There is no single spec, but there are references that carry weight and will save you arguments.

The Game Accessibility Guidelines are the closest thing the industry has to a shared baseline, organised into basic, intermediate, and advanced tiers. The basic tier is genuinely basic and most games still fail parts of it. Text size, remappable controls, subtitle options, and colour-blind consideration are not advanced features and treating them as stretch goals is a choice.

Platform holders publish their own requirements and they are not optional if you want to ship. Apple's Human Interface Guidelines and Google's Android game developer documentation both specify touch target minimums and behaviour expectations that will come up in certification whether you designed for them or not.

The pragmatic move is to read the accessibility guidance early rather than late. Almost everything in it improves the interface for players without disabilities too. Bigger text, clearer contrast, and remappable input are not accommodations. They are just better design that happens to also be required.

Final Thoughts: Why Game UI Is a Product Problem, Not an Art Problem

UI in games means the user interface: every element on screen that reports state, offers actions, or accepts input, and that is not part of the world itself. That is the definition and it is worth having straight.

But the definition is the least interesting part. What matters is the consequence. Your interface is the only part of your game every single player touches, in the first ten seconds, before they have any reason to be patient with you. It is the thing standing between the work your team spent years on and the player's ability to appreciate any of it.

Treat it as the last layer of polish and it will do exactly what a last layer of polish does, which is look fine and change nothing. Treat it as the product surface it actually is, with research behind it and someone accountable for what it says first, and it becomes the highest-leverage thing you can fix. The studios pulling ahead right now are not the ones with the biggest budgets. They are the ones who worked out that the interface is not in the way of the game. It is how anyone finds the game at all.

Get a Read on Your Game's Interface

If your game has an activation, retention, or conversion problem and you suspect the interface is involved, we can help you find out. Wandr has designed interfaces for game creation platforms, real-money gaming products, esports tools, and character systems, and the failure patterns are consistent enough that they are usually findable fast. Take a look at how we work as a game UI/UX design partner, or send us your product and we will come back with the friction points we would fix first. No pitch, just a real look at what is happening.

‍