creditunionwebsolutions.com

Affordances and Signifiers in UI Design: A Practical Framework for Designing Interfaces That Communicate Their Purpose Without Words

by | Jul 9, 2026 | UX Design

affordances and signifiers ui design

I've lost count of how many times I've watched someone hover over a button on a website, hesitate, and then click somewhere else because they weren't sure what would happen. That moment of hesitation, that tiny crack of uncertainty, is the direct result of a design failing at one of the most fundamental levels possible. The user couldn't tell what the interface was asking them to do, let alone what would happen if they did it.

This is where affordances and signifiers come in. Don Norman introduced these concepts in "The Design of Everyday Things" back in 1988, and somehow, decades later, most digital interfaces still get them wrong. I'm not talking about subtle, debatable design choices. I'm talking about basic communication breakdowns between the interface and the person using it.

What Are Affordances? A Refresher That Actually Sticks

The word "affordance" was originally coined by the psychologist James J. Gibson in 1977 to describe what the environment offers or furnishes an animal. A flat, horizontal surface affords resting on. A handle affords grasping. A ball affords throwing. These relationships exist whether or not the animal perceives them.

Don Norman borrowed the term for design and made a crucial distinction that I think is the most important idea in this whole article: a perceived affordance is what the user thinks they can do with an object, which may or may not match what the object actually affords. A glass door with no visible handle affords pushing. Or does it? If there's a vertical metal bar on the side, the user perceives it as something to pull. The physical reality of the door hasn't changed, but the user's perception has been guided by the signifier (the handle).

UX designer pointing at interface prototypes on a monitor, showing button states and interactive elements

Understanding affordances means studying how users perceive what your interface is offering them

Here's what I want you to really absorb: affordances are relationships, not properties. A button doesn't "have" an affordance of clicking. The relationship between the button's visual presentation and the user's ability to click it is the affordance. If the user doesn't perceive that relationship, the affordance hasn't been communicated, and for all practical purposes, it doesn't exist in that moment of interaction.

This sounds academic, but the implications are brutally practical. When you hide a call-to-action behind a ghost button with low contrast, you haven't just made a stylistic choice. You have broken the communication between the interface and the user. The affordance of clicking exists at the code level but not at the perception level. The button is technically there, and no user will ever find it.

I've seen this pattern (ghost buttons for primary actions) destroy conversion rates on landing pages. One client saw a 47% increase in click-through on their primary CTA just by giving it a solid background color and proper padding. The affordance was already there. They just needed to signal it.

Affordances in Digital Design: The Perceived Gap

Physical objects have a built-in honesty that digital interfaces lack. A chair's flat surface and leg structure communicate "sit here" through gravity and anatomy. You don't need instructions. But a digital button is just a collection of pixels arranged to look like something pressable. Nothing in the physics of the screen actually affords clicking; the entire interaction depends on learned conventions and visual cues.

This is why the concept of perceived affordance is so central to UI design. Every element on your screen is competing for the user's attention and cognitive processing. The user has to answer a rapid series of unconscious questions about each one: "Can I interact with this? What will happen if I do? Is it worth the effort?"

The answers come from visual signifiers, and those signifiers draw from:

  • Cultural conventions: Blue underlined text means link. We learned this from the web.
  • Physical metaphors: A raised button looks pressable because it mimics physical buttons.
  • Previous experience: The user has seen similar patterns in other interfaces.
  • Contextual clues: A text field in a form with a submit button tells a story about what's expected.

But here's where it gets tricky. Those conventions change over time. Flat design, for instance, deliberately stripped away many of the visual signifiers that skeuomorphic design relied on. Buttons lost their drop shadows and gradients. Suddenly, what looked like a button in 2010 might look like a decorative rectangle in 2015. Users had to relearn what was clickable.

I'm not anti-flat design. Some of the best interfaces I've worked on are visually flat. But I've also had to rescue products where the flat design went too far and nothing communicated its interactivity. The gap between what the interface affords (clickability) and what users perceive (nothing) had grown too wide.

The key insight: you can strip away ornamentation, but you cannot strip away signifiers. Removing drop shadows and gradients is fine if you replace them with adequate contrast, spacing, cursor changes, micro-interactions, and other signifiers that do the same job.

