Affordances and Feedback: Making Interfaces Feel Obvious

UI/UX

Most of the usability problems I see in client work do not come from missing features or ugly screens. They come from interfaces that leave the user guessing. Can I click this? Did that button do anything? Is the form still loading, or did it quietly break? Two of the oldest ideas in interaction design answer almost every one of these questions: affordances, which tell a user what an element does and how to use it, and feedback, which tells the user what just happened. When we sit down to fix a product that “feels off” but no one can quite say why, we nearly always find the fix hiding inside one of these two concepts. They are unglamorous, they predate every design trend, and they still explain the majority of the wins we ship. This post is my attempt to lay out how I think about both, why they matter more than most visual polish, and how we apply them in real projects at our studio.

What Affordances Actually Are

An affordance is a relationship between an object and the person using it. A door handle affords pulling. A flat plate on a door affords pushing. In screens we borrow the idea loosely: an affordance is the property of an interface element that suggests how it can be used. A raised, coloured rectangle with a label affords clicking. An underlined phrase affords following to somewhere else. A text field with a blinking cursor affords typing. The key thing is that affordances are about possibility. They answer the question “what can I do here?” before the user has to think about it.

It helps to separate two versions of this. A real affordance is what the element can genuinely do: this button really will submit the form. A perceived affordance is what the user believes it can do based on how it looks. Good design collapses the gap between the two. Trouble starts when they diverge, in either direction. If something looks clickable but is not, you get frustration and dead clicks. If something is clickable but does not look it, you get an interface people never fully explore because they never realise the option was there.

There is a related idea that does most of the heavy lifting in practice: the signifier. Don Norman drew this distinction to fix a confusion in his own earlier writing. The affordance is the possibility of action. The signifier is the perceivable cue that advertises that possibility. A link can afford navigation, but the underline and the colour are the signifiers that tell you so. When people say a design “has good affordances,” they usually mean it has clear signifiers. In our internal reviews we mostly talk about signifiers, because that is the part we can actually draw, adjust and test.

Why Flat Design Weakened Our Signals

For a long stretch, interfaces leaned on skeuomorphism. Buttons had bevels, gradients, drop shadows and pressed states that mimicked physical objects. It was often overdone and heavy, but it had one real virtue: the signifiers were loud. Nobody had to wonder whether a chunky, glossy, shadowed rectangle was a button. Then the pendulum swung hard toward flat design. Gradients disappeared, shadows were stripped out, borders vanished, and everything became clean coloured rectangles and plain text on generous whitespace.

Flat design looked modern and it photographed beautifully in a portfolio, but it quietly removed a lot of the cues that told users what to do. A flat coloured rectangle and a flat coloured tag can look identical even though one is interactive and one is decoration. Text that happens to be a slightly different colour might be a link, or might just be styled text. The result was a wave of interfaces that were attractive and confusing at the same time, where users had to hover, tap and probe just to learn the vocabulary of the page.

The industry course corrected into what people call flat two point zero, which keeps the clean aesthetic but reintroduces just enough signalling: subtle shadows to lift interactive elements, faint borders, a touch of depth on hover, clearer separation between what is a control and what is content. That middle ground is where I want almost every project to live. I am not arguing for a return to glossy bevels. I am arguing that a flat look is a style choice, and clarity is a requirement, and when the two conflict, clarity wins. This ties into a broader principle we lean on constantly, which is that people spend most of their time on other people’s products, so they arrive with strong expectations about how things should look and behave. Fighting those expectations for the sake of a novel aesthetic is a tax you make every user pay. We wrote more about that idea in designing for familiarity, and affordances are one of the most concrete places it applies.

Making Buttons Look Like Buttons

