Default State

The button drawn in a mockup is almost always the version with no interaction happening. When nobody names that as one state among several, both the person handing it over and the person building it treat the single image as the whole button.

Everything else then gets decided by whoever is implementing, in the moment. Inside one product, one button darkens when the pointer arrives, another grows a border it didn't have, and a third does nothing at all. The user has to relearn which things are clickable on every screen, which is a cost paid over and over for a decision nobody made on purpose.

Naming the baseline changes the conversation. Settle the reference version first, and everything else can be written down as what changes relative to it.

Fix every value of the element in its default state, then describe the remaining states as rules for what shifts and by how much.

The default state settles background color, text color, border weight and color, internal padding, corner radius, and text size. Once those six are set, how much visual weight the element carries on the page is decided.

The other states are recorded only as differences. Hover, the appearance while a pointer rests on the element, darkens the background one step. Focus, the state a keyboard or assistive device has selected, adds a two-pixel outline. Active, the moment while the element is being pressed, darkens two steps. Disabled, meaning unavailable right now, drops opacity to 40 percent.

Written this way, twenty buttons on a screen still need only one set of mockups. Because all twenty follow the same rules, the user also only learns them once.

The place this gets tricky is when the default state resembles another state. A button with no border and only a pale gray background is indistinguishable from a dimmed, disabled one. The user finds out it was clickable by clicking it, which is exactly the discovery a baseline is supposed to prevent. A default state only works as a reference if it is clearly distinct from all four of the others.

"You've only given me the default state. What should hover and disabled do?"

A single reference image is not enough to start building.

"The default state on this button looks disabled. Let's add a border or darken the background a step."

When the baseline overlaps another state, everything derived from it wobbles.

"Let's write the state rules into the system once and only draw default states per screen."

Stop redrawing the same rules on every screen.

At Pagedeck, Noa defined one default state each for buttons, text fields and menu items, and wrote the per-state change rules next to them. When Theo builds a new screen he receives only the default state and applies the other four from the rules. The same question stopped coming back screen after screen.