The main menu is the first thing every player sees and the last thing most teams design. That ordering is backwards and it shows in the results.
Menus get treated as connective tissue, the plumbing between the parts of the game that matter. But the menu is where a returning player forms their impression of whether this game respects their time, where a new player decides whether they can handle this, and where your inventory system either works or quietly ruins an otherwise good game. This is a guide to designing them properly.
What the Main Menu Is Actually For
Ask a team what the main menu does and you get "it is the hub." That is a description of its shape, not its purpose.
The purpose is throughput. Menus are one slice of the wider interface problem we map out in our guide to game UI design, but they have rules of their own. A returning player has decided to play. Every additional input between that decision and the game starting is friction applied to someone who was already sold. The main menu is not an opportunity. It is an obstacle you are obligated to keep short.
Which produces one hard rule: Continue belongs at the top, selected by default, reachable in one input. If a returning player has to navigate to resume, the menu is failing.
This rule gets violated constantly, and not by accident. The main menu is prime real estate and every stakeholder knows it. The store wants a promotion there. Live ops wants the news feed there. Marketing wants the season trailer autoplaying. Each of those requests is individually reasonable and collectively they produce a screen where the player has to hunt for the button that starts the game they paid for.
The honest framing for that conversation: every element you add to the main menu is a tax on the players who are most engaged, in order to reach the players who are least. Sometimes that trade is worth making. It should be made deliberately, with someone naming the cost, rather than by accretion.
Main Menu Patterns That Hold Up
Vertical lists remain the default for good reason. They map cleanly to a d-pad, they scale to any string length, they localise without breaking, and players have thirty years of trained expectation for them. They are boring and they work.
Radial and spatial menus look better in a trailer and cost more in every other dimension. They are harder to localise, harder to extend, and they punish the player with a memory requirement. They earn their place when the menu is small, fixed, and diegetic to the fiction. They do not earn their place because someone saw a nice one on Dribbble.
Scene-based menus, where the menu is a 3D space you move a camera through, are increasingly common and increasingly a trap. They look extraordinary. They also mean every menu interaction is now gated on load times and camera movement, and they make adding a new option a level design task. Beautiful, slow, and inflexible. Choose knowingly.
Inventory: The Hardest Screen in Your Game
Nothing else in a game interface has to do this much at once.
An inventory screen has to let the player see what they have, find a specific thing, compare two things, understand what a thing does, and act on it. Those are five different tasks with five different optimal layouts, and you have one screen.
It gets worse. The content is variable length, so your item name is four characters or forty. The content is variable quantity, so your player has six items or six hundred. The content is compared on multiple axes, so your player needs to see damage and weight and value and rarity simultaneously. And all of this has to work with a d-pad.
The persistent overlay during play has a separate rulebook, which we cover in our guide to game HUD design. Menus are the opposite problem: they interrupt play rather than overlay it, so they can afford density that a HUD never can. The patterns that survive contact with reality:
Grid plus detail. A grid of items on one side, the selected item's full detail on the other. This works because it separates browsing from evaluating. The grid is optimised for scanning, the panel is optimised for reading. Trying to do both in one place produces a grid where every cell has eight numbers on it and nobody can scan anything.
Comparison against equipped. When the player selects an item, show the delta against what they currently have, not just the item's absolute stats. Players do not want to know the sword does 47 damage. They want to know it does 6 more than the one in their hand. Making the player do arithmetic is a design failure that shows up as time-in-menu and reads as depth.
Sort and filter that are actually reachable. On controller, a filter buried behind a shoulder button and a submenu might as well not exist. If your inventory can exceed one screen, filtering is a primary action, not a secondary one.
Consistent slot geometry. Variable-size inventory grids, where a rifle takes four cells and a potion takes one, are thematically satisfying and a usability tax. They make scanning harder, they make the layout reflow unpredictably, and they turn inventory management into a packing puzzle. That is a legitimate design choice if the packing puzzle is the game. It is a mistake if it is not.
Menu Depth Is the Enemy
Every level of menu hierarchy loses you players. This is not a controversial claim in product design and it is somehow controversial in games, where deep menu trees get defended as depth.
The cost is worse on controller than on mouse. With a cursor, a three-level menu is three clicks and the player can see where they are going. With a d-pad, it is three levels of traversal, each with its own focus order, and the player is building a mental model of a tree they cannot see.
The practical constraint: if a player uses something every session, it should be at most one level deep. If they use it every few sessions, two. Three levels is for things that are configured once and forgotten, which is mostly settings.
Nielsen Norman Group's work on progressive disclosure is the relevant discipline here, and the framing is useful: the question is not how to organise everything, it is what does not need to be visible yet. Menus get deep because teams organise instead of subtract.
Controller Navigation Is a Design Deliverable
This is where menus break in ways that are expensive to fix.
Every controller-navigable screen needs three things specified in the design file, not discovered in engineering:
Focus order. Which element is next when the player presses down, up, left, right, from every element. In a grid this is implicit. In a mixed layout with a list, a panel, and a row of tabs, it is not, and if you do not define it the traversal will be whatever the DOM order or the instantiation order happened to be.
Wrap behaviour. At the bottom of a list, does down do nothing, or wrap to the top, or jump to the next region? All three are defensible. Inconsistency between screens is not, and inconsistency is what you get by default.
Default selection. What is focused when the screen opens. This is the single highest-value one, because getting it right means the most common action is zero presses away. Getting it wrong means every player pays a traversal tax on every visit.
Microsoft's Xbox Accessibility Guidelines cover input requirements alongside their text size minimums, and the Game Accessibility Guidelines are explicit that every area of the interface must be reachable with the same input method as the gameplay. That sounds obvious until you audit a shipped game and find a settings panel that requires a mouse.
Settings: The Screen That Gets Audited
Nobody prioritises settings. Every accessibility review starts there.
The things that belong in it are not mysterious and they are published. Remappable controls. Text size options. Subtitle options with background and size control. Colour-blind consideration. Sensitivity adjustment. The Game Accessibility Guidelines sort these into basic, intermediate, and advanced tiers, and the basic tier is genuinely basic. Most shipped games still fail parts of it.
The argument for taking this seriously is not compliance, though platform holders increasingly surface accessibility tags in their stores. The argument is that nearly everything on that list improves the experience for players without disabilities too. Bigger text helps everyone on a couch. Remappable controls help everyone with a preference. Subtitle backgrounds help everyone playing with a sleeping housemate.
Menus Carry Tone, and That Is Not a Distraction
Everything above is about function, which risks implying that menus should be a spreadsheet. They should not.
The menu is the most sustained look at your game's identity that a player gets outside of play itself. A survival horror menu and a farming sim menu are solving nearly identical information problems and should not resemble each other in any way. The typography, the motion, the sound of moving between options, the sound of confirming, all of it is telling the player what kind of experience this is before they experience it.
Sidney Rhoads, a product designer on our team, made the relevant point in a conversation about psychology in UX design. She noted that people are far less logical than they believe, that they become emotionally influenced by very subtle factors like colour and appearance, and that they weight first impressions disproportionately in how they judge the whole. Your menu is the first impression. It is doing emotional work whether you designed it to or not.
The reconciliation between tone and function is not a compromise. Put the personality in the motion, the sound, the typography, and the framing. Keep the hierarchy and the traversal ruthlessly conventional. Players will read the tone and never notice the convention, which is exactly the outcome you want.
The Menu Failure That Costs the Most
It is not any specific screen. It is accretion.
Eric Lee Smith, a game designer with award-winning titles behind him, described the dynamic to us on our Visionaries podcast as a law of development rather than a criticism: the longer a product is in development, the more complicated it becomes. Menus are where this is most visible, because a menu is the place a new feature goes when nobody has thought about where it should live.
Every live game accumulates menu entries. Every event adds a tab. Every partnership adds a banner. Nobody is assigned to remove, and the removal conversation is always harder than the addition conversation because removal has an identifiable loser.
The counter-practice is scheduling subtraction. Not "we should simplify the menu sometime," which never happens, but an actual review where the default is removal and each element has to argue for its place. Studios that do this ship menus that stay usable through year three of live ops. Studios that do not ship menus that need a rebuild.
What This Looks Like in Practice
Buildbox is a no-code game creation platform used by millions. Genuinely powerful. The original interface presented all of that power the moment a user signed in, and they left before they built anything. The value was real and invisible.
The rebuild started from one question: what does a meaningful first success look like for a new user? Everything that was not that got moved later in the sequence. Not deleted. Moved. The first thing a new user does is make something, not tour a menu. That change moved first-success completion by 41%.
The menu lesson generalises well beyond creation tools. The interface's first job is not to display the product's capability. It is to get the player to the part where the capability is worth understanding. Menus that lead with everything lead to nobody.
Final Thoughts: Game Menu Design Is Respect, Rendered
Players do not consciously evaluate menus. They form an impression in about two seconds and it is roughly binary: does this game respect my time, or not.
A menu where Continue is at the top, where the inventory sorts sensibly, where settings has the options you need, and where nothing is three levels deep reads as competence. It signals that someone on this team thought about the player as a person with a limited evening rather than a metric to be maximised.
The inverse also reads instantly. A main menu where the store is louder than the play button tells the player exactly what this game is optimised for, and they are not wrong. Menus are the most honest part of your game, because they show what you decided mattered. It is worth deciding carefully.
Get Your Menus Reviewed by People Who Do This
If your inventory is a known problem nobody has had time to solve, or your main menu has accreted past the point of rescue, or you are heading into a console port and your controller navigation is undefined, we can help. Wandr has designed interfaces for game creation platforms, real-money gaming products, and esports tools. See how our game UI/UX design team works, or send us the build and we will come back with what we would fix first.
