A button is not finished when the default state looks good.
That is only the poster image. The real button is everything that happens before, during, and after the click.
If those states are missing, users feel it. The button may look polished in a screenshot and still feel unfinished in the product.
Every button needs a few normal states. They do not need to be dramatic. They just need to exist.
A simple hover background shift can be enough. A tiny active scale can be enough. A clear focus ring can be enough.
The point is not to decorate the button. The point is to answer the user's question: can I use this, and did it hear me?
A pending button and a disabled button look similar in many products, but they mean different things.
Disabled means the action is not available. Pending means the action was accepted and work is happening.
If a user clicks "Save changes" and the button simply turns gray, they may wonder if the click worked. A better pending state says what is happening:
Saving...Inviting...Uploading...Keep the pending signal attached to the button that caused it. The user clicked one control. That control should explain the wait.
Not every button needs a success state, but many do. If the result is not visible somewhere else, the button may need to confirm it.
For example, after saving settings, the button could briefly say
Saved. After copying a link, it could say Copied.
Those states are small, but they remove doubt.
Error is the same. If an action fails, do not just return the button to normal. Tell the user what happened and how to recover.
"Try again" is often better than a silent reset. The user should not have to guess whether the request failed or never started.
A destructive button is not just a red button. It is an action with a higher cost.
The design should make that cost clear. Sometimes that means a red style.
Sometimes it means a confirmation step. Sometimes it means changing the
label from Delete to Delete workspace so the user
knows exactly what is about to happen.
The more serious the action, the more specific the button should be.
On mobile there is no hover. The tap target matters more. The button may need more height, more padding, or more space around it.
A 32px icon button may look tidy in a desktop toolbar. On a phone it can feel hard to hit, especially if it sits next to other controls.
The visual shape and the hit area do not have to be identical. An icon can look small while the clickable area stays comfortable.
Loading labels should not make the layout jump. If Save
becomes Saving changes..., the button may grow and push
nearby actions.
That movement happens at the worst moment: right after the user trusts the product with an action.
Reserve enough width, keep the outer button stable, and change the content inside it. The state can change without the layout moving.
Before calling a button done, check it like this:
A button is small, but it carries a lot of trust. It should feel finished when it is used, not only when it is viewed.