Interaction states
An interactive element isn't finished until all of its states are designed. States are how the interface answers “can I touch this? did it hear me? what happened?” — feedback that matters most when someone is working fast under pressure.
The states every interactive element needs
A control is a small state machine. Designing only the default state leaves the others to chance — and those are exactly the moments a user is unsure whether the product responded.
| State | Its job |
|---|---|
| Default | The resting state. Looks interactive without demanding attention. |
| Hover | Confirms “this responds” on pointer devices. A subtle shift, not a jump. |
| Focus | Shows keyboard position. Must be clearly visible — this is an accessibility requirement, not a style choice. |
| Active / pressed | Acknowledges the moment of interaction. Brief and physical. |
| Selected | Persists a choice — a chosen tab, a checked row. Distinct from hover and focus. |
| Disabled | Communicates “not available now”. Dimmed and non-interactive, with the reason nearby if not obvious. |
| Loading | The action was received and is in progress. Prevents double-submission. |
| Error | This control needs correction. Paired with a message, never color alone. |
Default, disabled, loading — seen together
Hover and focus are best felt live (try tabbing to these), but the resting states should read clearly side by side. Disabled recedes; loading shows the action is in flight.
Focus is not optional
A visible focus indicator is how keyboard, switch, and screen-reader users navigate. It is provided by default across Fortiv components — removing it without an equally visible replacement breaks the product for those users. Tab into the field below to see it.
Keep a clearly visible focus ring on every focusable element.
Don't set outline: none without providing an equivalent visible indicator.
Make focus and selected visually distinct — they mean different things.
Don't rely on hover to reveal an action; keyboard users never trigger it.
Feedback should be immediate and proportional
The state change is the receipt for an interaction. It should happen at once, and its size should match the event — a subtle hover, a clear pressed state, an unmistakable error.
Show a loading state the instant an action is triggered, so the user knows it landed.
Don't leave a button looking idle after a click — people will click again.
Disable a submit button while its request is in flight to prevent double-submission.
Don't animate state changes slowly; feedback under 150ms feels instant (see Motion).
Disabled needs a reason
A disabled control raises a question: why can't I use this? If the reason isn't obvious from context, surface it — a tooltip, helper text, or an inline note — rather than leaving the user stuck.
Explain why something is disabled when the cause isn't visible (“Add an activity first”).
Don't disable a primary action with no hint of what would enable it.
Prefer guiding the user to the fix over a dead, unexplained disabled state.
Don't use disabled styling for read-only display; they mean different things.