Users routinely extend a metaphor into edge cases the designer never anticipated

What it is

When a designer picks a metaphor, they typically only worked through a handful of core, typical scenarios in their head — a file dragged into a folder, a file dragged back out. But what a user receives is not "these few scenarios"; it's an entire rule set they can reason from on their own, and they will naturally apply that rule set to situations the designer never considered: what happens if you drag a folder into its own subfolder? Do two folders merge if dragged onto each other? These are the metaphor's boundary cases — the user derives an answer straight from the metaphor's logic, while the system often has no defined behavior there at all, or defines one that directly contradicts the inference.

Why it happens

A metaphor saves learning cost precisely because it hands over a derivable rule set rather than a list of scenarios — an advantage in the core scenarios, but a liability at the edges. Users have neither the means nor the reason to distinguish "this inference is one the designer endorsed" from "this is just something I derived myself by following the metaphor's logic", because both draw on the exact same mental process. Boundary cases are, for that very reason, the least likely to be designed for or tested, precisely because they sit outside the typical path of use — yet they are exactly where the metaphor's reasoning power extends on its own.

Where it stops holding

• The more "complete" a metaphor feels — the richer and more systematic the user's intuitions about the source domain — the more boundary cases it can be extended into. Risk scales with fidelity to the source domain; a metaphor is not safer just because it resembles its source domain more closely.
• Boundary cases are usually triggered infrequently, which makes them easy to deprioritize — but when one is triggered and the result contradicts the inference, the resulting confusion and loss of trust is often disproportionately larger than that from a high-frequency minor issue.
• How familiar users are with the source domain determines which boundary cases get extended in the first place — a product serving audiences with different backgrounds may see the same metaphor extended into different boundary cases by different groups, all of which the designer would need to cover.

Applying it

• Starting from the metaphor's source domain, systematically list "what other real but non-typical situations exist in this domain" (a folder inside itself, checking out right after emptying a cart, a conversation edited by multiple parties at once), and confirm the system's actual behavior at each point — rather than discovering it's undefined only when a user stumbles into it.
• For boundary actions you've identified but don't intend to support, give explicit feedback (a disabled state, a message) rather than letting the action fail silently or produce a result the user never predicted.
• How to check: let users explore freely outside the core scenarios and note the first batch of boundary actions they try on their own — that list is usually a closer match to the metaphor's natural extension path than anything the designer would think to enumerate themselves.

Related

• Same group: A7.09.1 A metaphor maps only part of its source domain — users fill in the rest themselves · A7.09.2 Mixing multiple metaphor source domains in one interface makes their inference rules collide · A7.09.4 Validating a metaphor requires testing edge cases, not just the core typical scenario
• Nearby: A7.03 Metaphor · A7.13 Cross-product transfer of mental models (users carrying a model from one product to another is the same overgeneralization phenomenon in a different setting)
• Search terms: metaphor overextension · boundary case · interface metaphor · edge case inference