W5.06.4Menu depth versus settings access costdesign

Deep menu hierarchies make common settings expensive

Aliases: menu hierarchy · settings navigation · access cost · settings IA

What it is

A setting's menu depth (the layers needed to reach it) decides its access cost. When common settings (volume, subtitles, brightness, accessibility) sit three or four layers deep, every adjustment costs multiple clicks and waits, and the cost grows high enough that players give up adjusting—subtitles too small to read but too bothersome to fix, volume too low to hear but left as is. Matching access cost to usage frequency is the first principle of menu information architecture: high-frequency items shallow, low-frequency items deep.

Why it happens

Access cost shapes behaviour along the path of least resistance: when adjustment costs exceed the discomfort's tolerance threshold, users tolerate rather than adjust. The threshold is especially low for common settings—volume and subtitles are things most players adjust at least once (different environments need different volumes), so buried settings mean many players finish the game on suboptimal configurations. Depth also compounds with situational cost: opening a menu mid-game means pausing or exposure (in multiplayer, time spent adjusting is time spent vulnerable), so each extra layer amplifies situational risk—which is why settings needing mid-game adjustment (volume, sensitivity, chat) deserve shallower entry than set-once-at-start items. The pressure toward depth comes from growing settings counts (hundreds in modern games), and sustainable solutions (search, favourites bar, contextual entry points) beat simply reducing layer count.

Where it stops holding

Shallow does not mean everything at the top level—putting all settings on layer one creates the inverse access cost (scanning dozens of items to find one). The goal is "shortest path for the most-accessed items," not "shortest path for everything." Different users have different high-frequency items (streamers adjust audio and capture, colour-blind players adjust colour, PC players adjust keybinds), so a fixed quick bar cannot serve everyone—customisable pinned entries (users pin their frequent items to the menu home) generalise better. Contextual entry points (a settings page popping directly when a mismatch is detected, like an HDR brightness prompt) reduce "find the menu" cost to zero and extend the shallow-frequency principle. Search is highly valuable when settings counts are large, but it depends on users knowing what the item is called—naming conventions (next group) shape search usability.

Applying it

  • Determine high-frequency settings from usage data or player interviews (volume, subtitles, sensitivity, accessibility as universal highs), and place them at menu layer one or provide quick entries.
  • Offer search and category filters for long-tail settings, show each item's menu path beside it (helping users learn the structure), and support hotkeys for settings.
  • Verification: record test players' operation paths for common tasks ("increase subtitle size," "disable camera shake") and count layers and time. Any item beyond three layers or fifteen seconds is buried and needs promoting.

Related

  • Same group: W5.06.1 Pause must truly freeze game state, not just hide the screen · W5.06.2 Save-point predictability shapes risk-taking · W5.06.3 Auto-save and manual save need distinct UI identity
  • Nearby: G2.01 Information architecture and navigation · W8.08 Accessibility settings' discoverability · F1.02 Interface hierarchy and grouping
  • Search terms: menu hierarchy · settings navigation · information architecture · access cost

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/W5.06.4