Button design is the work of making an action obvious, reachable and safe to trigger: a clear shape and label, enough size to tap or click, and visible states that confirm what the interface is doing.
Buttons are among the most repeated elements in ui design principles, which is why small decisions about them have outsized effects on usability.
Making a button look like a button
The Nielsen Norman Group makes the central point in its guidance on recognizable clickable elements: users need to know which areas of the page are plain static content, and which areas are clickable (or tappable). Flat visual styles remove many of the cues that once made buttons obvious, such as bevels and shadows, so the remaining cues have to do the work.
Reliable cues include a filled or outlined container with clear contrast against its surroundings, generous padding around the label, a consistent corner radius, and a position where users expect actions to be. Text that merely looks like body copy asks users to guess. A button that has to be explained in a tooltip has not yet been designed.
Primary, secondary and tertiary emphasis
Most screens contain several actions, and not all of them are equally important. A common pattern uses a ladder of emphasis: a solid fill for the single most important action, an outline or tonal fill for supporting actions, and a plain text style for low-priority ones such as cancel or skip.
The discipline lies in restraint. When every button is a bright filled rectangle, none of them leads the eye. A screen with one clear primary action tells the user what to do next, and the secondary styles keep alternatives available without competing. Destructive actions deserve their own treatment, often a warning colour reserved for that purpose alone, and should rarely be the default focus in a confirmation dialog.
Button states and what each one must communicate
A button is not a single picture but a set of states, and each state answers a question the user has at that moment.
- Default: this can be used.
- Hover: the pointer is over it and it will respond. Touch screens have no hover, so it can never carry essential information.
- Focus: this is where the keyboard is now.
- Pressed or active: the interface registered the input.
- Loading: the action is in progress and should not be repeated.
- Disabled: the action is currently unavailable.
Focus is the state most often neglected. The W3C explains that its focus visible criterion exists so that users know which element has keyboard focus. Removing the default outline without providing a clear replacement leaves keyboard users unable to see where they are.
A mockup that shows only the default state hides most of the design problems. Documenting every state for each button type, on each background it can appear on, is routine practice in ui kit work for exactly this reason.
Disabled buttons need care
Greyed-out buttons are attractive because they prevent errors, but they carry a cost. MDN states that the HTML disabled attribute prevents the user from interacting with the button, so that it cannot be pressed or focused. A keyboard or screen reader user may therefore never discover the button, or learn why it is unavailable.
Low contrast is part of the same problem, since a disabled style is often too faint to read. Where possible, keep the button available and explain the problem when it is used, or place a short note beside the control stating what is still missing. A form that says which field needs attention is more helpful than one with a silent grey button.
Sizing buttons for fingers and pointers
Size has measurable guidance behind it. The W3C’s minimum target size criterion says the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with exceptions for spacing and some other cases. The stricter enhanced criterion, which is a higher conformance level, asks that targets be at least 44 by 44 CSS pixels, aimed at people who find small objects hard to tap.
These are floors, not goals. Primary buttons on touch screens usually benefit from being larger than the minimum, and spacing between neighbouring buttons matters as much as the size of each. Placing a destructive action right next to a common one invites accidents.
Button sizes also have to hold up across screen widths, which is where responsive web design comes in: a full-width button on a phone may become an auto-width button on a desktop layout without losing its tap area.
Writing clear button labels
The Nielsen Norman Group defines user-interface copy as labels for commands that appear in buttons, menu items and other action-oriented elements. Good labels are short, begin with a verb and say what will happen. “Save changes” or “Send message” tells users more than “Submit” or “OK”, especially in a dialog where the question above the button may have scrolled out of view.
Keep labels consistent across the product. If one screen says “Remove” and another says “Delete” for the same action, users start to wonder whether the two differ. Avoid labels that need the surrounding text to make sense, and keep the same wording for the same action in every context.
Icon-only buttons need extra care. MDN notes that buttons that only display an icon do not have an accessible name, and the fix is to put text in the button element that concisely describes its function. Even when sighted users understand the icon, assistive technology needs the text.
Placement completes the picture. Primary actions usually sit where the user’s attention ends, such as the bottom of a form or dialog, and the order of buttons should stay the same throughout a product so that muscle memory works. A pair of buttons whose positions swap from one screen to the next causes mistakes that no amount of styling can repair.
Finally, buttons should be tested in context rather than judged in isolation. A button that looks balanced on an empty artboard can look overwhelming next to a dense table or lost beside a long paragraph, so a mockup should place it in realistic surroundings with realistic labels before the design is signed off.
Frequently asked questions
Should a button be a link or a button element?
A control that performs an action on the current page, such as submitting a form or opening a dialog, should be a button element. A control that navigates to another address should be a link. Using the right element gives keyboard and screen reader behaviour for free.
How many primary buttons should a screen have?
Usually one. A single primary action makes the next step clear, and other actions can use secondary or text styles. Several equal-weight primary buttons compete for attention.
Do rounded buttons convert better than square ones?
Shape is mostly a matter of visual style and consistency. What affects use is contrast, size, label clarity and position, so the shape should follow the brand’s visual language rather than be treated as a performance lever.
Which states should a button mockup include?
At minimum default, hover, focus, pressed and disabled, plus a loading state wherever the action is not instant. Each should be shown on every background the button appears on.
