Deep dive · 03
You drew one button —
why draw six more?
Hand over only the resting state and the developer invents the rest. Then you look at the result and say “that is not what the design showed”. Let us compare directly.
With states and without
On both buttons, hover, press, and Tab to them.
No states ✗
Nothing responds when pressed, so people think “did that register?” and press repeatedly.
With states ✓
It lightens on hover, sinks on press, and gains an outline on Tab.
What actually happens: A pay button with no press feedback got pressed three times, and three orders went through. States are not decoration — they prevent misfires.
UI that does not respond feels broken. And it genuinely causes duplicate submissions.
What has to be defined
Define these six for every component and development stops guessing. Try each.
The resting look. It has to look pressable.
When the pointer rests on it. It does not exist on mobile — anything given only on hover is invisible there.
When reached by keyboard Tab. Never remove it. Anyone who cannot use a mouse gets lost.
The moment it is held down. It goes when the finger lifts, and it prevents duplicate clicks.
Chosen and kept that way. Needed for tabs and filter chips. Different from pressed.
Not usable right now. You have to say why or people simply get stuck.
Default · hover · focus · pressed · selected · disabled. Add loading for anything waiting on data and that makes seven. Draw them into the mockup and hand them over together.
The most frequent accident
A menu that worked perfectly on desktop will not open at all on mobile.
On desktop, hovering unfolds the sub-menu. But a finger cannot “rest on” anything. Mobile users either never open this menu, or get strange behaviour on the first tap.
Use hover as a supplement onlyand always make it open on click (tap) as well. Never put important information in a tooltip.
How to check — open this page on your phone and press the dotted text below. If nothing happens, that is the problem.
Paying also earns you points.
Nothing should be reachable by hover alone. To a mobile user it is a feature that does not exist.
“Why will it not press?”
A disabled button is just a wall unless it says why. Compare the two approaches.
No reason given ✗
People leave the screen without knowing what is missing .
Reason shown ✓
There is a better option — leave the button enabled and, on press, point out what is missing. People never experience “why will this not work?”
Now ask for it like this
Please build a button component. Default, hover, focus, pressed, disabled and loading — define all six states. Show focus with :focus-visible so it appears only on keyboard navigation.
Please make sure this menu does not open on hover alone — there is no hover on mobile, so it must open on click (tap) as well.
When the submit button is pressed, switch it to a loading state and block duplicate clicks. Return it to its original state once the response arrives.
Add a note explaining why it is disabled below the disabled button. Once the conditions are met, the note disappears and the button becomes active.
Please do not remove the focus ring (the outline on keyboard navigation). If it clashes with the design, restyle it in the brand colour instead.
Hand over the states and the number of design QA items halves.
WHY THIS MATTERS
The resting state is
one sixth of the work.
To say a button is “finished” you have to draw six. Without states in the mockup the developer fills them in by guessing, and all of it comes back in design QA.