Signifiers Explained: The Invisible Work of Making Things Clear

If affordances are the possibilities for action, signifiers are the signals that point to those possibilities. Norman himself has said that signifiers are arguably more important than affordances for design, because you can't design what a user perceives; you can only design the signals that guide their perception.

Think about a door. The flat metal plate on a push door is a signifier. It's not the door's affordance (which is being pushed). It's the signal that tells you: "Push here." Your hand naturally goes to the plate, and you push. The signifier made the affordance discoverable.

In digital interfaces, signifiers take many forms:

  • Visual appearance: Shadows, borders, gradients, icons, color contrast
  • Motion: Hover states, micro-animations, transitions, loading indicators
  • Cursor changes: The hand cursor appearing over clickable elements
  • Sound: Click feedback, notification chimes, error tones
  • Haptic feedback: Vibration on mobile when pressing a button
  • Spacing and grouping: How related elements are positioned relative to each other
  • Labels and instructions: Text that tells the user what to do

Each signifier type has strengths and weaknesses. Visual appearance is the most commonly used, but it's also the most easily compromised by brand guidelines, accessibility requirements, and screen size variations. Motion can be incredibly effective at communicating state changes, but it fails on slow connections or with users who have motion sensitivity.

The best interfaces layer multiple signifiers for anything important. Your primary CTA button should have high contrast, adequate size, clear label text, a hover state, a cursor change, and potentially a micro-animation on click. Users who miss one signal will catch another.

Two UX designers collaborating on interface prototypes examining signifier patterns

Great signifiers require teams to think holistically about how users perceive and interpret interface elements

The Four Categories of Affordances Every Designer Needs to Know

William Gaver, a researcher in human-computer interaction, broke affordances into four categories that I've found incredibly useful when auditing interfaces. Here they are, adapted for digital design:

1. Perceivable Affordances

These are the ideal state. The user can both see the signifier and understand what it communicates. A solid, high-contrast button with "Submit" text falls into this category. The user perceives the clicking affordance, knows roughly what will happen, and can make a decision. This is what we should aim for with every interactive element.

2. False Affordances

These are elements that look interactive but aren't. The classic example is a plain text label styled to look like a clickable link (blue color and underline) that doesn't actually go anywhere. Users click it, get frustrated, and lose trust. False affordances are the most visible kind of betrayal in interface design, and they erode confidence faster than almost anything else.

Another common example: decorative cards with hover effects that turn out to be static. The user sees the hover state (a signifier) and assumes clicking is possible. When nothing happens, the interface has lied to them. Even if it's just a one-time confusion, it plants a seed of distrust.

3. Hidden Affordances

The opposite problem. The interaction is possible, but there's no signifier pointing to it. Right-click menus on the web are a classic example: they exist (affordance), but unless the user knows to try, they're invisible. Hidden affordances are common in power-user features, gesture-based mobile interactions, and any interface that relies on user discovery.

The danger of hidden affordances is assuming your users will discover them. They won't. At least, most of them won't. If an interaction is important, it needs a signifier. If it's a secondary power-user feature, hidden affordances can be a deliberate trade-off, but you need to accept that most users will never find them.

4. Correctly Rejected Affordances

These are elements that look somewhat interactive but signal clearly that they're not. A disabled button with reduced opacity and no hover state is the canonical example. The signifier communicates: "You could interact with this, but not right now." This is respectful design; it acknowledges the possibility without misleading the user.

In my experience, correctly rejected affordances are one of the most underused patterns in web design. Most teams either hide disabled options entirely (creating hidden affordances) or leave them fully styled (creating frustration when users click and nothing happens). The greyed-out state with a tooltip explanation is almost always better than either extreme.

Common Affordance Failures I See in Production Interfaces Every Day

I audit a lot of interfaces, both for clients and for my own curiosity. Here are the patterns I see failing most often, in order of frequency:

Ghost Buttons as Primary Actions

This is the number one offender. A ghost button (just an outline with no fill) used as the primary call to action on a landing page or critical flow. Ghost buttons work great as secondary actions because they recede visually. But as a primary CTA, they're basically invisible to scanning users.

