Settings Menus Are Design, Not Plumbing

Settings Menus Are Design, Not Plumbing

September 1, 2026 Off By Tobias Lindqvist

I remember sitting in a dark room at 3:00 AM, staring at my own build, trying to figure out why my playtesters were spending ten minutes just trying to equip a basic sword. It wasn’t a bug in the code; it was a failure in the logic. Most people think UI design is about making things look “clean” or “modern,” but that’s a lie. When you’re figuring out how to design menus people can use, you aren’t just arranging icons on a screen; you are setting the terms of engagement. If your menu is a labyrinth, you aren’t giving players choices—you’re giving them homework.

I’m not here to give you a lecture on color theory or the golden ratio. I’ve spent too many years breaking my own games to care about academic perfection. Instead, I want to talk about the actual friction that kills player momentum. I’m going to show you how to treat your UI as a series of clear, concise commands that respect the player’s time. We’re going to look at the cost of a click and learn how to build interfaces that stay out of the way so the actual game can finally breathe.

Table of Contents

Information Architecture as a Silent Command

Information Architecture as a Silent Command.

When I’m building my own project, I stop thinking about “folders” and start thinking about mental energy. Information architecture isn’t just about where the buttons live; it’s about the invisible path you’re forcing the player to walk. If I bury the gear enhancement screen under three layers of sub-menus, I’m not just being “organized”—I’m telling the player that upgrading their sword is a secondary priority. You are essentially imposing a cognitive load in navigation that drains the player’s focus before they even get to the actual gameplay.

Most developers treat menu hierarchy and organization like a filing cabinet, but in an MMO, it’s more like a conversation. If a player has to pause their combat flow to hunt through a sprawling list of tabs, the “sentence” you’re writing is: Stop playing and start managing. You want your UI to be a whisper, not a shout. A well-designed architecture should feel like it’s anticipating the player’s next move, rather than acting as a gatekeeper that demands they solve a puzzle just to check their mana levels.

The Cognitive Load of Navigational Friction

The Cognitive Load of Navigational Friction.

When you pile too many layers of sub-menus onto a player, you aren’t just making the UI “complex”—you’re actively draining their mental battery. Every time a player has to pause their gameplay to figure out if a specific setting is under “Options,” “System,” or buried in a nested “Advanced” tab, you are increasing the cognitive load in navigation. They aren’t thinking about the boss fight or the loot drop anymore; they are thinking about your menu. If they have to expend more energy navigating your UI than they do playing the actual game, you’ve already lost them to a YouTube video or a different tab on Chrome.

This friction is a silent killer for player retention. I’ve seen it in the private servers I play: a game with brilliant combat mechanics that feels like a slog simply because the menu hierarchy and organization are a mess. You might think a massive, sprawling tree of options feels “feature-rich,” but if a player can’t find the “Unbind Key” button in three seconds, that feature is effectively invisible. You aren’t providing depth; you’re just creating a scavenger hunt that nobody asked to play.

Five Ways to Stop Your Menus from Gaslighting Your Players

  • Stop hiding the important stuff behind layers of “discovery.” If a player needs to check their cooldowns mid-fight, and that menu is buried under three sub-tabs, you haven’t designed a discovery mechanic; you’ve designed a barrier. Every click you add is a tax on their attention, and in a high-stakes moment, they’ll stop playing your game and start fighting your UI.
  • Respect the hierarchy of urgency. Not all information is created equal. A player’s health bar and their current quest objective are fighting for the same mental real estate as your “Settings” button. If your menu layout treats a “Change Language” toggle with the same visual weight as a “Critical Low Health” warning, you’re sending a message that nothing in your game actually matters.
  • Design for the “Muscle Memory” loop. In an MMO, players don’t read; they react. If your inventory management requires a different kind of click or a different navigational logic than your skill tree, you’re forcing the brain to switch gears constantly. Good menus feel like an extension of the character’s hands, not a separate software suite they have to learn.
  • Avoid the “False Choice” trap in navigation. When you present a player with a menu that has four options, but two of them lead to the same functional outcome, you aren’t giving them agency—you’re giving them confusion. A menu should be a clear path of intent. If the player has to pause to wonder “which one of these actually does what I want?”, you’ve already lost the flow.
  • Watch out for “Menu Bloat” as a way to mask shallow systems. I see this all the time in mid-tier RPGs: they add more tabs and more sub-menus to make the game feel “deep,” but it’s actually just clutter. If a menu doesn’t force the player to make a meaningful decision or provide vital information for their next move, it’s just noise. And noise is the fastest way to make a player alt-f4.

Stop Treating Your UI Like a Filing Cabinet

Stop Treating Your UI Like a Filing Cabinet.

At the end of the day, designing a menu isn’t about finding the most efficient way to store data; it’s about managing the player’s mental energy. We’ve talked about how information architecture acts as a silent command and how every extra click adds to a cognitive tax that players eventually stop paying. If your menu structure is a labyrinth, you aren’t just making it “hard to navigate”—you are actively telling your players that the most important part of your game is fighting with the interface rather than engaging with the world you built. Every layer of friction is a withdrawal from the player’s bank of patience, and eventually, they’re going to hit zero.

When I’m working on my own project, I constantly have to ask myself: is this button here to help the player, or is it just here because I thought it looked “complete”? It’s easy to get lost in the weeds of feature creep, but remember that a menu is a conversation between you and the person holding the controller. If you want them to feel powerful, don’t bury their abilities under five sub-menus. If you want them to feel immersed, don’t break the flow with a clunky, jarring UI. Design your menus to be invisible facilitators, not obstacles. Because when the UI finally works, the player won’t even notice it—and that is exactly when they’ll actually start playing your game.

Frequently Asked Questions

If every menu is a "sentence," how do I know when I'm accidentally telling my players to stop playing the game and start playing my UI instead?

You know you’ve messed up when the player’s mental model of the game shifts from “I am a hero exploring a dungeon” to “I am a clerk filing paperwork.” If they’re pausing to stare at a sub-menu instead of reacting to a boss mechanic, your UI has hijacked the gameplay loop. When the friction of navigating a list becomes more cognitively demanding than the actual combat, you aren’t designing a tool anymore; you’re designing a chore.

At what point does "organizing information" cross the line into "adding unnecessary clicks" that just kill the game's momentum?

It crosses the line the moment the menu stops being a tool and starts being a gatekeeper. If I have to navigate three sub-menus just to check my cooldowns, that’s not “organized architecture”—that’s a tax on my focus. You’re effectively telling me that looking at my character is less important than the structure of your folders. When the friction of finding the info outweighs the value of the info itself, you’ve killed the flow.

How do I balance a clean, minimalist aesthetic with the reality that players actually need a lot of data to make meaningful decisions in a high-stakes loop?

The mistake is thinking “minimalism” means “hiding things.” If a player has to pause a high-stakes fight to hunt through three sub-menus for their cooldown timers, you haven’t designed a clean UI; you’ve designed a barrier. Minimalism should be about hierarchy, not absence. Use “progressive disclosure”—keep the screen quiet when the player is idling, but flood them with the specific data they need the second the tension spikes. Don’t hide the data; just stop shouting it at them when they’re just walking to a vendor.

About Tobias Lindqvist

Every system in a game is a sentence about what the designer wants you to do. Grind is a sentence. So is a queue timer, a loot table, a guild bank permission screen. I write about what those sentences actually say, and why so many of them say something the designer did not intend. I build a game alone, badly and slowly, which means I have made most of these mistakes myself and can tell you what they cost.