Your UI problem is usually a systems problem

The screen is where the design gets audited

A system exists in a spreadsheet, in code, and in the designer's head, and in all three of those places it can be as intricate as it likes. The screen is the first moment it has to be explained to somebody who was not in the room. That is a genuinely useful test, and it is why interface work so often surfaces design problems that survived every review.

Anything that cannot be shown clearly probably cannot be understood clearly either. The screen is not causing that problem, it is reporting it.

Signs it is the system, not the layout

1. It needs a tooltip to be understood at all. Not a tooltip for detail, a tooltip for existence. If the player cannot know what a thing does without hovering it, the thing is under-designed.
2. You cannot summarise it in a short phrase. If describing a stat takes a sentence with a conditional in it, the screen will need a sentence with a conditional in it.
3. Three currencies appear in one place. Every currency is a separate decision the player must hold, and they multiply rather than add.
4. A number nobody can act on. If seeing the value changes nothing about what the player does next, it is telemetry, not interface.
5. Two options with no visible difference. A choice the player cannot see the consequences of is not a choice, it is a coin toss with extra steps.
6. A modifier that is invisible in play. Hidden multipliers force the interface to explain something the game never shows, which is a losing position.
7. The screen only works with placeholder content. Real item names, real numbers and the maximum inventory size are the actual design constraints.

Complexity has a display cost

Design decisions are usually costed in engineering and content time. They also have a cost in screen space, comprehension and support, and that cost is rarely named until the interface is being built.

None of those are arguments against the decisions. They are arguments for costing them honestly, at the point they are made, while changing them is still cheap.

The comprehension budget

Players hold a small number of things in mind at once, and everything you put on screen competes for that space. It is worth treating as a budget with a real limit rather than as a soft preference.

• Under pressure, players track two or three things. In combat, a fourth resource is not tracked, it is ignored until it causes a death.
• At rest, they can handle more, which is why inventories and bases can be denser than a HUD.
• Every state is a thing to remember. Buffs, cooldowns, modes and stances all draw on the same budget.
• Familiar concepts are cheap. Health, ammo and money cost almost nothing because players arrive knowing them. Your invented resource costs full price.
• Names are part of the budget. Three invented nouns per system means a glossary, which is a UX writing problem caused by a design one.

Five systems changes that shrink an interface

When a screen is unsalvageable, these are the upstream changes I propose most often, roughly in order of how often they turn out to be the right answer.

1. 01

   Merge two currencies into one

   Ask what decision each currency forces. If two of them are spent in the same places on similar things, they are one currency wearing two hats, and merging them removes a bar, a conversion and a category of confusion.

2. 02

   Cap or collapse the stat list

   Eleven stats where three would do. Most games can fold several derived values into a smaller set of things players actually make decisions about, and keep the rest as hidden implementation.

3. 03

   Make the effect visible in the world

   A buff shown as a change in the character rather than as an icon costs nothing on the HUD and is understood faster. Anything the world can say does not need saying twice.

4. 04

   Delete hidden modifiers

   If it is invisible in play and only surfaces in a tooltip, it is not adding depth, it is adding trivia. Either make it visible or remove it.

5. 05

   Reduce the states an item can be in

   Owned, equipped, upgradeable, locked, new, comparable, broken. Each one needs a visual treatment and each one multiplies against the others. Cutting two states can halve the work on an inventory screen.

When the interface should push back

Part of a UI designer's job is to say that something cannot be shown, and to say it early enough to matter. That conversation goes better with a screen in hand than with an opinion.

• Draw the worst case, not the pitch. The inventory at maximum capacity with the longest item names, the HUD with every buff active. If that version does not work, the design has a problem the average case is hiding.
• Bring options, not objections. "This works if the third currency goes, or if we accept a second bar, or if the shop becomes two screens" is a design conversation. "This is too complicated" is not.
• Prototype the screen as a design test. A paper screen takes an hour and answers the question of whether a system is comprehensible before anyone builds it.
• Put the display cost in the estimate. A feature that adds four screens and eleven states is not a small feature, whatever the code says.

Numbers players can feel

A large share of interface clutter is numbers that exist because the system produced them, not because anyone uses them.

The exception is anything the player is optimising deliberately: build crafting, economy planning, competitive loadouts. There, precision is the point, and the screen should be built for reading rather than for glancing.

The screen as a design tool

The most useful change a team can make is to move the interface earlier, not as polish but as a test. Drawing the screen a system needs is one of the cheapest ways to find out whether the system is finished.

1. Sketch the screen when the system is designed, before it is implemented. An hour of drawing frequently changes the system.
2. Count the elements it forces. If the count surprises the designer, that is the conversation happening at the right time.
3. Write the tooltip before writing the code. If the tooltip is hard to write, the mechanic is hard to understand.
4. Show it to somebody outside the team and ask what they would do next.
5. Keep the sketch with the design document, so the display cost travels with the feature.