People favour the first and left positions; order must be controlled or randomised

What it is

The same three options, left and right swapped. The pick rate of “the left one” follows the seat, not the content. First in a list, leftmost in a row, topmost in a column, take extra choices. Position bias requires that option order be treated as a factor that will distort comparison — randomised, balanced, rotated — or be designed outright as “recommended first,” admitting the presentation is not neutral.

Not finishing looking, and regretting after a pick, are count problems. Here the content was seen; position still votes.

Why it happens

Reading and clicking have spatial defaults: in left-to-right, top-to-bottom writing systems, the first glance lands on the first item. Primacy makes the first-processed item the referent for later ones; later items have to beat an object already occupying working memory. Click heat is uneven too: a top-left target is easier for the hand. If the generator also ranks “quality left to right,” position and content correlate, and it becomes even harder to tell whether the pick was content or seat.

Position effects peak when differences are small — signal on the decision dimension is weak, and position wins as a noise channel. That abuts noise-picking, but the mechanism is spatial, not residual attributes.

Studying it

The same set, Latin square or full shuffle of positions; see whether picks move with the seat. Independent variables: position, content quality (rated by another group), size of between-option differences. Dependent variables: pick rate by position, correlation with content quality, whether people notice order changing.

Report variance explained by position and by content. Overall liking alone will swallow the bias. Reading direction (a right-to-left UI) must be a moderator; do not write left-bias as a human constant.

Where it stops holding

When the user asked to “put the best first,” position bias is requested; mark it as a ranking, not a neutral comparison. Assistive reading follows DOM order, so visual left-bias becomes sequential primacy; randomisation is still needed. A singleton has no position problem. On a narrow vertical swipe, “left” becomes “top”; the effect remains, the axis changed. This entry does not treat overload, nor whether spreading instability is worth it.

Applying it

• For comparison, default to random or session-rotated positions. Do not freeze the model’s first sample at top left.
• If position means recommendation, write “sorted by ××” and offer “shuffle” to people who want a neutral comparison.
• Log position with the pick. When position explains most of the variance, do not take clicks as content preference for fine-tuning.
• Check: swap positions on the same set. If pick rates follow the seats, order was not controlled. Add “this order is random” and see whether preference still sticks to top left — if it sticks, position is voting.

Related

• Same group: L3.07.1 Juxtaposition drops the evaluation load from good-or-bad to which-is-better · L3.07.2 When options differ too little, comparison collapses into picking noise · L3.07.3 More options bring choice difficulty and decision regret · L3.07.5 Multiple options expose the system’s instability — a cost and a form of honesty
• Nearby: L3.01 Generating Multiple Options · L1.01 Mismatch Between Stochastic Output and Deterministic UI
• Search terms: position bias · primacy effect · left-side preference