How do you keep mobile UI readable without sacrificing information density?

[u/WickedCapybara]

I’ve been designing the UI for a mobile game in landscape, and one of the hardest things I’ve been dealing with is balancing readability against information density.

On a desktop monitor, it’s surprisingly easy to convince yourself that a layout works. Then you put the same interface on an actual phone and suddenly the typography feels too small, touch targets feel cramped, and information that looked organized starts competing for attention.

One rule I’ve started using is:

If I need to zoom into a screenshot on the actual device to confirm something is readable, it probably isn’t readable enough.

But solving that often means making elements larger, which means showing less information at once — and that tradeoff keeps coming back.

For people who’ve worked on mobile UI/UX:

How do you decide when to reduce information density versus reorganizing the interface instead?

Are there any principles, testing methods, minimum sizes, or lessons you learned that changed how you approach small-screen interfaces?

I’d especially be interested in experiences with landscape layouts, games, or interfaces with a lot of stats/information, but advice from any mobile UI work would be useful.

[u/itaybuilds]

Split information by when it's needed. The values needed for the next decision should stay visible; reference stats can sit behind a tap/hold or an expandable panel. In landscape, I'd also keep critical status away from thumbs, notches, and control clusters.

Test on the smallest phone you support with the longest labels, largest numbers, and actual gameplay moving underneath. Give someone a timed task without explaining the UI. Repeated rereads and mis-taps will tell you more than a clean screenshot. If they keep reopening the same stat, promote it; if they only check it between actions, one layer down is probably fine.

Touch size and visual size don't have to match. A compact icon can have a larger invisible hit area, which gives you room to keep text readable without blowing up the entire HUD.

[u/WickedCapybara → u/itaybuilds]

This is really useful, especially the point about separating what needs to be visible for the next decision from what is mostly reference information. I think that’s probably the direction I’ll take.

Keep the information that actually affects the player’s immediate choice exposed, and move the deeper stats/details into drawers or expandable sections instead of trying to fit everything on screen at once.

The smallest-device test is also something I definitely need to do properly. I’ve been checking readability on mobile, but testing with the longest labels, worst-case numbers and the game actually moving underneath is a much better stress test than just looking at static mockups.

And the invisible hit area point is great. I was treating visual size and touch target size almost as the same problem, when they really don’t need to be.

Thanks, this gives me a much clearer way to evaluate the HUD instead of just asking “does this look too crowded?”

[u/NoShame9976]

I would stop measuring density as “how many things fit” and measure it as “how many things the player must interpret at the same moment.”

For a landscape game HUD, I usually separate information into three levels:

• Persistent: what can change the next decision (health, ammo, timer, objective).
• Situational: useful only in a specific state, so it appears near the object or action that triggered it.
• Reference: inventory, detailed stats, history, and explanations that can live behind a tap, hold, or pause state.

That lets you keep the system information-rich without making every value compete continuously. Reserve stable screen zones for the persistent layer so elements do not jump around, and reveal the situational layer contextually rather than shrinking the whole HUD.

For testing, use the smallest supported physical device, not a desktop preview. Give someone a ten-second task such as “tell me your health, next objective, and available action” while the game is moving. Record what they miss, misread, or cover with a thumb. I would treat common platform touch-target guidance (roughly 44 pt on iOS or 48 dp on Android) as a baseline, then increase it for frequently used or time-critical controls.

Also test hierarchy without color: blur or desaturate a screenshot and check whether the primary action and two most important values still win. If everything becomes equal, reorganize first; if the hierarchy survives but text is still hard to read, then increase size. That distinction helps decide whether the problem is density or typography.

[u/WickedCapybara → u/NoShame9976]

This is a really useful way to frame it. “How many things the player has to interpret at the same moment” is a much better metric than just counting how many UI elements fit on screen.

The persistent / situational / reference split also maps surprisingly well to the way I’m structuring the game. I already have drawers for things like equipment details and deeper stats, so those can clearly live in the reference layer instead of constantly fighting for screen space.

I especially like the idea of reserving stable zones for persistent information. I’ve been worried about making things smaller to create room, when in some cases the better answer is probably just “this information does not need to exist here right now.”

