Deep menu nesting makes infrequent commands undiscoverable

What it is

Format → Font → Advanced → Kerning parks a twice-a-year command on the fourth level. People do not forget its name; they never walk that corridor. Buried infrequent commands means discovery cost rises with depth, low-frequency commands cannot pay it, and in the user’s model of what the product can do the command might as well not exist. Hard diagonal aiming into a submenu is a motor problem. This entry is the discovery problem: never walking in.

Why it happens

Menu browsing is a breadth-first scan: read the dozen items visible on this level, then decide whether to send the pointer into a submenu. Each level charges an “open, scan, decide” tax, and the submenu covers or crowds out the parent, so looking back costs more. High-frequency commands, even if buried, get their coordinates remembered after a few repeats. Low-frequency commands have no such repeats; the first time they are needed, people scan the top level and one child list. Depth spends that one scan budget, and the command never enters the field of view. Search and a command palette can bypass depth, but only if people already know which word to type. An infrequent function whose name is unknown fails the same way in a deep menu and in a search box.

Studying it

Run find tasks with the target at level 1, 2, or 3, and declare frequency in advance (“you have almost never used this” versus “you use this daily”). Record whether it is found and how many dead-end menus were opened.

Independent variables: depth of the target, items per level, whether in-menu search or a command palette is offered, prior familiarity with the command. Dependent variables: discovery rate, count of wrong submenus opened, time before abandonment, whether people can later say “it lived under this kind of thing.”

A lab that writes “please find Kerning” on the task sheet has already handed over the search term and will overestimate deep discovery. Closer to use is a result description (“make these two letters sit tighter”) with no command name. Do not count “people who knew the shortcut found it” as menu discovery—that is a different channel.

Where it stops holding

Apps whose main discovery path is a command palette or menu search take less damage from depth, but not zero: people still have to know what to type. Expert spatial memory can keep a deep tree alive if the structure stays still; one reshuffle buries infrequent items again. Touch menus have no hover preview of children, so motor cost and discovery cost rise together. Legal and professional tools sometimes bury cold clauses on purpose to reduce misuse; then “undiscoverable” is risk control, not neglect, but another door must exist in docs and settings.

Applying it

• Promote infrequent but independently launchable commands to the second visible level, separated from high-frequency items by a divider, rather than wrapping another “Advanced” level.
• Keep a third level for modifiers that only make sense after an object is selected; pull twice-a-year global commands out of that third level.
• Offer discovery that does not require knowing the name: examples, empty-state links, related items in settings—not only a command palette.
• Verify: give people who have never used the product a result description and no command name, and see whether they can find the target in the menus. Do not close a third-level-or-deeper miss with “put it in Help”; move the item up one level and measure discovery again.

Related

• Within the group: K2.09.1 Group commands by use situation, not by development module · K2.09.3 Command names must match terms used elsewhere in the UI · K2.09.4 Situational items should change availability, not disappear
• Adjacent: E5.12 Menus and Submenus · E5.14 Command palettes
• Search terms: menu depth · command discoverability · buried commands