A lot of UI problems start before anyone opens Figma. They start in language. One person says HUD and means every interface element in the game. Another says menu and means a full screen. Someone calls a modal an overlay. Someone else calls a hint a tooltip. The team keeps moving, but the meaning is already drifting.
Small misunderstandings start entering reviews, tickets, handoff, QA, and implementation. The screen may look fine. The production language is the part that is already breaking.
Shared Language Is Part of the System
Terminology is not about being strict for the sake of being strict. It is about reducing ambiguity. When a team uses the same word for different UI elements, every conversation becomes slightly more expensive.
A tooltip, a hint, a modal, and a notification do not interrupt the player in the same way. They do not ask for the same level of attention. They do not carry the same weight. They should not be designed, tested, or implemented as if they were the same thing.
HUD vs UI
HUD means the in-game information layer. It usually contains information the player needs during gameplay, such as health, ammo, ability cooldowns, minimap, objective markers, resources, warnings, or interaction prompts. UI is broader. UI includes the HUD, but also menus, settings, inventory, stores, reward screens, pause screens, onboarding, popups, and flows.
Calling everything HUD makes the discussion less precise. Better wording: “The HUD needs a clearer cooldown state.” “The inventory UI needs better item comparison.”
Screen vs Menu
A screen is a full interface view. A menu is a set of options inside a screen, view, or flow. A pause screen can include several menus: Resume, Settings, Controls, Quit, Save, Load, or Accessibility.
If the team says “the menu is broken,” the issue is not specific enough. Which menu? Inside which screen? In which state? On which platform?
Overlay vs Modal
An overlay sits on top of the current view. It adds information or interaction without necessarily blocking the whole flow. A modal interrupts the flow and asks for attention or action before the player can continue.
The key is not the visual style. The key is behavior. Does it block input? Does it take focus? Does the player need to dismiss it? Does it pause the game? Does it require a decision? If the answer is yes, the team should probably treat it as a modal or modal-like flow.
Tooltip vs Hint
A tooltip explains a specific element. It gives extra context about a button, icon, stat, item, ability, or label. A hint gives broader contextual guidance. It helps the player understand what to do, where to look, or how to approach a situation.
A tooltip helps with meaning. A hint helps with action. The player may understand the icon but not the next step. That is probably a hint problem, not a tooltip problem.
Notification vs Toast
Notification is the broader term. A toast is usually a brief, lightweight, non-blocking message. Some teams use toast for small confirmations like “Item added,” “Progress saved,” or “Quest updated.”
Not every notification is a toast. Some notifications persist. Some require action. Some appear in a notification center. Some are tied to platform systems. If the team uses “toast” for every message, priority gets blurry.
Inventory vs Loadout
Inventory is what the player owns. Loadout is what the player equips or prepares for action. A player can own ten weapons in inventory, but only two may be equipped in the current loadout.
Inventory is about ownership, storage, collection, and management. Loadout is about selection, readiness, and strategy. If the team mixes these terms, flows can become confusing. A player may think they equipped something when they only inspected it.
A Simple Rule
When naming a UI element, ask what it does to the player’s flow. Does it inform, guide, interrupt, confirm, warn, ask for a decision, change state, show ownership, or prepare the player for action?
The Takeaway
Shared terminology is production clarity. It makes reviews sharper, tickets easier to understand, QA more specific, handoff cleaner, and implementation less ambiguous. It is not bureaucracy. It is less noise.