Each added level costs one more decision and one more wait
Aliases: per-level navigation cost · click-and-wait · serial menu depth
What it is
Every extra level of hierarchy charges the user for two things: another choice among the newly revealed children, and another interval of time—load, render, eyes finding the new menu. Each added level costs one more decision and one more wait names the unit cost of depth. It is not the fact that people abandon deep trees, and not how many items a level can hold.
A four-level tree is not merely “three extra clicks.” It is four judgments in series, with three unusable gaps between them. During a gap the next level cannot be previewed, and undoing the last level costs another wait.
Why it happens
Decision cost comes from uncertainty at the current level. Until the new menu appears, the next level’s options are invisible, so later scent cannot be folded into the present bet; the person can only wager on the labels now in view. Wait cost comes from round-trip latency and page replacement: the previous level has already gone, the next is not yet operable, and the interval is enforced blank. On mobile networks, heavy front ends, and full-page reloads, waiting overtakes deciding and becomes the main term of depth.
The two costs couple. The longer the wait, the less willing people are to revise the last bet—backtracking means paying the wait again—so a wrong decision is locked in by latency. Miller and Kiger’s menu studies already showed depth slowing performance; swap their instant switches for real loads and the same depth costs still more. Depth’s bill is “number of decisions × difficulty of each + number of waits × latency of each,” not a click count.
Studying it
Split an arrival into decision time and wait time; do not report only total completion.
- Paradigms: controlled menu-depth experiments; the same tree under instant switch versus throttled delay; instrumentation that separates “menu visible to click” from “click to next menu visible.”
- Independent variables: number of levels, options per level (held fixed so breadth does not confound), between-level delay, whether child menus are prefetched.
- Dependent variables: decision time per level, wait time per level, whether backtracking is suppressed by delay.
- Methodological note: hover-reveal desktop menus have almost no wait and will understate depth cost for tap-and-replace mobile menus. Prefetch cuts waiting, not deciding. Lab participants know the answer is in the tree and will pay waits more readily than real users.
Where it stops holding
When child menus are already visible (a mega-menu that opens several columns on one screen), the next level has almost no wait, and the decision becomes same-screen discrimination; the unit cost of depth does not apply. Native apps with no between-level load leave only the decision. Autoplay or timed advances are not user decisions. A one-level structure has no “one more level” to add. Very strong scent can drive decision time toward zero while the wait remains—further depth is then expensive in latency, not in thought.
Applying it
- Count levels on frequent paths and measure load at each. Levels × (median decision + median load) is that path’s depth bill.
- Where hover or preview can expose the next options, use it to cut the “bet while blind” decision, not merely to shorten an animation.
- On mobile, avoid tap–replace–tap for more than three levels with no content; prefetch intermediate levels when you can.
- Verify by recording a target task and logging, per level, “menu visible to click” and “click to new menu tappable.” If wait dwarfs decision, fix load first; if decision dwarfs wait, fix that level’s labels and option count. Only when both are long do you cut a level.