I tested this on a client's homepage. The primary button was a ghost button on a dark hero image. Eye-tracking heatmaps showed users scanning right past it to a secondary solid-color button below. We swapped them (solid primary, ghost secondary) and the conversion rate on the primary action went up by 32%. Same page, same content, different signifiers.

Flat Text Links Without Underlines

Inline text links that are distinguished only by color (usually a blue that barely contrasts with black body text) are increasingly common, and they fail anyone who can't see color or anyone scanning quickly. WCAG requires a minimum contrast ratio between link text and surrounding body text that many designs don't meet.

The fix is almost always underlines. I know underlines feel "dated" to some designers, but they're the most universally understood signifier for a clickable text element. If you absolutely cannot use underlines, you need bold weight + high contrast + a color difference of at least 3:1 between link and body text.

Clickable Cards Without Click Cues

Entire card components that are clickable (product cards, article previews, dashboard widgets) but look like static containers. Users hover over them, see no cursor change, and miss the interaction entirely. This is a hidden affordance, and it's costing you engagement.

Every clickable card needs at minimum: a pointer cursor on hover, a hover state (shadow lift or border color change), and clear visual hierarchy that suggests the whole card is a single action target.

Icons Without Labels

Icon-only buttons for primary actions like "Save," "Delete," or "Search" are everywhere, and they're almost always a problem. Icons are ambiguous by nature. A floppy disk icon means "save" to people who grew up with floppy disks. To someone born after 2005, it's a museum piece. Even supposedly "universal" icons like the magnifying glass for search can cause hesitation.

The signifier of a label (even a single word) dramatically reduces cognitive load. If space is tight, use a tooltip or an accessible label that appears on hover or focus. But never rely on icon meaning alone for primary actions.

Interactive Elements Below the Fold Without Scroll Cues

We know users scroll. But if the most important action on a page requires scrolling and there's no visual cue pointing to the content below, many users will never find it. The affordance of the lower section exists (scrolling reveals it), but the signifier is missing.

Solutions include: partial visibility of the next section (often called "peeking"), arrow indicators, animated scroll hints, or progressive disclosure that reveals content as the user reads.

How to Design Better Signifiers: A Practical Decision Framework

After years of designing and reviewing interfaces, I've settled on a simple decision framework for evaluating and designing signifiers. It answers one question: "Is this signifier doing its job?"

The S.P.A.C.E. Framework

Salient — Does the signifier stand out enough to be noticed in the context of surrounding elements? A signifier that blends in is a signifier that doesn't exist. Test this by stepping back from your screen to the point where you can't read text. Can you still identify interactive elements by their visual weight alone? If not, your signifiers aren't salient enough.

Predictive — Does the signifier communicate what will happen? A button labeled "Submit" is predictive. A button labeled "Click Here" is not. The best signifiers tell the user not just that they can interact, but what the outcome will be. This is where microcopy joins forces with visual design.

Available — Can all users perceive this signifier? This includes users with visual impairments, color vision deficiencies, motor disabilities, and cognitive differences. If your signifier relies only on color, it fails the availability check. Layer in motion, contrast, spacing, and text.

Consistent — Does this signifier match expectations set by other parts of the interface and by common platform conventions? Inconsistent signifiers force users to relearn the same pattern in different contexts. If buttons in one section use shadows and buttons in another don't, you've violated consistency.

Efficient — Does the signifier communicate quickly, or does it require studying? An efficient signifier is processed pre-attentively; the user knows what to do before they consciously decide to act. An inefficient signifier requires reading, interpretation, or trial and error.

Run every signifier through these five criteria. If it fails two or more, redesign it. If it fails three, it's actively harming the user experience.

Applying S.P.A.C.E. in Practice: A Real-World Example

Let me walk through how this framework would apply to a concrete design problem. Say you're designing a settings panel for a mobile app. The user needs to toggle notifications on and off, adjust notification frequency, and save their preferences. The Save button sits at the bottom of the screen.

