More items raise both scanning and decision cost
Aliases: Hick's law · visual search cost
What it is
Each extra item on a navigation is another thing to look at and another candidate in the choice set. Count raises scanning cost and decision cost together — not merely a fear of “not remembering”. Sweeping a longer row takes time; choosing among n also takes time. The gain from adding an item must cover both bills, or the product has only moved the choice onto this row.
Why it happens
Scanning grows roughly linearly with visible items: the eyes must cover a longer row or column, and names must be read far enough to tell apart. Decision grows roughly logarithmically (Hick–Hyman): as the set grows, choice reactions slow, provided the options are treated as one choice. After the two costs stack, the “one fewer hop to arrive” from the 8th or 9th item is often eaten by “every arrival is slower”, especially when those items are rarely chosen.
A further layer: more items make names collide or become more abstract, discrimination during the scan worsens, and decision starts at “parse” rather than “recognise”. Cost is therefore not only a function of n, but of name separability. Laying rarely used items in the same choice field as daily ones makes every frequent choice pay tax for the rare.
Studying it
Use a choice reaction: fix the target item, add distractors in the same field, and measure gaze time, arrival time, and wrong taps. Independent variables: visible count, name separability, whether the target is frequent. Dependent variables: time to first-fixate the target, a Hick-style latency curve, neighbour misses.
In a live product use a funnel: after adding an item, does arrival at existing frequent items get slower. Slower, with tiny use of the new item, is everyone paying a scan tax to subsidise a rarely walked door.
Where it stops holding
Once items are grouped, the choice field is no longer a flat n and the curve kinks, because people choose a group and then an item inside it. Experts can skip scanning on items in a stable place, so cost barely grows with n, but a layout change wipes that advantage. A search field lets people bypass the row, so the scan tax falls only on people who do not search. Icon-plus-text sometimes cuts scanning; it does not cut “choose among n”.
Applying it
- Before adding an item, measure arrival at current frequent items. If expected use of the new one cannot cover everyone slowing down, do not put it in the same choice field.
- Do not lay frequent and rare items in one flat row; let frequent items pay less tax.
- Make names pairwise separable before asking whether one more item fits — inseparability amplifies n’s cost.
- How to check: record “go to the most frequent entry” before and after the add. Longer arrivals plus almost no use of the new item is a count tax. Then hide icons (text only) and the reverse, to see whether scan failure is n or colliding names.