Imagine a simple scene. You open a subscription screen. Three cards side by side. One has a clear border and a “Most Popular” tag. The second looks normal. The third is slightly dimmed. Before you read any text, you already more or less understand what is going on: the first one is promoted, the second is available, and the third probably cannot be selected right now or requires a different condition.

That is exactly what UI signifiers are about. A good interface does not have to explain everything using additional text hints. Its very form should show what belongs together, what is active, what responds to a click, and what is temporarily unavailable. The user should see that before they even start to wonder.

Why This Is Not Just an Aesthetic Detail

It is easy to confuse “clean” with “clear” in UI/UX design. We remove borders, reduce contrast or hide descriptions because we want the screen to feel lighter. But users do not come to admire the composition. They come to complete a task. And if they cannot immediately tell what is clickable, what has been selected, and what will change after an action, the UI turns into an obstacle.

NN/g has pointed out for years that weak clickability cues increase the effort needed to understand a screen. And it is not just an academic issue. The moment the user pauses over a screen to think “Is this a link or just text?” or clicks something that looks like a button and discovers it is only a decorative tile, the site looses trust.

So the core idea is simple: a good interface should not depend on instructions for basic comprehension. It should embed meaning in the appearance and behavior of its elements. 

Affordance and Signifier: What Is Good UX Made of?

The simplest way to differentiate the two is this: affordance is what an object allows you to do, while a signifier tells the user they can do it.

A form field allows you to enter text; that is its affordance. However, the user recognizes this capability through signifiers such as the label, border, text cursor, and sometimes an icon.

A button allows you to trigger an action. While its affordance technically exists even if it’s designed without contrast, an active state, or a response when pressed, the user won’t receive a strong enough signal that it’s interactive.

This distinction is even more crucial on digital screens, where almost every pixel could potentially appear interactive. Therefore, the interface must communicate clearly through its form, conveying messages like “this works,” “this is selected,” “this is inactive,” or “you are here.”

How Signifiers Work on an Ordinary Screen

Consider a few basic elements that are almost universally present.

A container establishes order. When a section shares a background, border, or consistent spacing, it is immediately perceived as a cohesive unit. This is a simple yet powerful cue. You don’t need to label every block “payment settings” if the structure already conveys that meaning.

A selected state guides decision-making. In filters, tabs, segmented controls, or pricing plans, users should instinctively see which option is active. A border, fill color, checkmark, or typography change isn’t mere decoration; it’s vital information.

A grayed-out element signals unavailability, which is effective to a certain extent. A dimmed button indicates “not now,” but it doesn’t independently explain “why not now.” If the reason isn’t obvious, the disabled state leaves the user uncertain.

“Hover” and “press” demonstrate responsiveness. Material Design considers hover, focus, and pressed as core interaction states of a component, not optional visual effects. Apple, similarly, explicitly recommends that custom buttons always have a pressed state, as its absence can make a button feel unresponsive. This is a practical point: a lack of reaction after a tap or click immediately creates uncertainty.

A tooltip helps clarify meaning, but only as a supplement. While a trash icon that isn’t immediately clear without a tooltip can still be defensible, a design where the full meaning of an action relies solely on hover starts to lose stability, especially on mobile.

Practical Rules Worth Following

First, do not make users guess what is clickable. A link should look like a link, a button like a button, and a field like a field. This sounds obvious, but it’s precisely where “overly elegant” screens most often encounter problems.

Second, show state; do not assume the user remembers it. If something is selected, it should be immediately visible, not discernible only after comparing subtle shades of gray.

Third, do not build meaning with color alone. WCAG reminds us that color should not be the sole carrier of information and that focus also needs to be clearly visible. This is important not just for formal accessibility but for everyday product use.

Fourth, design states beyond the desktop. If your only interaction cue depends on hover, that entire layer of communication disappears on touchscreens.

Fifth, if you block something, provide a trace of the reason. A dimmed “Next” button without any hint isn’t smart guidance; it’s quiet frustration.

Where Do You Most Often See Poorly Designed Signifiers?

First, in many places, everything looks clickable. Cards, tiles, section headings, icons, and badges all carry a similar level of visual “importance,” leading users to test the interface through trial and error.

The second classic mistake is active navigation that is barely visible. A tab might be marked only with slightly heavier text or a barely different shade. While a technical difference exists, in practice, it disappears.

The third mistake is an invisible focus state. For someone navigating with a keyboard, this isn’t a minor detail; it’s essential for orientation. If the current focus is unclear, the interface loses predictability.

An Honest Counterargument: Form Alone Is Not Always Enough

We must be plain about it: not every interface should be stripped down at all costs.

In a simple plan selection flow, account settings, or basic navigation, strong visual form can replace a fair amount of microcopy. However, in a credit form, a legal consent flow, privacy settings, or a medical process, visual suggestion alone may be too imprecise. Users need not only a signal that says “click here” but also confidence about what that decision means.

So the counterargument is valid: sometimes explicit labels, instructions, or short explanations improve safety and understanding more than the most elegant UI state ever could.

This does not overturn the main point; it refines it. Good signifiers should reduce the need to explain basic things. They should not replace clear communication where the stakes of a decision are high.

Two Quick Implementation Examples

An example supporting the main point: Material and Apple component systems describe button, field, and selection states very clearly. This is useful because it demonstrates that a modern interface should not be silent. It should respond, show focus, indicate a pressed state, and clearly communicate selection.

An example based on the counterargument: In financial flows or privacy settings, the active state of a control is often not enough on its own. You may need a note explaining the consequence of a choice, the condition required to activate something, or the reason an option is blocked. In these situations, reducing text is not a virtue in itself.

Checklist Before You Hand Off a Screen

  • Can the user immediately see what is clickable?
  • Can they see what is currently selected?
  • Is the focus state clearly visible?
  • Does an unavailable element have a clear reason behind its state?
  • Does meaning rely on more than color alone?
  • Does the same message still work without hover?
  • After an action, does the system signal that something happened?

Finally, do one simple exercise. Take a screen, remove the helper labels, and leave only the components, states, and structure. If it is still clear what can be done, the signifiers are working. If not, the interface is trying to be minimal at the expense of clarity.

UI without instructions does not mean UI without communication. It means communication embedded in form, states, and element behavior, with text appearing where it truly adds something instead of rescuing a design that cannot explain itself.

Sources: