The same glyph means different things in different products
Aliases: cross-product ambiguity · colliding icon conventions · glyph collision
What it is
A heart can be like, save, health, or donate. A star can be a rating, a bookmark, or a paid tier. Three bars can be a menu, a playlist, or a sort. People do not arrive with a blank meaning table; they arrive with the reading they just learned in the last app. When one outline is bound to different actions across products, the failure is not that the drawing is a poor likeness. It is conventions trampling each other.
Why it happens
Icon meaning is a pact, not a physical fact. A single product can train the pact by repetition, but a day of use crosses a dozen interfaces, each overwriting the last binding. Collisions cluster on simple shapes that can host almost anything: heart, star, bell, three dots, a person silhouette. The emptier the shape, the more functions it can swallow, and the higher the chance of a cross-product crash. People do not keep a separate lexicon per app; they reuse the last binding that worked. A wrong reuse is a miss at best and an irreversible action at worst.
Studying it
Isolated naming is the wrong instrument here. That test assumes one correct meaning; the trouble is that the correct meaning changes with the product. A better design is a cross-product contrast: inventory how several widely used apps bind the same outline, count one-to-many mappings, then run a switch task — use the icon in product A, immediately act in product B, and score wrong actions.
Independent variables: whether the outline is a high-frequency shared shape, how far apart the two product categories sit, which apps the participant used most recently. Dependent variables: wrong action, hesitation time, and the post-hoc "I thought it would…" account.
Where it stops holding
- A closed ecology — one suite, one industry tool — can write its own law, and collisions drop.
- If a platform documents a system glyph, rebinding it inside a product is a worse expectancy violation than inventing a new drawing.
- This is binding conflict across products, not "the picture cannot be named on a blank field", and not "the function has no drawable object".
Applying it
- Before taking a shared shape, look up what the apps your users live in already bind it to. If they bound a different action, do not take the shape.
- If the shape must be reused, nail the action with words. Do not expect users to swap dictionaries on their own.
- How to check: make a table of "what this shape means in competing products", then watch at least three people who use those products click your interface with no briefing, and see whether the action they expect is the one you bound.