A metaphor maps only part of its source domain — users fill in the rest themselves

What it is

An interface metaphor — a folder, a trash can, a shopping cart — never imports its source domain (a real folder, bin, or cart) wholesale. It only maps a selected subset of properties: a folder maps "contains" and "categorizes", not "takes up physical space" or "can be torn". This is partial mapping. The trouble is that users don't just receive the mapped subset — whatever property the designer left undefined, users fill in on their own, using the source domain's intuitions. Whether a file in the trash is merely "set aside" or "already being destroyed" gets guessed from real-world trash-can intuition, not from anything the interface actually states.

Why it happens

A metaphor lowers learning cost precisely by letting users import an entire ready-made set of inference rules from the source domain, instead of learning each rule individually. But that also means what gets imported isn't just the handful of rules the designer wanted — it's the whole intuitive network, because in the user's head the source domain was never split into "core of the metaphor" versus "peripheral detail" to begin with. The designer only defines the behaviors they need; every remaining gap gets auto-filled by source-domain intuition, and those auto-filled parts are often never examined by the designer at all — and may directly contradict the actual implementation.

Where it stops holding

• Partial mapping isn't a flaw — it's the very reason a metaphor saves learning cost. Demanding full correspondence to the source domain would eliminate the metaphor's simplifying value, and is not achievable anyway.
• The direction of the fill-in is predictable: the more salient and basic a property is in the source domain ("things in a trash can are meant to be discarded"), the more readily users import it unreflectively, regardless of designer intent.
• For users unfamiliar with the source domain itself (someone who has never used a physical shopping cart, or a cultural context without the corresponding real-world image), this auto-fill doesn't happen — the metaphor simply becomes opaque, so this group neither benefits from nor suffers the fill-in effect.

Applying it

• Explicitly list the properties of the source domain that users are most likely to assume by default but that the system either doesn't implement or implements oppositely, then decide, item by item: follow the intuition (behavior matches expectation) or deliberately interrupt it (a cue that corrects the wrong expectation). Leaving it ambiguous is the worst option — users will act on their own guess.
• Prioritize gaps involving irreversibility or safety: whether trash can actually be recovered, whether deleting equals permanently emptying. These cannot be left for users to guess.
• How to check: find new users who were not part of the design discussion and ask directly, "if I do X now, what do you think will happen" — where X is an edge action the designer never explicitly defined. Any guess that comes up frequently and contradicts actual behavior marks a gap that needs explicit handling.

Related

• Same group: A7.09.2 Mixing multiple metaphor source domains in one interface makes their inference rules collide · A7.09.3 Users routinely extend a metaphor into edge cases the designer never anticipated · A7.09.4 Validating a metaphor requires testing edge cases, not just the core typical scenario
• Nearby: A7.03 Metaphor (how metaphor lowers learning cost) · A7.01 Definition and function of mental models
• Search terms: metaphor mapping · partial mapping · source domain · interface metaphor