This sounds almost too obvious to write down, and yet it is the single most common fix we ship. A button should read as a button before anyone reads its label. That usually means it needs a filled background or a clear border, enough padding that it feels like a distinct target rather than a line of text, a shape the rest of the page reserves for actions, and a colour that stands apart from ordinary content. When every one of those cues is present, the click happens without thought. When they are stripped away in the name of minimalism, users hesitate, and hesitation is the enemy.

A worked example from the kind of dashboards we build. A team had a primary action styled as plain coloured text with no background, sitting inside a busy toolbar next to several other bits of coloured text. Analytics showed people were missing it entirely and using a slower path through a menu instead. We changed nothing about the layout. We simply gave the primary action a solid filled background and a bit of padding, and demoted the secondary actions to outlined or plain styles. Usage of the fast path climbed sharply, and the support questions about “where do I save” faded. No new feature, just a signifier doing its job.

The same logic applies to hierarchy among buttons. If three buttons all look equally loud, you have told the user nothing about which one you expect them to press. We use a simple ladder: one primary style that is filled and high contrast for the main action, a secondary style that is outlined or muted for the safe alternative, and a tertiary or text style for low stakes actions like “cancel”. This is partly about affordance and partly about placing the important target where it is easy to hit. Bigger, closer targets are faster to acquire, which is the essence of how target size and distance shape interface speed, and the primary action almost always deserves the biggest, most obvious treatment on the screen.

Links, Drag, Scroll and Swipe

Links deserve their own note because the web spent years teaching people that underlined or distinctly coloured text can be followed, and then a lot of designers spent years removing the underline for tidiness. If you take away both the underline and the colour difference, an inline link becomes invisible, and content that was meant to guide people through a site becomes a dead end. My rule is simple: inline links inside body text should be visually distinct in a way that does not rely on colour alone, because colour alone fails for a meaningful slice of users. An underline, a weight change, or both, does the job. Navigation links styled as obvious tabs or menu items can rely on position and grouping instead, because their context already signals what they are.

Gestural affordances are harder because the cue often has to imply motion on a static screen. Drag handles are the classic case. If a card can be reordered by dragging, there needs to be something that says so: a grip icon of little dots, a cursor that changes to a move cursor on hover, or the card visibly lifting when pressed. Without any of that, drag is a hidden feature that only power users discover by accident. The same goes for content that scrolls horizontally inside a vertical page. If a row of cards continues off the edge, you need a peek of the next card, a fade, or an arrow, otherwise most people will never know there is more to see.

Swipe is the trickiest of all because on touch there is no hover state to lean on and no cursor to change. This is where signifiers have to be deliberate: a partial reveal of the action hiding behind a list item, a small handle on a bottom sheet that invites you to pull it up, dots or a peeking edge that hint a carousel can be swiped. A pattern I insist on is never making a gesture the only way to do something important. If swiping left deletes an email, there should also be a visible control that deletes it, because the gesture is a shortcut for people who know it, not the sole path. Hidden gestures are wonderful accelerators and terrible primary interfaces.

Feedback: The System Talking Back

If affordances answer “what can I do,” feedback answers “what just happened.” Every action a user takes is a small act of faith, and feedback is how the system keeps that faith. Press a button and it should visibly respond. Submit a form and something should acknowledge the submission. Delete an item and the item should leave, ideally with a moment to undo. The absence of feedback is not neutral. Silence reads as failure. When a user taps something and nothing changes, they do not assume it worked. They assume it broke, and they tap again, which is how you end up with duplicate orders and double submissions.

The most fundamental rule of feedback is that it must be immediate. The response to a press does not have to be the finished result, but it does have to be instant acknowledgement that the input was received. This is where the perception of speed comes from, and perception matters as much as the raw number. An interface that responds to every touch within a fraction of a second feels fast even when the real work takes longer, because the user is never left wondering whether their input landed. There is solid old research behind this, captured in what people call the productivity threshold: when a system responds to a user in well under a second, people stay in flow and actually work faster and more happily. We treat that sub second acknowledgement as non negotiable, and we go deeper on it in the response time that keeps users in flow.

