When a stated conceptual model conflicts with actual interaction behavior, users go by behavior

What it is

The help documentation says "deletion is recoverable within 30 days," but hitting delete makes the item unrecoverable — when written copy and actual behavior conflict like this, what a user ends up believing is not the copy but the result they got with their own hands. This is a specific tie-breaking rule: when the two fight, behavior wins and the copy loses, however clearly or formally the copy was written.

Why it happens

Written copy is a claim that has to be trusted; whether a user accepts it depends on how much they trust the source. A result obtained by direct action is evidence that can be re-verified any number of times — every repeat of the same operation checks it again, with no dependence on trusting any source at all. When the two conflict, the user is holding a chain of evidence they can keep re-confirming for themselves, while the copy is a one-time statement from a source of unknown reliability — the weighting is inherently lopsided.

More importantly, behavior isn't a one-off event: as long as the operation keeps getting used, the evidence it provides keeps being reconfirmed, and each repetition strengthens the conclusion that the copy is wrong. Copy that isn't actively corrected just sits at the moment the user first read it and never gets another chance to compete. Weighing the two, a user is effectively pitting a continually accumulating body of evidence against a statement that was frozen the moment it was written and never updates again.

Where it stops holding

• This only applies once a user has directly and repeatedly observed that the stated behavior doesn't match reality. If they haven't actually performed the operation yet, or have only done it once and can't yet rule out a fluke, the copy is still doing the work of shaping expectations — it hasn't yet been overturned by behavior.
• This doesn't mean copy is worthless. Before a user has any behavioral evidence to go on — their very first use — copy shapes their initial expectation, and it continues to color how ambiguous behavioral evidence gets interpreted afterward. Copy only gets fully overridden once behavioral evidence is clear and repeated enough.
• This assumes the behavior itself is consistent enough to override anything. If the system's actual performance is itself inconsistent — sometimes matching the copy, sometimes not — a user may end up neither fully trusting the copy nor able to induce a stable alternative model from behavior, landing in a state where neither side is reliable. In that case, "behavior wins" doesn't hold either, because behavior isn't offering anything stable to win with.

Applying it

• Treat written copy as a promise that must be verified, not a task that's done once it's written: before shipping, check each claim in the copy against what the system actually implements, and treat any mismatch as a defect — not as something to be fixed by softening the wording so it sounds less absolute.
• When a mismatch is found, fix the behavior before rewriting the copy. Users encounter the copy far less often than they encounter the behavior, so fixing only the copy — even if that makes it technically more accurate — does nothing to remove the sense of contradiction the user experiences, because the next time they act, they'll hit the same behavior as before.
• How to check: pick out the handful of behavioral promises in the product that matter most to a user's decisions (recoverability, reversibility, whether the other party gets notified), and actually execute each operation to verify the outcome, rather than just reviewing whether the wording reads clearly. Treat any discrepancy found as a defect to be prioritized.

Related

• Same group: A7.10.1 An explicit conceptual diagram is learned more accurately than a model left implicit in interaction · A7.10.2 A persistently visible status display is itself a form of conceptual-model expression · A7.10.3 A conceptual model should be presented before feature detail, establishing the framework before filling in operations
• Nearby: A7.08 Design model, system image, and user's model · A7.14 Recognizing and correcting wrong mental models
• Search terms: behavior over copy · system image consistency · mental model · direct experience