Positional stability outranks ranking optimality

What it is

A settings menu ordered by usage puts Notifications first and About eighth today; after the stats refresh they swap. For someone on a first visit, first place really is more likely to be hit. For someone on their twentieth visit, that “better” ranking is worth a penny, and the swap is worth a discarded motor program. Stability over ranking is a trade: the returning user’s place-memory weighs more than the one search saved by moving today’s top item one slot forward.

It is not an argument against ordering. It is an argument against treating order as a living process. Rank once, then stop.

Why it happens

A “better order” shortens the scan of controlled search. The gain lands on people who do not yet know the slots, and it lands once (or a handful of times). A stable slot, once written as a motor program, costs near zero on every later visit. Sum the first over all return visits and the second over visits still in search, and in a product whose skilled users are the majority, stability almost always wins.

Product decisions often maximise click-through from an analytics panel as a function of layout, and so reshuffle weekly by the numbers. The week click-through rises is often new or occasional users benefiting, while the already-automatic slice of daily actives starts missing. Averaging those two populations produces an “optimum” that injures the heavy users.

Where it stops holding

A brand-new product with no returning users, or a seasonal entry (a year-end event, a one-shot quiz), can lead with ranking optimality — there is no memory to protect. An order the user dragged themselves is their optimum; stability means honouring it, not freezing the factory arrangement. An information-architecture rewrite that changes the categories themselves cannot keep the slots; treat that as a migration, not as daily ops. An A/B that leaves half the people on the old slots and half on a “better” ranking, if it measures new-user conversion, must not be written into the returning users’ default.

Applying it

• Navigation, tab bars, toolbars take their ship-day order as the default. Later data decides whether to add an entry, not whether to reshuffle old ones.
• Split click analytics between new users and users older than thirty days. A ranking gain seen only on the new-user side does not get to rewrite the old-user layout.
• When both populations must be served, fixed slots for the old, a separate Recommended strip for those still searching, and the two strips do not crowd each other.
• How to check: pick an entry shipped more than a month ago, and compare “keep the slot” against “reshuffle by last week’s click-through” on returning users’ miss taps and time. If the reshuffle group is slower or sloppier on those users, stop the trade at stability.

Related

• Same group: F1.06.1 Moving a control discards the muscle memory already formed · F1.06.2 Dynamically ordered entries cannot be operated automatically
• Nearby: F1.14 Semantic conventions of position · F3.07 Hierarchy aligned with priority
• Search terms: stability over ranking · menu consistency · positional constancy