Crucially, feedback and affordances are not two separate checklists. They work as a loop that builds a mental model. The signifier promises what will happen, the user acts, the feedback confirms the outcome, and each successful loop teaches the user a little more about how the system behaves. After a handful of these loops the user trusts the interface enough to move quickly and stop reading every label. Break the loop, by promising an action that does nothing or by staying silent after an action, and trust collapses. Once trust is gone people slow down, double check everything, and start blaming themselves or your product for a confusion you built into it.

The States Every Interactive Element Needs

An interactive element is not one thing that sits still. It is a small set of states, and each state is a piece of feedback. When we build or review a component, we walk through the full set rather than designing only the resting look. The default state is how it sits at rest. The hover state, on devices that have a pointer, confirms the element is interactive and about to receive a click. The active or pressed state fires the instant of the press and is the most immediate feedback there is, the digital equivalent of a physical button giving way under a finger. The focus state shows which element the keyboard is currently on, and it is not optional, because people navigating by keyboard or assistive technology are lost without a clearly visible focus ring.

Then come the states that describe what is happening over time. A disabled state signals that an action is not available yet, though I always push teams to also answer the obvious next question, which is why it is disabled and what the user must do to enable it. A loading state covers the gap between an action and its result, and it should reflect how long that gap is likely to be: a small inline spinner on a button for a quick action, a skeleton layout for a page that is fetching data, a progress indicator for anything genuinely slow. A success state confirms the good outcome, and an error state explains the bad one. Miss any of these and you create a moment where the user does not know where they stand.

A concrete example we run into often is the submit button on a form. In its resting state it looks obviously clickable. On press it shows an active state so the tap feels registered. The moment it is pressed for real it should switch into a loading state, usually a spinner inside the button plus disabling the button so it cannot be pressed twice, which is the single most effective cure for duplicate submissions I know. When the server responds it resolves into either a success state, which might be a confirmation message or a move to the next screen, or an error state that says precisely what went wrong and how to fix it. That one button, handled across all its states, is a masterclass in feedback, and getting it right is a large part of why some forms convert and others leak users. We pulled that thinking together in a longer piece on designing forms that people actually complete.

Errors That Help Instead of Scold

Error feedback is where a lot of otherwise decent interfaces fall apart, because errors are treated as an afterthought and written by whoever was nearest the keyboard. A good error message does three things. It says what went wrong in plain language, it explains why or what the constraint is, and it tells the user how to put it right. “Something went wrong” fails all three. “That email address is already registered. Try signing in instead, or use a different address” passes all three and turns a dead end into a next step.

Placement and timing matter as much as wording. An error about a specific field should appear next to that field, not in a summary banner far from the problem, and certainly not only after the whole form is submitted if it could have been caught earlier. At the same time, I am wary of validating too aggressively while someone is still typing, because flagging an email as invalid before they have finished entering it is its own kind of rudeness. A pattern that works well is to validate a field when the user leaves it, show a clear inline message if it fails, and clear that message the moment they correct it. The feedback should feel like a helpful colleague looking over your shoulder, not a strict examiner marking you down.

The worst error of all is the silent one. A silent failure is when something breaks and the interface says nothing, leaving the user to assume it worked. A saved setting that did not save, a message that did not send, a payment that did not go through, all with no indication of trouble. These destroy trust faster than any loud error, because the user only discovers the problem later when the damage is done. I would far rather a system tell someone honestly that an action failed and offer to retry than let them walk away believing a thing happened that did not. Honest failure is recoverable. Silent failure is a betrayal the user does not even know is happening.

Optimistic UI, Sound and Haptics

