Mixing multiple metaphor source domains in one interface makes their inference rules collide
Aliases: metaphor clash · metaphor conflict
What it is
Every metaphor comes with its own set of inference rules: a folder implies "things placed inside stay there until someone takes them out"; a conversation implies "what's said is ordered by time, and earlier turns don't disappear". When one interface uses metaphors from different source domains at once — say, treating a message as a card (swipeable, discardable) and also as a conversation (meant to be preserved and traceable) — users apply both sets of rules at once, and the two give contradictory predictions for the same action: does swiping away a card mean "discard", or "archive, still retrievable in the conversation history"?
Why it happens
Users don't consciously decide "which metaphor should I use to interpret this element right now" — the choice happens below the level of awareness. When visual or interaction cues from multiple source domains appear on the same object at once, users trigger whichever inference rule is most salient at that moment, and which cue is most salient can differ across users, or even across moments for the same user. The result is that the same action generates different expectations for different people, and no expectation is "wrong", because the interface itself genuinely offers evidence for both readings.
Where it stops holding
- Mixing metaphors is not the same as using several metaphors. An interface can perfectly well host multiple metaphors side by side, as long as each governs a region that doesn't overlap with the others — the conflict only appears when the same object or the same action is claimed by two source domains at once.
- Less experienced users are more easily dominated by whichever metaphor cue is most visually prominent, and so more likely to be caught off guard when the conflict surfaces. Experienced users may have already learned through trial and error which rule the product actually follows, so the conflict's impact on them fades with use over time — but that doesn't mean the underlying conflict has gone away.
- If two source domains happen to produce the same prediction for a specific action, no conflict shows up. Whether a conflict exists has to be judged at the level of specific interaction points, not by whether the interface "looks like" it uses multiple metaphors overall.
Applying it
- For each interactive object, first ask how many metaphor cues it carries at once (what its graphic style resembles, what its motion resembles, what its copy implies). Whenever there is more than one, list out the expectation each would lead a user to form, and check whether those expectations agree on the specific action in question.
- When a conflict is found, pick one source domain as the authoritative rule for that object, and strip out the leftover cues (visual style, motion, wording) belonging to the other — don't keep both and hope users sort it out themselves.
- How to check: construct a concrete interaction scenario and have a new user predict the outcome out loud, while you have on hand the two answers each candidate metaphor would produce for that object. If the user's answer wavers between the two, or clearly disagrees with actual behavior, the conflict is real and the metaphors need to be converged into one.
Related
- Same group: A7.09.1 A metaphor maps only part of its source domain — users fill in the rest themselves · 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 · A7.08 Design model, system image, and user's model (the general case of a self-contradictory system image)
- Search terms:
mixed metaphor·metaphor clash·interface metaphor·inference rules