Running the Save button through S.P.A.C.E.:

  • Salient — The button uses the brand's primary color with a white label and sits at the bottom of the panel where users expect actions. It has adequate padding and stands out from the surrounding form fields. Pass.
  • Predictive — The label reads "Save Preferences" rather than just "Submit" or "OK." The user knows exactly what will happen. Pass.
  • Available — The button has high contrast (4.5:1 ratio), includes a visible focus ring for keyboard users, and has a clear touch target of at least 44pt. Pass.
  • Consistent — This button uses the same visual pattern as other primary action buttons throughout the app. Users who have performed other actions will recognize and trust this pattern immediately. Pass.
  • Efficient — The button is recognizable at a glance. No user needs to study it to understand what it does. Pass.

Now let's run the toggles themselves through the same framework. Each toggle is a switch component (green when ON, grey when OFF). This is a pattern I see fail constantly.

  • Salient — The toggles have adequate size and use a high-contrast green for the ON state. They're positioned to the right of their labels, following platform convention. Pass.
  • Predictive — The toggle shape communicates flipping, and the color change from grey to green communicates active vs inactive. But without the label above it, the toggle alone doesn't tell the user what's being toggled. The label-text pairing saves this. Borderline pass.
  • Available — Here's where it gets interesting. The toggle's ON vs OFF state is indicated only by color (green vs grey). A user with red-green color deficiency may not be able to distinguish these states. The toggle also lacks a visible position indicator (no dot moving left vs right, no text label like "ON" inside the switch). Fail.
  • Consistent — iOS and Android have slightly different toggle conventions, but within a single platform, this pattern matches expectations. Pass.
  • Efficient — Toggles are among the most efficient interaction patterns when designed well. Users process them pre-attentively. Pass.

The framework reveals a critical failing: the toggle relies entirely on color to communicate its state. The fix is simple: add a dot that shifts position (left for OFF, right for ON), which provides a shape-based signifier that works regardless of color perception. This small change dramatically improves the availability criterion and costs almost nothing to implement.

Interaction Patterns That Communicate Purpose Without a Single Word

Some of the most elegant signifiers in digital design don't use text at all. They rely on motion, spatial relationships, and learned patterns to communicate. Here are a few of my favorites and why they work:

The Pull-to-Refresh Gesture

Loren Brichter's invention for Tweetie (which became the Twitter app) is a masterclass in signifier design. The affordance (pulling down to refresh) is entirely non-obvious to new users. So the original design included affordance cues: the top of the content area showed a visual spring, and as the user pulled, the interface provided immediate visual feedback (the rubber-banding effect) that communicated "there's more happening here."

Today, the pattern is so ingrained that users don't need the cues anymore. But early versions layered multiple signifiers: the spring animation, the loading spinner that appeared on release, and the content that snapped back into place. Each one communicated something different about the state of the interaction.

Dots at the bottom of a carousel that indicate position are a minimal signifier pattern that does surprising amounts of work. They communicate: "There are more panels," "You are here," and "You can interact with me to navigate." The active dot gets highlighted (usually with a different color or size), and inactive dots remain. Hovering over a dot typically reveals or changes its appearance to indicate clickability.

This pattern fails when the dots are too small, too close together, or not contrasty enough. It also fails when the carousel auto-rotates without indicating the progression clearly; users lose track of where they are in the sequence.

The Progress Bar

A progress bar is essentially a signifier for a hidden affordance (the completion of a process). It tells the user: "Something is happening," "We're this far along," and "You should wait." The animated fill communicates progress, and the horizontal bar shape communicates linearity.

I've seen progress bars fail when they jump from 10% to 90% and then sit for 30 seconds at 90%. The signifier has communicated "almost done," but the system hasn't delivered on that promise. The mismatch between the signifier's implication and the actual experience creates frustration.

Drag Handles

The six-dot or three-line drag handle icon (often called a "grip") is a learned signifier for reorderability. It communicates: "You can grab this and move it." The icon uses a familiar visual metaphor (the handle) to suggest physical manipulation.

The grip pattern is interesting because it's one of the few signifiers in digital design that directly mimics a physical handle. It works because users who need it have learned to associate those dots with draggable content. But it fails for users who have never seen it before, which means onboarding or contextual hints are sometimes necessary.

The Shimmer Effect as a Loading Signifier

Skeleton screens — those gray rectangular panels that shimmer while content loads — have become a popular pattern for communicating "content is coming." The shimmer animation signals activity, and the rectangular shapes signal the type and position of the content being loaded. A tall narrow rectangle suggests a sidebar image. A short wide one suggests a text block.

