A confirmation step must present the specific features that distinguish the object

What it is

A description-similarity error happens at the selection step: the user has already picked the wrong target because two objects weren't discriminable enough. By the time confirmation comes around, if the dialog only repeats a generic line — "Are you sure you want to do this?" — it's asking a question that has nothing to do with what actually caused the misselection. The misselection wasn't caused by the user being unsure whether to proceed; it was caused by the user not realizing the object they selected isn't the one they actually wanted. A generic confirmation offers no new information that could expose that mismatch, so the user confirms as usual — in their own head, the object being confirmed and the object they meant to act on are still the same thing. The error sails straight through the confirmation step unopposed.

Why it happens

For a confirmation step to actually catch an error, it has to offer information the selection step didn't provide, or that the user didn't notice at selection time, giving them a fresh chance to check. If the confirmation text includes features specific to the object itself — features that let someone tell at a glance "is this the one I wanted" (a filename together with its modification date, a contact's name together with a photo and department, an actual preview of the items about to be deleted) — then any mismatch between what the user sees now and the target they hold in their head gets exposed concretely, rather than being quietly papered over by an abstract "are you sure." A generic confirmation, carrying no object-specific information, effectively asks the same question the selection step already asked — it offers a user who's already picked wrong no new opportunity to catch it.

Where it stops holding

This only works in situations where the user picked the wrong object but is still actually reading the confirmation content. If a user has already built up habitual blindness to the confirmation dialog itself — because it pops up too often, mostly for low-stakes actions — then no amount of object-specific detail will get read either. At that point the problem isn't that the confirmation content lacks specificity; it's that the confirmation mechanism itself has lost its effectiveness from overuse, and the fix has to start with reducing how often unnecessary confirmations get triggered in the first place.

Applying it

For every action that carries a description-similarity misselection risk and has a confirmation step, check whether the information the dialog presents is object-specific: replace generic wording with text that includes a concrete identifier, and replace a plain-text confirmation with one that includes a thumbnail, preview, or key attribute — so that at the moment of confirming, the user can independently judge "this really is the object I wanted" without depending on a memory that may already have failed at the selection step. Verification: run a control group with a generic confirmation and an experimental group with an object-specific one, have testers complete tasks known to involve similar objects, and track the rate of "picked the wrong object but confirmed anyway" in each group. If the experimental group's rate is clearly lower, the added object-specific content is genuinely catching errors.

Related

• Same group: A10.04.3 mis-selecting files, contacts, or options with near-identical names · A10.04.4 a destructive action sharing its shape with a routine one is a high-risk configuration
• Nearby: A10.08 error tolerance and graceful degradation
• Search terms: confirmation dialog · object-specific confirmation · disambiguating confirmation