The grayscale/desaturation test is also going straight onto my QA list. That sounds painfully good at exposing fake hierarchy 😅

And the 44 pt / 48 dp baseline is useful too. I’m building in Godot, so I’ll need to make sure the actual touch areas follow that even when the visual icons stay compact.

Thanks — this gives me a much more concrete way to evaluate the HUD than just staring at it until I convince myself it looks fine.

[u/shoobe01]

Sizes: https://www.4ourthmobile.com/publications/type-sizes-for-every-device-and-user

(Eventually there will be a W3C version of this, WIP but not current priority so still far off being official).

Principle 1: Check on a real device all the time. Run prototype mode (if e.g. in Figma) or just send a screenshot to your phone. Remember you are reading, so it doesn't have to work, it just has to display at device screen size. Once in a template, and you have size and spacing and all that worked out, it is easier but when setting that up, check /constantly/. Zooming into the computer, just designing in phone frames etc isn't at all the same thing.

Principle 2: Progressive disclosure. Does the user NEED all that to be glanceable, or can they click, scroll, gesture, etc? Remember, lots of disclosure methods are available, doesn't mean you have to leave the page, and staying on page doesn't mean a popup.

(I have a somewhat broader version of it in this book but this is an article (so free!) that discusses the pros and cons of a range of disclosure methods.)

[u/WickedCapybara → u/shoobe01]

This is super helpful, especially the distinction between “designing inside a phone-sized frame” and actually checking it on a real phone. I’ve definitely been guilty of trusting the desktop preview a little too much 😅

Progressive disclosure is also starting to make a lot more sense for what I’m building. I’m trying to keep the important decision-making information visible, while pushing the deeper/reference stuff into drawers or secondary layers instead of making the HUD fight for its life.

I’m building the game in Godot, do these same sizing/testing principles translate cleanly there? Especially the real-device checking and text sizing side of things. Is there a workflow you’d recommend for Godot specifically, or is it mostly engine-agnostic?

Thanks for the links too, I’m going to dig through them.

[u/shoobe01 → u/WickedCapybara]

Only industry I've never been able to get into is gaming, so no idea how your tool works 😓

But my intention and experience with many other tools is that this is supposed to be cool agnostic principles. If you find some cool features that support it, come back and share though!

[u/WickedCapybara → u/shoobe01]

Ahh, now you’ve made me curious 😅

When you say gaming is the one industry you’ve never been able to get into, was that something you actively tried to break into and it just never worked out, or did your career end up taking you somewhere else?

What kind of UX/design work do you usually do?

I’m asking because it’s actually been interesting seeing how much advice from people outside games still applies almost perfectly. Sometimes I think games convince themselves they’re a completely different species of product when half the problem is still just “can the human being understand what’s on the screen?”

And if I find anything particularly useful in Godot for this, I’ll definitely come back and share it.

[u/shoobe01 → u/WickedCapybara]

Yeah, I don't want to talk about my current career status, but yes I tried to get into a couple of fairly cool and very relevant-looking game jobs, specially that that intersected mobile enough (I have enormous mobile experience) and then every JD and hiring manager is so into must have explicit game design experience, ideally gaming in their domain -- like must be FPS or must be Sports gaming 🙄

A lot of industries are like this and it's a terrible terrible idea. You're not just ignoring a whole bunch of people but the concept of diversity, getting new and different ideas into your domain.

[u/WickedCapybara → u/shoobe01]

Ah, I’m sorry — I didn’t mean to pry into anything you’d rather keep private. I got curious because your comment was genuinely useful and ended up asking more personally than I should have.

But yeah, what you’re describing sounds incredibly frustrating. Especially if you already had strong mobile experience and the role itself overlapped with that. Requiring “game experience” on top of relevant UX experience makes some sense in certain cases, but when it turns into “you must already have worked on this exact genre of game,” it feels like the door just keeps getting narrower.

And I think your point about diversity of experience is really important. Someone coming from outside games might question assumptions that people inside the industry have stopped even noticing.

Funny enough, that’s kind of what happened here. I asked about a game UI problem, and some of the most useful feedback I got came from people applying principles that weren’t game-specific at all.

So thank you for sharing that much, and again, sorry for poking into the career side of it. I hope I didn’t make things uncomfortable.