Button

A paper form has nothing to press. Fill in the boxes, hand it to a clerk, and a person takes it from there. Moving the same task onto a screen created a problem that never existed before: the screen itself has to say what turns a filled-in form into a submitted one.

Early screens were bad at saying it. Text was just text, and nothing distinguished the part that could be pressed. So the calls came in: "I've filled everything in, now what?" There was a blue word reading "Next" at the bottom of the screen, and nothing told anyone it could be pressed.

A button is the convention that answers that. Fill a background, draw a border, add a shadow so the thing looks unlike the text around it, and people know to press there without being taught. It carries a physical button's property onto the screen — the shape sticks out, so nobody has to be told to push it.

It shows that it can be pressed, confirms that it was pressed, and locks itself until the result arrives. Which means building one button really means building five appearances of it.

1. Default — how it looks at rest. This is where the background or border that separates it from surrounding text gets decided.
2. Hover — the color deepens slightly or a shadow appears. The signal that this is what the pointer is currently on.
3. Pressed — the color deepens further or the shape sinks a little. It confirms contact from a finger or a mouse the instant it happens.
4. Disabled — dimmed, to say it can't be used right now. Used where submission is blocked because a required field is empty.
5. Pending — after the press, a spinner runs until the response arrives and the control locks so it can't fire twice. It's a loading state placed inside the component.

A sixth appearance comes from the keyboard: the outline shown when focus lands on it. People who can't use a mouse move through a screen with the Tab key, and if there's no visible sign of where they are, they can't reach checkout. That's why accessibility gets settled at the component level before the screen level.

Two more decisions sit beside appearance. One is how many prominent buttons a screen carries. Keep one filled with solid color and demote the rest to outlined or text-only. Three solid buttons side by side means three emphases, which is the same as none. The other is the label. "Confirm" doesn't say what is being confirmed, so write what pressing will do as a verb — "Pay now," "Send invite."

It's the same component everywhere, but the job changes with the position.

1. The submit slot on an input screen. Signup, checkout — whatever gets pressed last, after the values are filled in. It travels in a pair with the text input, which is the field that takes typed characters; sending what was typed is the button's half of the job.
2. Confirm and cancel in a window. In a modal, which blocks everything else until it's answered, buttons are the only way out. When the action can't be undone, the confirming one gets a dangerous color here.
3. Actions inside a list. Share or delete attached to each row of a document list. Twenty rows means twenty copies of the same control, so it shrinks to a smaller size or down to an icon alone.
4. The invitation on a landing page. The spot that urges a visitor toward the next action, known as a call to action (CTA). One word in the label moves actual signup counts here.

Different positions call for different sizes and weights, and deciding that per screen grows a single product into ten kinds of button. So the types and sizes get fixed to a handful in advance and stored in the design system, the single set of reusable rules and components a team works from.

Touch screens add a lower bound on size. Sized to the height of its text, the pressable area ends up smaller than a fingertip, and people press something that appears to do nothing. Keep the pressable area around 44 pixels on a side, independent of how large it looks. A text-only control 20 pixels tall passes review on a laptop and then fails in someone's hand on a moving train.

"There are three solid buttons on this screen. Let's keep one and demote the rest."

A proposal to decide what the screen is actually recommending.

"The pending state is missing, so it got pressed twice. Two payments came through."

Reporting an incident caused by appearance 5 never being built.

"Change the label from 'Confirm' to 'Delete permanently.'"

A request to make the label alone carry what pressing will do.

This turned into a long conversation at Pagedeck once. The delete-document window had a confirming label that read "Confirm," and support was getting more than ten messages a month asking whether something pressed by accident could be brought back. Noa changed the label to "Delete permanently," raised its color to red, and kept cancel on the left but demoted it to an outline. The next month brought two messages.

Theo caught one more thing in the same window. Deleting takes 0.8 seconds for the server to answer, the control stayed unchanged the whole time, and impatient people pressed again — the second request tried to delete an already-deleted document and threw up an error screen. Locking on press and running a spinner ended it.

Most people read the difference between a link and a button as a difference in appearance. Both get clicked, and links are often styled to look like buttons, so it's an easy read. But what separates them is the job, not the look. Something that takes you elsewhere is a link; something that runs an action in place is a button. Break that and a screen reader announces "link" for what is actually a payment, and something that looked like it would open in a new tab does nothing at all.

Treating the disabled state as a kindness is the other common belief. It stops mistaken presses, so it looks considerate. But a dimmed control says nothing about why. Unchecked terms, an empty required field, no card on file — any of them could be the reason, and the person is left searching the screen. Leaving it pressable and saying what's blocking on press is usually faster.