The shimmer effect works as a signifier because it communicates two things simultaneously: the interface is working (the animation signals activity) and something will appear here (the shape signals the expected content type). This is vastly superior to a spinning loader, which communicates only "wait" without any context about what's coming.

But shimmer effects fail when they're too fast (users can't perceive them), too slow (users perceive the interface as broken), or mismatched with the actual content dimensions (the loaded content doesn't match the skeleton's implied layout). Getting the timing and shape right requires careful tuning that many teams skip.

Infinite Scroll vs. Paginated Content

Infinite scroll communicates a specific affordance: there is always more content. The signifiers are subtle: the bottom of the page never arrives, new content appears as the user approaches the end, and a loading indicator briefly appears at the bottom. These signals communicate continuous availability.

Paginated content communicates something different: the content has been organized into discrete chunks. The signifiers are page numbers, "Next" and "Previous" buttons, and breadcrumb-style indicators showing "Page 3 of 12." These signals communicate structure and progress.

The choice between these patterns is essentially a choice about what affordance you want to communicate. Infinite scroll says "stay here, there's always more." Pagination says "you're moving through content with a beginning and an end." Both are valid, but the signifiers need to match the message. I can't count how many infinite-scroll implementations I've seen where the loading indicator fails to appear, and users sit at the bottom of the page wondering if they've reached the end or if the site is broken.

Accessibility and Affordances: Where Clarity Matters Most

Accessibility requirements and good affordance design are essentially the same thing. When you design clear signifiers, you're designing for everyone, but you're especially designing for people who need unambiguous clues about what an interface element does.

Color as the Only Signifier

The most common accessibility failure I see in affordance design is using color as the sole signifier for interactive states. A link that's blue surrounded by black text, with no underline and no hover state change. A required form field indicated only by a red asterisk. A disabled state indicated only by reduced opacity. These all fail the "Available" criteria in the S.P.A.C.E. framework because they exclude users who can't perceive color differences.

The fix is almost always adding a second signifier: an underline, an icon, a text label, a shape change, or a motion cue that reinforces (or replaces) the color signal.

Focus Indicators as Signifiers

Focus indicators (the visible outline or highlight that appears when an element receives keyboard focus) are critical signifiers for keyboard users. They communicate: "You are here" and "You can interact with this element using the keyboard."

I've seen far too many designs that remove or conceal focus indicators because they're considered "ugly." This decision eliminates the primary signifier for users who navigate with keyboards, screen readers, or switch devices. The default browser focus ring may not match your design system, but removing it and replacing it with nothing is unacceptable.

If you don't like the default focus ring, style it. Make it more visible, not less. A 2px solid outline with 3px of offset is WCAG-compliant and can be designed to match your brand. Just don't remove it.

Motion as a Signifier for State Changes

Users with vestibular disorders may experience discomfort from motion-based signifiers like parallax scrolling, animated transitions, or pulsing elements. This doesn't mean you should abandon motion entirely. It means you should provide reduced-motion alternatives and respect the user's operating system setting for reduced motion.

The safest approach: use motion only to communicate state changes (loading, progressing, completing), never just for decoration. And always provide a static alternative for critical information conveyed through motion.

Auditory Signifiers for Multimodal Interaction

Not all signifiers are visual. Sound plays a critical role in communicating affordances, especially in screen reader experiences, voice interfaces, and mobile notifications. A screen reader announcing "Button: Submit" is an auditory signifier that makes the clicking affordance available to users who cannot see the visual cue.

Voice user interfaces present a particularly interesting challenge for affordance design. A smart speaker has no visual signifiers at all. The user must know (through previous experience, onboarding instructions, or auditory prompts) what the device affords. "Say 'Alexa, turn on the lights'" is a verbal signifier for the hidden affordance of voice control. Without it, the user has no way to discover what the device can do.

In mobile interfaces, haptic feedback (vibration patterns) is a tactile signifier for actions like confirming a payment, long-pressing an item, or hitting the end of a scrollable list. These signals work below conscious awareness but provide confirmation that an interaction was registered. Apple's Taptic Engine uses different vibration patterns for success, error, and notification events; each one a distinct signal for a different system state.

