Selecting the wrong object because its description fails to distinguish similar candidates

What it is

A description-similarity error is when a user selects and acts on the wrong object, not because they misjudged what they wanted to do, and not because they misjudged what state the system was in, but because the internal "description" they used to pick out the target — something as coarse as "the one on the left," "the red one," "the file I opened just now" — matched more than one candidate at once, and the wrong match got selected instead of the one actually intended. This sits on a different mechanism from a mode error or a capture error: it isn't the same action meaning something different under different state, and it isn't a familiar sequence hijacking intent — the failure happens at the step of picking out the target itself: the target isn't wrong in principle, the basis for identifying it just wasn't specific enough.

Why it happens

When picking an object to act on, people rarely run a full, item-by-item comparison across every candidate; instead they rely on a description that's just detailed enough to work, and use it to locate the target quickly — this is perfectly reliable when candidates differ obviously, and it's exactly what keeps everyday operation efficient. The trouble starts when the difference between candidates happens to fall along a dimension the coarse description doesn't cover: two files both named "Report," two buttons carrying the same icon, two contacts both surnamed the same. At that point, the coarse description points to a set with more than one member, and the selection mechanism has no built-in way to further discriminate within that set — so it either picks essentially at random, or systematically picks whichever member is most salient or listed first. Either way, the user's confidence that "what I selected is what I wanted" gets decoupled from the actual accuracy of the outcome: confidence doesn't drop just because the candidate set happens to have several matches, because the user was never aware other candidates existed at all.

Studying it

A standard paradigm for testing description-similarity error builds a set of candidate objects along a graded similarity dimension — icons converging step by step in color, shape, or position — and has participants complete identification-and-selection tasks under time pressure, tracking how the misselection rate rises with similarity, alongside a confusion-matrix analysis to find which object pairs get substituted for each other most often. These studies typically also log response time: if misselections tend to come with shorter response times than correct selections, that supports the hypothesis that users are matching a coarse description and committing immediately without checking further candidates. If misselections instead come with longer response times, it suggests the user hesitated but still got it wrong — pointing more toward a judgment failure than a rushed one.

Where it stops holding

This mechanism requires there to actually be enough candidates, and a genuine multi-choice situation the user is facing — if the interface shows only one candidate at a time with no other member the same description could point to, the physical precondition for this kind of error simply isn't there. The odds of misselection also depend on how practiced the user is at the task: on a completely unfamiliar task, people tend to slow down and check items one by one, so similarity-driven misselection is actually lower than it is for moderately experienced users — the latter have already built a habitual "spot the rough feature and go" judgment style, and it's precisely that habit that fails first once the candidate set gets more complex.

Applying it

For any setting with multiple candidate objects that share obvious appearance or naming features — a list, an icon grid, a dropdown — first measure the discriminability between every pair of candidates along the dimension users actually judge by (shape, color, position, text), find the pairs with insufficient discriminability, and then decide whether to redesign the appearance or rearrange the layout to widen the gap. Verification: have testers unfamiliar with the interface complete a batch of identification tasks under time pressure, logging the time taken and correctness of each selection. Group the misselected trials by candidate pair, and tally which pairs account for most of the errors — those pairs are the ones that need redesigning first.

Related

• Same group: A10.04.2 mis-tapping adjacent controls that look identical · A10.04.5 use position, shape, and wording together to widen discriminability
• Nearby: A10.05 capture errors (picking the wrong object and having a familiar sequence hijack intent are two distinct failure mechanisms)
• Search terms: description similarity · target confusability · selection error