Mobile game UI design: thumb zones, safe areas and the screens that pay

What actually changes on a phone

Five constraints do most of the work. None of them are aesthetic, and all of them are settled before a single pixel is drawn.

1. The input device covers the screen. A cursor is one pixel. A thumb is roughly a centimetre wide and attached to a hand that hides whatever is under it.
2. Reach is limited. The corners of a modern phone are genuinely hard to touch one-handed, and the far top corner is close to impossible.
3. The rectangle is not the screen. Notches, camera cutouts, rounded corners and the gesture bar all take bites out of it, and they differ per device.
4. The viewing conditions are hostile. Sunlight, a smeared screen, a bus, one eye on something else. Contrast that passes indoors fails outdoors.
5. Sessions are short and interrupted. A phone game is played in three-minute pieces between other things, so the interface has to re-orient a returning player instantly.

Every recommendation below comes out of one of those five.

The thumb map: where controls can actually go

Hold a phone in one hand and sweep your thumb. The area it covers comfortably is an arc, roughly centred on the bottom corner of the side you hold it, and it does not reach the top of the screen at all. That arc is the single most useful piece of layout information you have.

The most common mobile layout mistake is a close button alone in the far top corner of a full-screen panel. It is the hardest pixel on the phone to reach, and it is the control every player needs. Keep it in the corner if the convention demands it, but also let a tap outside the panel dismiss it, and never make the corner the only way out.

Safe areas: the screen is smaller than the screen

Since notched displays arrived, the usable rectangle has been a per-device value the operating system reports at runtime. Design against the safe area and let the background fill the rest, rather than designing against the full frame and hoping.

• Top inset: the status bar plus the notch or camera cutout. Nothing readable goes there, and nothing tappable goes beside the cutout.
• Bottom inset: the home indicator or gesture bar, around 34 points on current iPhones. A button under it gets swiped instead of pressed.
• Rounded corners: the corner radius clips content. Keep a margin so a counter is not sliced diagonally.
• In landscape the insets move to the sides, where racing and action games like to put their controls.
• Tablets are a different aspect ratio entirely. A 4:3 tablet next to a 20:9 phone will break any layout that assumes a fixed height.

The practical rule: build a full-bleed background layer, then place every interactive and readable element inside a safe-area container with its own margin. That is one decision at the start of a project, and it removes an entire class of device-specific bugs. The panel set in the Cartoon Space UI kit is built this way, so the same screens survive a notch, a cutout and a tablet without anything being redrawn.

Touch targets and the cost of a missed tap

Apple's guidance is a minimum of 44 × 44 points, Android's is 48 × 48 density-independent pixels. Those are minimums written for productivity apps, where a mistake costs a tap. In a game where a mistake costs a run, go bigger.

The hit area and the artwork are separate things. A 40-pixel icon can sit inside a 56-pixel transparent button, and the player feels the difference without ever seeing it. This is the cheapest quality improvement available on mobile, and it costs nothing but the decision to specify it.

Density: what to cut when the screen is six inches

A monitor at arm's length and a phone in a hand can hold a similar number of pixels and nothing like the same amount of information. Shrinking a PC layout is how mobile interfaces end up looking cheap: everything becomes too small and too close together at the same time.

• Show one thing per screen. Where PC puts a list and a detail panel side by side, mobile shows the list, then the detail. Tabs and sheets are not a compromise, they are the correct pattern.
• Cut the tier-three information. If the player consults it once a session, it belongs behind a tap. The three-tier hierarchy in Seven HUD mistakes applies here with less room for mercy.
• Type has a floor. Around 14 to 16 points for anything a player reads, larger for anything they read while moving. Below that you are not designing, you are hiding.
• Numbers get shorter. 12.4K, not 12,437. Precision nobody uses costs width you do not have.
• Icons need labels, or a tutorial. A bare icon set is a memory test, on a screen too small for tooltips.

