Metaphor borrows existing knowledge to lower the cost of learning

What it is

An interface metaphor takes a conceptual system users already know (the source domain — a real-world folder, a desktop, a shopping cart) and uses it to stand in for a new, abstract digital system (the target domain), so users don't have to learn an entirely new set of rules from scratch — they apply reasoning they already have. Choosing a good metaphor is essentially a way of sparing users the trial-and-error learning cost of starting from a blank slate.

Why it happens

Learning a brand-new set of operating rules is costly mainly because of the work of building causal expectations from nothing — the user has to learn by trial and error what clicking here or dragging there will actually do. A metaphor skips that from-scratch process: the user already has a ready-made reasoning network for how the source domain works, and the metaphor simply plugs that network's entry point into the new system, so the user can start operating with a full set of expectations already in hand instead of groping from a blank state.

Studying it

Comparing how long it takes users with a metaphor cue versus users given an unfamiliar abstract label to complete the same first-time tasks, and how many errors they make along the way, shows how strong the metaphor's borrowing effect is — the bigger the gap, the stronger the effect. Another check is asking users to predict an operation they've never used but that "should" exist by the source domain's own logic (can a folder be nested inside a folder?) — a correct guess confirms they actually imported the source domain's reasoning, not just memorized an icon's name.

Where it stops holding

A metaphor's cost-reducing effect depends on the user being genuinely familiar with the source domain — for someone who has never seen a physical folder or a physical shopping cart, the metaphor borrows nothing and may add extra cognitive load as just another unfamiliar symbol. The savings a metaphor provides are also concentrated in the onboarding stage; once a user is fluent, whether the metaphor is still present or not makes far less difference to their efficiency.

Applying it

• When choosing a metaphor, first confirm that the target user population's familiarity with the source domain is broad and reasonably stable across cultures and age groups — don't assume users share the designer's own familiarity with it.
• Prefer a source domain whose core operating logic — not just its appearance — matches the target function; a metaphor that looks right but whose underlying logic doesn't match fails to actually transfer any useful reasoning.
• How to check: show a brand-new user, with no prior exposure to the product, a screenshot involving the metaphor and no explanation, then ask "what do you think happens if you click this." The share of answers that match the actual function is a quantitative measure of how effectively the metaphor is borrowing the source domain's reasoning.

Related

• Same group: A7.03.2 Overcommitting to a metaphor caps digital capability · A7.03.3 The source knowledge behind a metaphor fades across generations
• Nearby: A7.09 Metaphor and where it breaks down · A7.01 Definition and function of mental models
• Search terms: interface metaphor · source domain · metaphor transfer