Mis-selecting files, contacts, or options with near-identical names

What it is

This is the description-similarity error's counterpart in text rather than spatial controls: when a user identifies a target from a rough name fragment — "the report," "Manager Zhang," "that option from last time" — and the system happens to hold several candidates with near-identical names ("Report_v1" and "Report_v2," two contacts both named "Manager Zhang," two nearly-identical option labels in a dropdown), misselection follows. Unlike mis-tapping adjacent controls, there's no physical landing-point error involved here at all — the failure is purely that the name itself doesn't carry enough discriminating information to cover the size of the candidate set. The user already can't tell the difference at the textual level; there's no "slip of the hand" to speak of.

Why it happens

A name works efficiently as a way to identify a target because, in most situations, the name itself is distinctive enough that a glance locks onto the one correct object without any need to check the content further. That strategy — relying on the name's own uniqueness — breaks down the moment the system holds several objects with near-identical names. The problem isn't that the user read carelessly; it's that the name, as a channel, simply doesn't carry enough information to separate the two objects. What makes this worse is that a lot of this kind of duplication is a perfectly ordinary by-product the system or the user generates on their own: default naming rules on "save as" (copy, duplicate, v1/v2), duplicate names preserved from a bulk contact import, form options whose labels are inherently close in meaning. These aren't edge cases — they're a steady output of everyday use, which means the risk of this kind of misselection doesn't fade with experience; it accumulates as the number of files or contacts grows.

Where it stops holding

If the candidate set is small to begin with — fewer than ten contacts total, say — the cost of scanning through every one and checking manually is low even when names overlap, so the misselection risk drops accordingly. This mechanism bites hardest when the candidate set is large and the user relies on search or autocomplete to jump straight to a match rather than browsing item by item — search and autocomplete are exactly what amplifies the "see a match, pick it" shortcut that depends on the name alone, and with it, the risk that comes from overlapping names.

Applying it

In any list of files, contacts, or options indexed mainly by name, add a second discriminating dimension to every item and make it directly visible on the selection screen — a last-modified date or source-app icon for files, a department or most-recent-contact channel for people, a short description rather than just the option's title for form options. For system-generated default names (copy, v1/v2), surface information that actually distinguishes the content up front, rather than requiring the user to open each item to tell them apart. Verification: pull a set of real, near-identical-name items from production data, build a batch of "select the specified item from this list" tasks, and hand them to testers, logging error rate and time to complete. The item groups with the highest error rate and longest completion time are the priority candidates for added disambiguating information.

Related

• Same group: A10.04.1 selecting the wrong object because its description fails to distinguish similar candidates · A10.04.6 a confirmation step must present the specific features that distinguish the object
• Nearby: G3.03 search suggestions (autocomplete amplifies exactly the name-dependent "see a match, pick it" shortcut)
• Search terms: similar filename · near-duplicate naming · contact disambiguation