Portrait or landscape, decided once

This is an early decision with consequences everywhere, and changing it later is close to a redesign. Portrait is one-handed, matches how the phone is already being held, and suits vertical lists and tap-driven play. Landscape gives you the width for a world view and two-thumb control, and asks the player to commit to the session.

Supporting both is a real cost, roughly a third again on layout work, because it is two layouts rather than one that rotates. It is usually worth it for menu-heavy games and rarely worth it for action games. Cartoon Racing plays in landscape with menus that stay comfortable in the hand, which is the compromise that most often survives contact with a schedule.

The screens that carry the revenue

On a premium PC game the main menu is the front door. On a free-to-play mobile game the front door is the first session, and the money is made on three or four screens that most teams design last. Budget accordingly.

1. 01

   The first sixty seconds

   From the tap on the icon to the player doing the fun thing. Every extra splash, login prompt and permission dialog in that path costs installs that never become players. This is the highest-value sequence in the entire game.

2. 02

   The end-of-run screen

   The most viewed screen in the game after the play surface itself. It has to show what happened, what progress was made, and what to do next, in that order. This is where the retry loop is either tight or broken.

3. 03

   The shop and the offer

   Every currency, price and bundle in the game passes through here, and confusion costs conversions more reliably than pressure wins them. The economy underneath those prices is its own design problem. That has its own article: monetisation screens players do not resent.

4. 04

   The progression screen

   The upgrade tree, the collection, the roster. This is the reason players come back tomorrow, so it needs to be legible at a glance and satisfying to open.

On mobile the main menu is a corridor. Design the room the player actually spends time in.

Feedback has to work harder

The thumb covers the button it is pressing. On a mouse-driven interface the cursor confirms the target and the hover state confirms the intent. Mobile has neither, so that confirmation has to be rebuilt somewhere the finger is not.

• Show the press state outside the contact patch: a border, a glow, a scale change, something visible around the thumb rather than under it.
• Acknowledge within about 100 milliseconds, before the action resolves, or the player taps again.
• Use haptics for the moments that matter, sparingly. A short tick on a purchase confirmation or a hit lands well. Constant vibration gets the game uninstalled.
• Animate transitions with direction. Where a screen comes from tells the player where they are, and on a small screen that is often the only navigation cue they get.
• Never put a confirmation button exactly where the previous button was. Double taps happen, and an accidental purchase becomes a refund and a one-star review.

Daylight, dirt, and one eye elsewhere

Test in sunlight. Not as a metaphor: take the device outside. Contrast that felt subtle and premium on a calibrated monitor in a dark studio is invisible on a phone at a bus stop, and that is where a large share of your sessions happen.

• Give text its own contrast, from a scrim or an outline, rather than borrowing it from the artwork behind it.
• Test at half brightness. Battery saving and auto-dimming are the normal state of a phone, not the exception.
• Do not rely on colour alone for state. Daylight takes saturation first. See game UI accessibility.
• Check with the screen slightly dirty and held at an angle, which is how a real phone is used.

A one-device test that finds most of it

Twenty minutes, one phone, no equipment. I run this on every mobile project before anything is called finished.

1. Play one-handed for five minutes. Note every control you had to shift your grip to reach.
2. Do the same with the other hand. Note what got worse.
3. Take the phone outside and photograph the HUD. Is everything still readable?
4. Open every full-screen panel. Can each one be dismissed without reaching the far top corner?
5. Check every screen on a device with a cutout and one without, in every orientation you support.
6. Find the two nearest tappable elements in the game and measure the gap. Under 8 dp is a misfire waiting to happen.
7. Tap the primary action twenty times quickly. Does anything double-fire?
8. Look at the end-of-run screen. Can a returning player tell what happened and what to do next within two seconds?
9. Reinstall and play the first sixty seconds as a new player. Count the taps before the fun starts.
10. Hand it to someone who has never played, and say nothing for two minutes.