Skip to main content

Button Design Rules: Hierarchy, Size, and States

By · · 5 min read

ui designuxcomponents
On this page

Buttons are the moment where a user's intent turns into action. They're also one of the most frequently designed elements in any product — which is exactly why small mistakes in button design get repeated hundreds of times.

These rules cover the decisions that matter most.

1. Establish a clear hierarchy#

Not all actions are equal, and buttons should show it. A typical hierarchy:

  • Primary — the main action on a screen. Filled with your accent color.
  • Secondary — alternative actions. Outlined or a subtle fill.
  • Tertiary — low-emphasis actions. Text-only or ghost style.
  • Destructive — actions that delete or cannot be undone. Typically red, used with care.

The goal is that users can identify the most important action within a second of looking at the screen.

2. One primary action per view#

If everything is primary, nothing is. Limit each screen, dialog, or section to one primary button. Supporting actions should use secondary or tertiary styles. This guides attention and reduces decision time.

3. Write labels that describe the action#

Button labels should say exactly what will happen:

  • Use verbs. "Save changes," "Send invoice," "Create account."
  • Be specific. "Delete project" is clearer than "Delete," and much clearer than "OK."
  • Keep them short. One to three words is ideal.
  • Use sentence case. It's easier to read than all caps or title case.

Avoid vague labels like "Submit," "Continue," or "Yes" in situations where the consequence matters. In a confirmation dialog, "Delete project" and "Keep project" are far clearer than "Yes" and "No."

4. Size for touch and click#

Buttons must be easy to hit:

  • Minimum touch target — 44 by 44 points on iOS, 48 by 48 dp on Android. The visual button can be smaller if the tappable area extends around it.
  • Consistent sizes — define small, medium, and large sizes, commonly 32, 40, and 48px high.
  • Generous horizontal padding — typically 16 to 24px, so labels don't feel cramped.

Fitts's law reminds us that larger, closer targets are faster to hit. Important actions deserve comfortable sizes.

5. Place buttons where people expect them#

Placement should follow conventions and the user's flow:

  • Forms — primary action at the end of the form, aligned with the fields.
  • Dialogs — actions at the bottom, with the primary action consistently positioned.
  • Mobile — key actions within thumb reach, often at the bottom of the screen.

Whatever convention you choose, apply it consistently across the product so users don't have to hunt.

6. Design every state#

Buttons need a complete set of states:

  • Default
  • Hover — for pointer devices.
  • Pressed — immediate feedback on click or tap.
  • Focused — a clearly visible focus ring for keyboard users.
  • Disabled — visibly inactive.
  • Loading — while an action is processing.

Missing states make interfaces feel unresponsive. The focus state, in particular, is essential for accessibility and often forgotten.

7. Be careful with disabled buttons#

Disabled buttons can frustrate users because they don't explain why an action is unavailable. Consider alternatives:

  • Keep the button enabled and show validation errors when clicked.
  • Explain what's needed near the button, for example "Fill in all required fields to continue."
  • If you do disable it, make the reason clear.

Also remember that disabled buttons still need enough contrast to be recognized as buttons.

8. Show loading clearly#

When an action takes time, show it. Replace the label with a spinner or show a spinner alongside the label, keep the button size stable so the layout doesn't jump, and prevent duplicate submissions while the action is processing. For long operations, give additional progress feedback.

9. Make buttons look like buttons#

Users should recognize buttons instantly. Consistent shape, fill or border, and padding make clickable elements obvious. Avoid styling non-interactive elements like buttons, and avoid styling buttons so subtly that they look like plain text unless they're intentionally tertiary.

10. Use icons to support, not replace#

Icons can make buttons faster to scan, but they shouldn't replace labels for important or ambiguous actions. If you use icon-only buttons — common in toolbars — provide tooltips and accessible labels, and use widely understood icons.

11. Separate destructive actions#

Destructive buttons should be visually distinct and physically separated from common actions to prevent accidental clicks. For irreversible actions, add a confirmation step that restates the consequence, or better, offer undo when possible.

12. Build buttons as a system#

Define buttons as a component with variants for hierarchy, size, and state, plus properties for icons and labels. Use the same component across the product and match it to the coded component. Consistency teaches users how to interact with your product without thinking.

Small element, big impact#

Buttons seem simple, but they carry much of the weight of an interface's usability. Clear hierarchy, honest labels, comfortable sizes, predictable placement, and complete states make the difference between an interface that guides people confidently and one that makes them hesitate.