Validating a metaphor requires testing edge cases, not just the core typical scenario

What it is

A metaphor performing well in the core, typical scenario says nothing about whether it holds up overall — the places where a metaphor breaks, whether that's a gap a user fills in on their own, a rule conflict from mixing source domains, or an extension into an edge case, cluster almost entirely in the atypical operations users rarely take but do sometimes take. So judging whether a metaphor is sound requires test coverage that specifically targets edge cases; a "pass" obtained by testing only the core path says nothing about whether the metaphor holds everywhere else.

Why it happens

Standard usability testing is naturally biased toward the core scenario: tasks are usually designed around the most common usage flow, and recruited users are largely steered toward completing typical goals. This process is efficient at validating "how most people experience most things," but it systematically routes around exactly where a metaphor tends to break — because edge cases simply aren't on the typical usage path, so a study that only exercises that path will never run into them on its own.

This isn't bad sampling luck; it's a structural blind spot in the test design itself. As long as task scripts are derived by working backward from "what users typically want to do," edge cases won't naturally get included unless tasks are deliberately designed for them. And edge cases are exactly where a metaphor's inference rules get extended automatically and unconsciously — not testing for them means that whole layer of inference goes completely unchecked until real users first stumble into it after launch.

Studying it

To make testing actually cover edge cases, task design shouldn't start from "what users usually do" but from the property space of the metaphor's source domain itself, enumerated systematically: what other properties, states, or combinations exist in the source domain beyond its core use (can a folder hold another folder, can items still be added to a cart after checkout starts, can a conversation be edited by multiple people at once) — then check, one by one, whether the system has defined behavior at each point, turning every item into a concrete test task.

Common independent variables: whether a task falls on the core path or on an edge case derived from the source domain, participants' familiarity with the source domain. Common dependent variables: prediction accuracy for the outcome of an edge-case operation, the degree of confusion or subsequent corrective behavior when the prediction doesn't match actual behavior.

Methodology note: enumerating the source domain's property space depends on the researcher's own familiarity with that domain, and can easily miss boundary properties the designers themselves never noticed. A more reliable supplement is to first run a round of open-ended exploration with no predefined edge-case list, observe which atypical operations users spontaneously try, and fold those into the systematically enumerated task list — cross-checking the two sources covers more ground than relying on either alone.

Where it stops holding

• Enumerating edge cases can never be exhaustive — a source domain's property space can be subdivided indefinitely, and test resources are always finite. This entry argues for deliberately allocating test resources to boundary coverage, not for covering every conceivable boundary.
• This kind of systematic enumeration is only worthwhile when the metaphor genuinely borrows from a source domain users have rich intuitions about; if the source domain itself is unfamiliar to users, they're unlikely to spontaneously extend it into edge cases, and the payoff from covering boundaries drops accordingly.
• A "usability is good" conclusion drawn from core-scenario testing is not overturned or replaced by this entry's claim — the two answer different questions. One measures the experience of most people doing most things; the other measures the completeness of the metaphor's rules. A product launch typically needs both.

Applying it

• At the test-planning stage, maintain a separate "edge case list" — sourced from both systematic enumeration of the source domain and observations from open-ended exploration — kept apart from the core task list, so edge tasks don't get deprioritized out of the test cycle just for looking "rarely used."
• For identified edge operations the system deliberately doesn't support, check whether the system gives explicit feedback (a disabled state, explanatory copy) rather than leaving the behavior undefined — this is the key step that turns a test finding into a concrete fix.
• How to check: report the pass rate for edge-case tasks separately from the pass rate for core tasks, side by side. If edge tasks pass at a noticeably lower rate but get washed out by an overall average because they're a small share of the total, the current test framing is systematically understating the metaphor's real risk.

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.3 Users routinely extend a metaphor into edge cases the designer never anticipated
• Nearby: A7.03 Metaphor · A7.08 Design model, system image, and user's model
• Search terms: metaphor validation · boundary case testing · edge case · interface metaphor