A button has five real states — default, hover, active, disabled, loading — and most systems only ever design the first two.
Default gets the initial design pass, hover gets a quick pass because it's easy to preview in a browser, and then active, disabled, and loading get whatever the framework does by default, which is usually nothing.
That gap is invisible until a real user hits it: a slow network request looks identical to a broken button when there's no loading state, so the obvious thing to do is click again, and now the form has submitted twice. A disabled button with no visual distinction looks clickable, so someone taps it, waits, and assumes the site is frozen.
None of this is really a design failure — it's a token gap, the same shape as every other one in this series. Name the missing states as tokens instead of leaving them to accident: `button-bg-hover`, `button-bg-active`, `button-opacity-disabled`, `button-loading-shimmer`.
The loading token matters most, because it's the only one solving an actual communication problem — a shimmer sweep across the button is a small, constant signal that the click landed and something is happening, which is the entire difference between "the site is broken" and "the site is thinking." Once all five states are named and referenced everywhere a button appears, a user never has to guess what just happened when they click.
Leave a Reply
You must be logged in to post a comment.