Designing game UI for controllers: focus, navigation and console requirements

Focus is not hover

This is the mistake underneath most of the others. A mouse interface has hover, which follows the pointer and disappears when it leaves. A controller interface has focus, which is a persistent property of exactly one element on screen at all times, and it is the player's only way of knowing where they are.

• Focus always exists. There is never a moment on a controller-driven screen where nothing is focused. If a panel opens, focus moves into it. If it closes, focus returns to what opened it.
• Focus has to be visible from across the room, not a subtle tint. It is the cursor, and a cursor you cannot find is a broken interface.
• Focus is different from selected. A toggle can be on while focus is elsewhere; a tab can be the active tab without holding focus. Designs that use one treatment for both make it impossible to tell what a press will do.
• Focus survives navigation. Coming back to a list should return you to where you were, not to the top of it.

The states every control actually needs

A design that ships one state per button will be built as one state per button. This is the table I put on the handoff for every console project.

Disabled items should be skipped by navigation, not focusable dead ends. If an option matters enough to show while unavailable, it needs a reason attached, because on a controller the player cannot hover it to find out.

Navigation is a map, not a guess

Engines will auto-generate navigation from screen positions. It works for a simple vertical list and falls apart everywhere else: grids with a wider last row, panels with a sidebar, anything centred, anything that appears conditionally. The fix is to specify it, and it takes about ten minutes per screen.

1. First focus. Which element holds focus the moment this screen opens? Usually the most likely action, not the first item in the list. On a main menu that is Continue, not New Game, as covered in main menu design.
2. The order. Where does up, down, left and right go from each element? Write it on the design. For a grid, say what happens at the ragged edge of the last row.
3. Wrapping. Does the bottom of a list wrap to the top? Vertical lists usually yes, horizontal tab rows usually no. Pick one rule and use it everywhere.
4. Shoulder buttons. On console, L1 and R1 move between tabs and categories. If your design has tabs and no shoulder mapping, you have designed a mouse interface.
5. Return focus. When a dialog closes, focus goes back to the element that opened it. Every time.

The WAR options screens are built around this: categories on the shoulders, a single focused row in the panel, and every control on the screen reachable without ever passing through a dead end. That is what makes a settings screen with fifty options feel navigable with a stick.

Button glyphs: never draw them, look them up

Confirm and cancel are not the same button everywhere. On Xbox, confirm is the bottom face button. On Nintendo hardware the physical positions of A and B are mirrored relative to Xbox. Sony standardised on cross for confirm on PlayStation 5, after years of that varying by region. A PC player might be on any of those pads, or a keyboard, and they can remap it.

• Bind prompts to actions, not to letters. The interface asks for confirm, and the glyph system answers with whatever that is on the current device.
• Detect the active device and swap glyphs live. A player who unplugs a pad mid-session should see keyboard prompts on the next screen, not before they act.
• Respect remapping. If a player rebinds confirm, the prompt has to follow. Hardcoded glyphs make your own accessibility settings lie to the player.
• Give glyphs their own sprite set with consistent optical size, so a round PlayStation glyph and a letter-based Xbox glyph do not change the width of the prompt bar.
• Keep the prompt bar in one place, bottom of the screen, same order on every screen. It is the closest thing a console interface has to a menu bar.

Practically this means the design delivers a prompt component with slots, not a picture of a button. It is the difference between one system and forty screens that each need editing when a platform is added.

Ten feet away, on a television

A console player sits two to four metres from the screen. Everything that was comfortable on a desk monitor is now roughly half the apparent size, and televisions add their own problems on top.

The same discipline that keeps a racing HUD readable at speed keeps a console menu readable across a room: contrast that belongs to the element rather than borrowed from the background, and a hierarchy strong enough to survive a bad panel. That was the whole design constraint on Nocturne Drive.

The screens that cannot survive a controller

Some patterns from PC and mobile simply do not translate, and every one of them shows up in ports.

• Free-floating cursors. An emulated mouse driven by a stick is the last resort, not a design. If a screen genuinely needs one, such as a map or a large strategy board, add snapping to points of interest.
• Drag and drop. Replace it with pick up, move focus, place. Two presses beat a held stick every time.
• Text entry. Every text field means a platform keyboard and a slow, painful interaction. Cut the field, or offer presets, or use the platform's native input dialog rather than building your own.
• Dense tables and spreadsheets. A strategy game's data screens need a focus-friendly rebuild, usually as a list with a detail panel.
• Right-click, middle-click, hover tooltips, and scroll wheels. Each of these needs an explicit controller equivalent and a visible prompt for it.
• Timed inputs that assume a mouse's precision. A stick has an acceleration curve and a dead zone. Anything requiring pixel accuracy needs a bigger target or a snap.

If a screen needs a cursor, it was designed for a different machine. Rebuild the screen, do not simulate the mouse.

Steam Deck and handhelds

The handheld PC has quietly become a console tier of its own, and it fails games for reasons that are almost entirely interface reasons: text too small on a seven-inch screen, menus that need a mouse, no sensible default controller mapping, launchers and dialogs that assume a keyboard.

1. Check every screen at 1280 × 800 on a small panel. The usual failure is not layout, it is type size. Design body text with that panel in mind and it is comfortable everywhere.
2. Everything must be reachable with the pad, including first launch, settings, save management and any error dialog.
3. Provide a sane default controller layout, so the player never opens a mapping screen before they play.
4. Show the right glyphs. A handheld with console-style controls showing keyboard prompts reads as unfinished.
5. Watch persistent brightness and contrast. Handhelds are played in variable light and on battery, and heavy interfaces cost both.

What certification actually checks

Each platform holder publishes its own technical requirements under NDA, and the specifics differ, but the interface-facing categories are consistent enough to plan around. None of these are difficult if they are known at design time, and all of them are expensive if they surface in a submission failure two weeks before launch.

The practical takeaway for a designer: every one of those categories needs a screen or a state that nobody puts on a screen list. The controller disconnect overlay, the storage full dialog, the save-in-progress indicator. Add them to the list at the start and they cost a day. Add them at submission and they cost a milestone.

How I run a controller pass

1. 01

   Map the graph

   Every screen gets its first focus, its navigation order, its wrap rule, its shoulder mapping, and its back behaviour written directly on the design. This is the deliverable that most changes what gets built.

2. 02

   Build the states

   Focus, pressed, selected, focused-and-selected, disabled, for every component in the kit rather than every screen. Six states on twelve components covers a hundred screens.

3. 03

   Rebuild what needs a cursor

   The screens from the list above get redesigned around focus, not adapted. Usually a handful per game, and they are the ones players complain about in reviews.

4. 04

   Add the prompt system

   One prompt bar component, action-bound, device-aware, in a fixed position, with the platform's own glyph sets slotted in.

5. 05

   Fill the gaps in the screen list

   Disconnect, suspend, save failure, storage, network loss. Designed once, in the same visual language as everything else.

6. 06

   Test in the hand, on the hardware

   Across the room on a TV, and on a handheld at native resolution. Every screen, pad only, keyboard unplugged, no exceptions.