Touch Targets and Fitts's Law

Fitts's Law tells us that the time to acquire a target is a function of its size and distance. Small, closely spaced touch targets fail as signifiers because they communicate "you might be able to tap this, but it's going to require precision."

WCAG requires touch targets of at least 44x44dp on mobile. This isn't just a compliance requirement. It's a design principle that acknowledges the relationship between affordance and human anatomy. A target that's too small doesn't just fail accessibility; it fails to communicate the affordance of tapping to users with larger fingers, reduced motor control, or any kind of environmental distraction (walking, holding things, bumpy transit).

Scaling Affordance Knowledge Through Design Systems

Maintaining consistent affordance communication across a large design system with multiple teams is one of the hardest problems in product design. Every button should communicate the same thing everywhere. But as design systems grow, signifier quality degrades. It happens to every team eventually.

I've seen design systems with forty-plus button variants (primary, secondary, tertiary, ghost, outline, icon-only, danger, success, warning, text-link, dropdown-trigger, split-button). Each one slightly different. At that scale, the "Consistent" criterion in S.P.A.C.E. becomes a joke. Users can't learn what a button looks like in your product because there's no consistent "button look" anymore.

The solution is ruthless reduction. Go through your design system's interactive components and ask a simple question: "Does this variant communicate something genuinely different to the user, or is it visually different only because it makes the developers' lives easier?" If it's the latter, kill it. The goal isn't visual variety. It's a consistent signifier vocabulary that users can learn once and apply everywhere.

Documenting Signifier Behavior in Component Specs

Every interactive component in your design system should include documentation about its signifier behavior, not just its visual appearance. This means specifying:

  • Default state visual treatment (shape, color, size, shadow)
  • Hover state transformation (animation, color shift, shadow lift)
  • Focus state visibility (outline, ring, background change)
  • Active/pressed state feedback (scale, color depth, haptic trigger)
  • Disabled state treatment (opacity, cursor, removal of interaction cues)
  • Loading state indication if applicable (spinner, shimmer, pulse)
  • Cursor behavior (pointer, default, grab, text selection)
  • Motion preferences the component respects (reduced motion, prefers-reduced-transparency)

This level of documentation transforms a component library from a visual style guide into a genuine communication system. Developers can implement signifier behavior consistently without having to re-interpret design intent for every component.

Testing Your Affordances: A Simple Protocol for Design Teams

You can't know if your signifiers work until you test them with real users. But you don't need a full usability lab. Here's a lightweight testing protocol I use with teams:

The Five-Second Test

Show someone your interface for exactly five seconds. Then hide it and ask: "What can you click on? What would happen if you clicked each thing?" If the user misses interactive elements or misinterprets what they do, your signifiers need work. This test is brutal and fast, and it catches the most common affordance failures immediately.

The Noise Test

Have someone navigate your interface while you talk to them continuously about something unrelated. The idea is to simulate the divided attention of real-world use. Users online are rarely giving your interface their full focus. If they can't complete key tasks while distracted, your signifiers are asking too much of them.

The Hover Audit

Systematically hover over every element on every page of your interface. Note every element that has no hover state but is clickable (hidden affordance). Note every element that has a hover state but isn't clickable (false affordance). Fix what you find.

The Color Desaturation Test

Take a screenshot of your interface and apply a grayscale filter (most design tools can do this, or you can use a browser extension). If you can't identify interactive elements in grayscale (if primary actions blend into the background), your signifiers depend too heavily on color. Add contrast, shape, position, or spacing cues that work in monochrome.

The One-Thumb Test

Hold your phone with one hand. Can you reach every primary action with your thumb? The thumb zone on mobile is asymmetrical; the bottom third of the screen is easiest to reach, and the top corners are hardest. If a critical CTA is in the top-left corner of a mobile interface, you've placed a signifier where users can't easily act on it, regardless of how clear the visual design is.

References

This article was brought to you by Timothy Graf | GrafWeb exploring the intersection of UX design theory and practical interface craftsmanship. Published by Timothy Graf on timgraf.com. GrafWeb CUSO is at grafwebcuso.com.