UI States and Feedback

Interfaces Need Feedback

A user should never wonder whether something is clickable, whether an action worked, or what to do next. UI states make interaction visible.

Good feedback is part of the design, not a final decoration. A button, link, card, form, or navigation item should communicate what it can do before and after someone interacts with it.

Start With The Default State

Every component starts in a default state. Before adding hover or animation, make sure the default version already looks usable and understandable.

• A button should look clickable before hover.
• A link should look like a link before hover.
• A form input should look editable before focus.
• A card should make it clear whether the whole card is clickable or only a link inside it.

Common States

Active Is Not Current

Active and current are easy to mix up. Active usually means something is being pressed right now. Current means the item represents the page, section, tab, or filter that is selected.

Button States

Buttons need clear default, hover, focus, active, disabled, and sometimes loading states. Focus matters because not everyone uses a mouse.

.button {
  background: #2457d6;
  color: #ffffff;
  border: 0;
  border-radius: 0.375rem;
  padding: 0.75rem 1rem;
  font: inherit;
  cursor: pointer;
}

.button:hover {
  background: #1742a4;
}

.button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

.button:active {
  transform: translateY(1px);
}

.button:disabled {
  cursor: not-allowed;
  opacity: 0.55;
}

Focus Visible

Hover helps mouse users. Focus helps keyboard users. Do not remove the browser outline unless you replace it with a visible focus style.

• Use :focus-visible for keyboard-friendly focus styling.
• Make the focus style easy to see against the background.
• Test with Tab, Shift + Tab, Enter, and Space.
• Focus should appear on links, buttons, form controls, and custom interactive elements.

Link States

Links should be recognizable and usable in every state. Avoid making links depend only on color when they appear inside paragraph text.

a {
  color: #1659c7;
  text-decoration: underline;
  text-underline-offset: 0.15em;
}

a:visited {
  color: #6b3fb5;
}

a:hover,
a:focus-visible {
  color: #0d347a;
  text-decoration-thickness: 0.15em;
}

Current Navigation

A current navigation state helps users know where they are. It should be visible without relying only on color.

<nav aria-label="Main navigation">
  <a href="index.html">Home</a>
  <a href="menu.html" aria-current="page">Menu</a>
  <a href="contact.html">Contact</a>
</nav>

Form Feedback

Form feedback should be specific and connected to the field it describes. Users should know what went wrong and how to fix it.

• Required fields should be clear before submission.
• Error messages should explain the fix.
• Success messages should confirm what happened.
• Helper text should make the expected input easier to understand.
• aria-describedby can connect help or error text to the input.

<label for="email">Email</label>
<p id="email-help">Use an address you check often.</p>
<input
  id="email"
  name="email"
  type="email"
  required
  aria-describedby="email-help email-error"
  aria-invalid="true"
>
<p id="email-error">Enter an email address that includes an @ symbol.</p>

Loading States

Loading states tell users that the system is working. They also prevent people from clicking the same action repeatedly because nothing appears to be happening.

• Change button text from Submit to Sending... or Save to Saving... when work is in progress.
• Disable repeated submit actions while loading when appropriate.
• Use skeletons or placeholders for content that will appear soon.
• Keep loading messages short and specific.

<button class="button" disabled aria-busy="true">Saving...</button>

Empty States

An empty state appears when there is no content to show yet. A good empty state explains what happened and gives the user a useful next step.

Disabled State Caution

Disabled controls can be frustrating when users do not know why the control is disabled. Use disabled states carefully and explain what is needed when the reason is not obvious.

• A disabled button should still be readable.
• Do not use opacity so low that the label becomes hard to read.
• Add helper text when the user needs to complete another step first.
• Sometimes an enabled button with a helpful error message is clearer than a disabled button with no explanation.

Writing Feedback

Good feedback messages are specific, human, and useful. They tell the user what happened or how to fix the problem.

Motion And Micro-Interactions

Small transitions can make feedback feel smoother, but motion should support the interaction instead of distracting from it.

• Use short transitions for hover, focus, opening, closing, and loading feedback.
• Avoid large motion for essential actions like form errors.
• Respect reduced-motion preferences.
• Do not hide important information behind animation timing.

.button {
  transition: background-color 160ms ease, transform 160ms ease;
}

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    scroll-behavior: auto !important;
    transition-duration: 0.01ms !important;
  }
}

Accessibility Checklist

• Interactive elements have visible keyboard focus.
• Color is not the only cue for links, errors, current pages, or success states.
• Form help and error messages are connected to their inputs when possible.
• Disabled states are understandable and readable.
• Loading states prevent duplicate actions when needed.
• Motion is subtle and respects prefers-reduced-motion.
• Messages explain what happened or what to do next.

Component State Checklist