Reordering nav items by frequency unfixes their positions and hurts predictability

What it is

Moving the most-clicked item to slot one looks like a time saver, but the slots may change on every visit. Frequency reordering hurts predictability: people remember “Settings is second from the right,” not “Settings is my most used so it lives on the left.” When frequency changes, coordinates change, and spatial and motor memory both void. Personalization here moves order, not an extra recommendation block.

Rarely used items get pushed farther until the primary row is only high-frequency items. Low-frequency but critical entrances (annual expenses, delete account) become harder to find than under a fixed order.

Why it happens

Skilled pointing depends on stable coordinates. Frequency sort binds coordinates to a moving statistic: search was used more this month, Settings yields. The next point still hits the old slot and lands on the new high-frequency item. The misclick is taken as new evidence and the reorder continues; feedback amplifies the mess.

To the system, frequency is continuous. To a person, slots are discrete. A tiny frequency crossover makes a visible swap, and there is no way to know which day the swap happens. Predictability wants order inert relative to usage; frequency sort wants order sensitive. They cannot both hold on the same array.

Studying it

Let pointing form on a fixed order, then turn on frequency reordering, against a fixed-order control.

• Paradigms: learning to asymptote on a fixed order; test phase reorders by personal or scripted frequency. Measure pointing time, neighbour misclicks, reports that “it moved.” Contrast with “copy the frequent item into a shortcuts area, leave the primary row still.”
• Independent variables: reorder sensitivity, persistence across sessions, whether a low-frequency critical item is pushed out of the primary row.
• Dependent variables: change in skilled-task time, misclicks, steps to recover a pushed-out item.
• Methodological note: new users have no spatial memory, so frequency sort looks faster. Turn reordering on only after learning. Separate personal frequency from site-wide popularity; the latter makes everyone’s nav jitter together.

Where it stops holding

Launchers and command palettes ranked by frequency are a different surface and do not occupy primary nav slots, so the harm differs. A user-dragged custom order is stable personalization, not automatic frequency sort. “Recently used” on TV or in a car, if labelled as recent and not impersonating primary nav, uses a different expectation model. Frequency sort confined to an overflow, with the primary row locked, can keep predictability.

Applying it

• Lock primary-nav order. Copy frequent items into a separate shortcuts area; do not twitch the main row.
• If the business insists on automatic sort, confine it to overflow, with a high threshold and a long window so it does not jitter daily.
• Verify by having a week-long user point at primary items with eyes closed, then run the same points on a frequency-reordering prototype. A rise in misclicks or “it moved” means the main row should not follow frequency. If a low-frequency critical item vanished from the row, add a recovery task.

Related

• Within the group: G2.10.2 Personalized recommended items appearing and disappearing interrupt spatial memory · G2.10.3 Stable core nav and personalized modules must be partitioned · G2.10.4 Personalized ranking belongs on secondary entrances, not primary-task nav · G2.10.5 People need an explicit way to turn personalization off and restore a fixed order
• Adjacent: G2.07 Navigation consistency · E5.16 Shortcuts and pinned items · F1.06 Location stability of frequent actions
• Search terms: adaptive navigation · frequency ordering · spatial memory