Button

Buttons trigger actions within an interface, typically involving data transformation or manipulation. They provide clear visual indicators of the primary actions users can perform on a page or section.

Type Component

Tier Global

Documentation Status Minimal

Last Edited 06.03.2026

Open in Figma View on GitHub

Usage

Use buttons for meaningful interactions that transform, submit, or manipulate data, such as:

• Submitting forms
• Deleting items
• Processing payments
• Updating settings.

Actions represent state changes in the application rather than simple navigation.

Buttons help establish clear visual hierarchy by signaling the most important actions available to users at any given moment. This hierarchy is critical to effective interface design. Users should immediately understand what action they're expected to take.

While buttons should primarily trigger actions, they can occasionally be used for navigation when the context demands it. This is most appropriate for high-priority conversion points, such as call-to-action buttons in hero sections that direct users to, for example, sign-up flows or landing pages. In these cases, the button represents a key user journey rather than standard navigation.

When to use

• For actions that transform, submit, or manipulate data
• To draw attention to the most important action on a page or section
• For high-priority conversion points or key user journeys
• When the interaction represents a meaningful state change in the application

When not to use

• For simple navigation between pages (use Link instead)
• When you already have a primary button visible in the current viewport (consider using secondary or tertiary button styles instead)
• For multiple competing actions of equal importance (reconsider your information architecture and prioritize one clear primary action)

Call to actions

Almost always, there is an action that the user needs to perform on a page. Guide users toward the main action within the user flow that you have designed. This means being opinionated about what action the user should be performing and using that as the primary call to action. Rather than presenting users with an overwhelming array of choices, you should clearly signal the intended path forward. As a result, the main action on any given page should, in most cases, be represented by a primary button.

Be deliberate about the number of calls-to-action you present. Each additional CTA dilutes the user's focus and makes it harder for them to decide what to do. Ideally, limit pages to as few CTAs as possible so users clearly understand their intended path forward. As a rule of thumb, there should almost never be more than one primary button visible in the user's viewport at a time.

When multiple primary buttons compete for attention simultaneously, the hierarchy collapses and users face decision paralysis. If you find yourself needing multiple primary actions in view, reconsider whether they're all truly primary and whether some could be deprioritized or removed entirely.

Button order and alignment

Right-aligned buttons when:

• The action moves the user forward in a flow (forms, wizards, checkout)
• In modal dialogs and confirmation windows
• Settings or configuration panels
• The button completes or submits something
• Following the natural "end of task" position after scanning content left-to-right

Left-aligned buttons when:

• The button is a direct continuation of left-aligned content (Hero, cards, marketing blocks)
• The action relates to specific content above it
• "Back" or "Cancel" actions that return users to a previous state
• Article pages or content-heavy contexts where buttons are secondary to the text

Icon buttons

In situations where space is limited and the actions have easily recognizable icons, buttons may use an icon without Text. These should be reserved for very common actions such as delete, edit, or close. Icon-only buttons must always include a Tooltip that clearly states the action the button performs. The Tooltip should include a delay so that it does not interrupt the user unnecessarily.

When to disable buttons

For form submissions, buttons should remain enabled even when mandatory fields are incomplete. Users often don't understand why a button is disabled, particularly in longer or more complex forms where they may have overlooked a required field. Allowing users to click the button and receive validation feedback makes it easier for them to discover and correct their mistakes.

Disabling is more appropriate when the system knows an action is genuinely unavailable, not due to incomplete input, but due to external constraints like permissions, plan limits, or missing prerequisites. In these cases, clearly communicate why the action is unavailable with a Tooltip.

If possible, provide an alternative that unblocks the user. For example, if an empty state requires a prerequisite to be fulfilled first, display the action to complete that prerequisite rather than showing a disabled button with no clear path forward.

Dual buttons

There are situations where opposing actions can be combined into a single button, for example play and pause in a video player. The icon or label should reflect the action that will occur when the user presses the button. If the media is playing, show the pause icon. If it is paused, show the play icon. This aligns with user intent because they select an action, not a status.