Hiding destinations in a menu sharply cuts their use
Aliases: out of sight out of mind · hidden navigation
What it is
Putting destinations in a hamburger menu takes them out of default view: until that control is opened, the functions inside are not on the interface. The hamburger hiding effect is the effect of visibility itself on use. The same function, exposed on a tab bar or sidebar, gets tapped by people who were passing by; once it is inside the menu, only people who already know it lives there still open it. That is separate from whether the glyph looks like anything, and from whether frequent items belong inside.
Why it happens
People choose among the entries they can see. Navigation is browsing, not recall: someone sweeps a row of visible destinations, gets hooked by one, and does not need to be able to name it in advance. The hamburger splits browsing into two stages — first decide whether to open this container, then look inside. The first stage is often skipped, because the current page already completes the main task and opening the menu has no immediate payoff. Inner items then lose the “seen while passing” path. Use concentrates among people who have opened the menu before; curves for newcomers and infrequent users drop.
The extra step also taxes time. Even someone willing to open pays a tap and a shift of attention from content to menu, so postponable functions get postponed — and often never reached in that session. A lab task that says “go find Settings” overestimates discovery, because it has already made the first-stage decision for the participant.
Studying it
Use unprompted find: do not say the entry is in the hamburger; give a goal (change notifications, open saves, switch workspace) and watch whether the first hop hits the menu, whether the goal is met, and how many opens precede abandonment. The control condition exposes the same entries persistently. Dependent variables: time to first discovery, feature use (more meaningful in unprompted live traffic), and later reports of “I did not know that existed”.
An A/B test sits closer to the mechanism: pull one item out of the menu onto visible chrome and see whether that item’s use rises without hurting the main task. Rise without harm means the earlier loss was visibility, not demand.
Where it stops holding
In expert tools and internal systems where the same functions are opened daily, hiding costs less because habit has already skipped the first-stage decision. Settings, legal copy, and rare account items were never meant to be triggered by passing-by, so parking them in a menu hurts use less than parking a main-task entry there. When visible chrome is already full and one more exposed item would wreck legibility, hiding is the lesser harm — but the lost use has to be counted, not treated as “it is still top-level because it is in the menu”. Screen-reader users who can reach the same places via search or commands partly bypass visual hiding; that does not stand in for visual discovery.
Applying it
- List candidate entries by live use, then simulate removing pass-by visibility: anything that is used because it is seen should not go in the hamburger.
- Do not launch a new feature only inside the menu. Give it a period on a visible surface, then decide whether to demote it.
- Do not defend hiding with “architecturally it is still top-level”. Top-level means visible before the menu is opened.
- How to check: give someone new to the product a task with no path spelled out, and count whether the first hop must open the hamburger. Then compare a week of use with that entry exposed. A clear rise after exposure means hiding was eating use, not that people did not need the function.