Affordance, Signifiers & Metaphors: The Three Words Every UX Designer Confuses (And Why It Matters)

Early in my career, I used “affordance” and “signifier” interchangeably. I’d tell my team, “this button needs a better affordance,” when what I actually meant was “this button needs a better signifier.” Nobody corrected me because most people in the room were doing the same thing.

It took a real product problem, not a textbook, to make the distinction click for me. I design for a B2B export/logistics SaaS platform think exporters filling out compliance-heavy shipment and documentation flows. It’s dense, high-stakes work where users can’t afford to guess wrong. That environment forced me to actually understand what these three concepts mean, because getting them wrong wasn’t a cosmetic issue it slowed down real business workflows.

Here’s what I learned, with examples from my own work.

Affordance: What an object lets you do

An affordance is a property of an object what it actually allows, independent of whether anyone notices it. A chair affords sitting. A flat surface affords placing things on it. This has nothing to do with visual design; it’s about the actual possibilities built into the thing.

In digital products, this translates to: what can this element actually do? Can you click it, drag it, expand it, type into it?

While designing the onboarding flow for our platform, I had to decide which fields in the activation sequence should be required now versus fillable later. Certain compliance fields IEC number, GSTIN, authorized signatory details are genuinely gating: the platform can’t function without them. Others are important but not blocking.

The affordance question here wasn’t about how the field looked. It was about what the system actually let the user do at that field: could they skip it and come back, or was skipping impossible? I had to design the actual behavior first a “soft-gate” pattern where certain fields blocked progress and others didn’t before I could think about how to communicate that to the user. Affordance is the underlying truth. Everything else is how you reveal it.

Signifier: The clue that tells you the affordance exists

This is where most of us actually spend our design time, even when we call it “affordance.” A signifier is a signal a visual or textual cue that tells the user an affordance exists and how to use it. Don Norman, who popularized this distinction, pointed out that a doorplate reading “push” isn’t the affordance (the door could be pushed or pulled regardless); it’s the signifier that tells you which action works.

On our onboarding screen internally we called it “Make it yours” I was iterating on how to signal which fields were mandatory-to-proceed and which were optional-for-now. A plain asterisk next to a label is a weak signifier in a form this dense; users scan past it. I moved to a combination of: a distinct visual treatment for gating fields, inline microcopy explaining why a field mattered (“required to generate your first shipment document”), and a persistent but non-blocking state for the deferrable fields so users could see, at a glance, “this is optional, I can move on.”

The affordance (can-skip vs. cannot-skip) didn’t change. What changed was how legible that affordance was. That’s the entire job of a signifier: closing the gap between what’s possible and what’s perceived as possible. A powerful affordance with a weak signifier is functionally invisible users will treat a skippable field as mandatory, or a mandatory field as optional, and either way, they’ll get it wrong and blame themselves.

Metaphor: Borrowing a mental model that already exists

A metaphor lets you reuse a model of the world your user already carries around, so you don’t have to teach a new one from scratch. “Folder,” “cart,” “inbox,” “drag to trash” none of these are literal, but they let people transfer existing knowledge instantly.

I leaned on this heavily while working on our Document Studio feature a module for generating export documents automatically from shipment data. Export documentation is unfamiliar territory for a lot of first-time users, so instead of inventing new interaction language, I framed the feature around a “template” metaphor: build a document template once the way you’d build a template in any word processor, then generate documents from it repeatedly. Users who had never touched an export platform before still understood, instantly, that a template is something reusable and editable because that mental model already existed from completely unrelated tools.

The same thing showed up in a modal for selecting an existing shipment versus starting a new one I modeled it after the familiar “open file vs. create new file” pattern most people already carry from every desktop app they’ve used. Nobody had to be taught what that choice meant.

Metaphors are powerful, but they’re also risky a bad or half-borrowed metaphor imports the wrong expectations. If you call something a “cart” but it doesn’t let people remove items the way a real cart would, you’ve created confusion, not clarity. I try to only reach for a metaphor when I can honor it fully, not just borrow its vocabulary.

How the three actually work together

In practice, you almost never design just one of these in isolation:

• Affordance is the decision layer: what should this element actually be able to do?
• Signifier is the communication layer: how will the user know that?
• Metaphor is the shortcut layer: can I borrow an existing mental model instead of teaching a new one?

On the onboarding work, the sequence was: decide the affordance (which fields gate progress), choose signifiers (visual states, microcopy) to communicate it, and where possible, lean on metaphor (progress-through-steps, familiar form patterns) so the whole flow felt native rather than invented.

When something feels “off” in a product and you can’t articulate why, it’s usually worth asking which of the three broke down. Is the actual behavior wrong (affordance)? Is the behavior right but invisible (signifier)? Or is the design using a metaphor that promises something it doesn’t deliver? They’re different problems with different fixes, and conflating them like I used to means you end up redesigning the wrong layer.