A wrong signifier is more harmful than none
Aliases: misleading signifier · erroneous cue · false action cue
What it is
A misleading signifier promises an action that does not exist, is unavailable, or means something else: static decoration that looks clickable, a handle suggesting drag when only a click works, or a control still labelled “Save” when submission is impossible. No signifier tends to cause hesitation; a wrong one prompts a mistaken action with a specific expectation, usually at greater cost.
Why it happens
A signifier leads people to predict an action, outcome, and consequence. When the prediction conflicts with system behavior, they lose not only an attempt but also confidence in the interface, their understanding, and the system's trustworthiness. Repeated wrong cues can make people abandon valid conventions and resort to aimless probing. For consequential actions, false expectation can produce data loss, wrong submission, or privacy exposure.
Studying it
In task testing, record which cue caused an expected action and compare expectation with the actual outcome. Look especially for confident but wrong first actions, repeated ineffective attempts, workarounds, and trust judgments rather than completion alone. Audit dynamic states too: many misleading cues arise when loading, permission, or disabled-state changes do not update the visual mark.
Where it stops holding
An occasional misunderstanding does not necessarily make a signifier wrong; task language, domain knowledge, or the broader structure may be unclear. But if an interface consistently induces a reasonable expectation that it cannot fulfill, the communication is mismatched. Caution does not mean removing all cues: after removing a false one, provide an honest, understandable alternative for critical capability.
Applying it
- Check each important mark against the action, availability condition, outcome, and permission it implies, ensuring displayed state reflects actual system state.
- When an action cannot run, state why and how to recover rather than retaining an apparently available but unresponsive control.
- Include expectation–outcome mismatch, repeated ineffective actions, and surprising consequences in usability tests and log review.