Start with the question each state answers
A default state shows what an element is. Its other states should tell people what is happening or what they can do next. Hover says, “You are pointing at this.” Focus says, “Keyboard input will act here.” Disabled says, “This control is not available right now.” Error says, “Something needs attention.” Treating these as different messages prevents a common design problem: changing every state to a different shade of the same color and hoping people understand why.
Before choosing colors, list the interactive elements in a screen: links, buttons, inputs, checkboxes, menus, and any custom controls. Note which states each one actually needs. A text link may need hover and focus treatments but no disabled state. A form field may need focus and error treatments, sometimes at the same time. This small inventory helps you design a system rather than a collection of one-off effects.
Make hover an invitation, not the only clue
Hover feedback helps pointer users confirm that an element is interactive. A button might change its background or border, while a link might gain an underline. Keep the change noticeable but related to the default appearance; a dramatic shift can make the element seem like a different action. If you use motion, keep it brief and avoid making movement necessary to understand the control.
Do not rely on hover to reveal essential information or the only route to an action. Touch interfaces do not offer a dependable hover experience, and keyboard users navigate without a pointer. A card can become more visually prominent on hover, for example, but its title and primary action should remain discoverable at rest. The default design must still communicate that the card or its contents can be used.
Give focus its own visible treatment
Focus is not a substitute for hover. It marks the element that will receive the next keyboard action, so people need to spot it as they move through a page. An outline or ring outside the element often works well because it remains visible without changing the element’s meaning. Check that it is clear against light and dark surroundings and is not clipped by nearby containers.
Design the focus treatment across components, not just on a sample button. Test a keyboard path through links, form fields, menus, and dialogs to see whether the indicator is consistently visible and the order makes sense. A focus style can coexist with another state: an invalid field still needs a visible focus indicator while someone is correcting it. If the two treatments conflict, give them separate jobs, such as an outer focus ring and an error-colored field border.
Use disabled states sparingly and explain the path forward
A disabled control signals that an action cannot currently be taken. Lower contrast can support that message, but an extremely faint control may become hard to find or read. Keep its label legible and avoid styling it so much like a normal button that people repeatedly try to activate it. Also avoid giving it a hover effect that promises a response it cannot provide.
The more important question is whether disabling the control helps. If a form button is unavailable until required fields are complete, people may not know what to fix. Clear field labels, requirements, and validation messages can provide a better path forward. When an action is unavailable because of a temporary condition, place a short explanation nearby if users would otherwise be left guessing. Distinguish disabled from read-only, too: a read-only value may still need to be selected or copied.
Make errors specific, persistent, and easy to correct
An error state should identify both the affected field and the problem. A red border alone cannot tell someone whether a value is missing, formatted incorrectly, or outside an expected range. Pair the visual treatment with a short message close to the field, such as “Enter an email address” rather than a vague “Invalid input.” Keep the message visible long enough for someone to act on it; do not make it depend on hover.
Color can help people scan a form, but it should not carry the entire meaning. Combine it with text and, where useful, an icon or a change in border style. For custom interfaces, ensure the error is also conveyed to assistive technology through appropriate labels and descriptions. Finally, test the full sequence: an empty field, an incorrect entry, a focused field with an error, and a corrected value. Good state design does more than announce a problem; it makes recovery feel straightforward.