Optimistic UI is a technique for making feedback feel instant even when the network is slow. Instead of waiting for the server to confirm an action before updating the screen, you update the screen immediately on the assumption that the action will succeed, then reconcile if it does not. When you like a post, the heart fills at once rather than after a round trip. When you send a message, it appears in the thread straight away. This makes an app feel dramatically faster and keeps the user in flow. The catch is that you owe the user honesty when the optimism turns out to be wrong. If the action fails, you must gracefully roll back and tell them, not leave a phantom success on screen. Done with that discipline, optimistic UI is one of the most powerful perception of speed tools available. Done carelessly, it is just a prettier form of silent failure.

Sound and haptics extend feedback beyond the visual, and they are best used with restraint. A subtle haptic tap when a toggle flips, a gentle vibration when a payment confirms, a quiet click on a successful scan: these reinforce the visual signal in a way that feels satisfying and reduces the need to stare at the screen. The danger is overuse. An app that buzzes and chimes at every minor interaction becomes exhausting and gets silenced, taking the useful signals down with the noise. My rule is to reserve non visual feedback for moments that genuinely warrant it, usually confirmations of meaningful actions or alerts that need attention when the user may not be looking, and to always let people turn it off. It is seasoning, not the meal.

The Common Failures We See Again and Again

When we audit a product, a handful of failures show up so often that I could almost predict them before opening the file. Mystery meat navigation is the first: controls that give no clue what they do until you interact with them, icons without labels that could mean three different things, menus hidden behind ambiguous symbols. The fix is rarely subtle. Add labels, add tooltips, use icons that match established conventions rather than clever inventions, and stop asking users to decode your interface like a puzzle.

Dead clicks are the second: elements that look interactive but do nothing, or areas users reasonably expect to be clickable that are not, like a card whose image and title look tappable but only a tiny link inside actually works. Every dead click is a small broken promise, a case where the perceived affordance wrote a cheque the real affordance would not cash. We hunt these down by asking, for every element that looks like a control, whether it behaves like one, and for every place a user might reasonably expect to click, whether we have made the whole sensible target work. The missing loading state is the third, where an action fires but nothing indicates work is happening, so the user waits in doubt or retries. And the silent failure, covered above, is the fourth and most damaging. These four account for a startling share of the “it just feels clunky” complaints that bring clients to us in the first place. Many of them map cleanly onto long standing usability principles, and if you want the fuller framework we check work against, it lives in the ten usability heuristics that still hold up decades on.

A Practical Checklist In Prose

When I want to sanity check whether an interface feels obvious, I run through a short set of questions rather than a rigid form. For affordances I ask: can a first time user tell what is clickable without hovering or tapping to find out? Do buttons look like buttons, with a shape and treatment reserved for actions? Are links distinguishable by more than colour alone? Where a gesture like drag, scroll or swipe is available, is there a visible cue that it exists, and is there also a non gesture way to do anything important? Is there one clear primary action per screen, sitting where it is easy to reach, styled loudly enough that the eye lands on it first?

For feedback I ask a parallel set: does every interactive element respond the instant it is touched, before any real work completes? Does every element have a visible hover, active and focus state, and is the focus state strong enough to navigate by keyboard? Whenever an action takes more than a moment, is there a loading indicator matched to the wait, and is the control disabled so it cannot fire twice? When something succeeds, is that confirmed, and when something fails, does the message say what went wrong and how to fix it, right next to where it happened? Is there anywhere the system could fail silently, and if so, how do we make that failure honest and recoverable?

If the answers are yes, the interface will usually feel obvious, and users will move through it quickly and trust it. If the answers are no, no amount of visual polish will save it, because polish decorates a surface while affordances and feedback decide whether the surface makes sense at all. That is the quiet lesson of these two old ideas. They are not the exciting part of a project and they never win the compliments that a striking layout does, but they are the part that decides whether people can actually use the thing. In our studio we treat them as the floor, not the ceiling. Get affordances and feedback right first, make the interface obvious, and then spend the remaining energy making it beautiful. Do it the other way round and you will have a gorgeous product that people quietly give up on, which is the most expensive kind of failure there is.