How many button states does an interface need?

Separate interaction feedback from task state

Default, hover, pressed and disabled describe interaction feedback. Pending and selected describe a task or a value. Treating all of them as one flat list can hide combinations such as a focused button while a request is pending.

Touch may provide no hover feedback; keyboard users need a visible focus location. Check each input method and the state combinations supported by the component.

The W3C button pattern explains keyboard behavior, accessible names and toggle state. Prefer native buttons for actions on the web, and links for navigation.

Handle waiting and duplicate actions together

Without feedback after Save, people may press it again. Show progress and decide whether the same action can be invoked while pending. Check that a changing label does not shift nearby controls.

Preventing repeated clicks is only one layer. Refreshes and retries can still produce duplicate requests, so operations that must not repeat need a corresponding server rule.

Completion should expose a result or a useful failure. Decide whether inputs remain available and whether the user can retry immediately or needs to check the previous result first. That decision determines when re-enabling the control is appropriate.

Explain persistent selection and unavailability

Filters and toggles retain a selected value after activation. Distinguish that value from a transient pressed effect, and decide whether it persists after leaving the screen or combines with other selections.

Explain unavailable actions near the control. Missing input, insufficient permission and an operation already in progress each suggest a different next step. A hover-only explanation is difficult to discover through touch or keyboard interaction.

Use text, an icon or another clear state cue alongside color. An unavailable button should still help the user understand what needs to happen before the action becomes possible.

Test transitions, not only static appearances

Static examples are useful, but also exercise transitions: submit and succeed, fail and retry, or leave the screen while a request is pending.

• Reach and activate the button using a keyboard.
• Check where focus remains during and after the operation.
• Make success and failure understandable without color alone.
• Try long translations in a narrow layout.

Review visual states in the shared component and request-to-result behavior in the screen flow. Before adding a state, explain the information it gives the user and which decision that information supports.