Elastic UI

Button guidelines

This page documents patterns for button design, including types, placement, color, and size.

Button types

Filled buttons are for the primary action

This button has the heaviest visual weight to draw users' attention.

Standard buttons are for secondary actions

Such actions include Add and Apply. This button type works well for multiple actions of equal weight.

Empty buttons are for complementary, UI-specific actions

Close, cancel, filter, refresh, and other actions that reconfigure the UI are appropriate for empty buttons.

Icon buttons are for saving space

The icon must be immediately understood, for example, a trash can for delete. Use these buttons sparingly, and never for the primary action.

Placement and order

Button placement and order should follow the user path.

Put buttons on the right in containers with a restricted width

In contained spaces like modals, popovers, bottom bars, and flyouts, the user path is top to bottom, left to right, in a Z-shaped pattern. Placing buttons on the bottom right puts them right where users finish scanning.

button placement in an input modal — Do. In modals, the primary action is on the bottom right with the secondary action on its left.

button placement in confirmation modal — Do. Popovers should always use buttons positioned to the right.

Put buttons on the left in unrestricted containers

With large page forms, content is typically concentrated on the top and left with a lot of open space to the right. The user path is top to bottom, in an F-shaped pattern.

button placement in form — Do. Because the user's eye never leaves the left side, the buttons are on the bottom left. The primary action is in the leftmost position.

form buttons go on the left, not right — Don't put the actions far away from the content.

Other patterns

Button should always fit the surrounding context and stay consistent with the app.

button placement in upper right — Do. If the action is against the page title, place the primary button in the upper right. A common pattern is a create button that adds an item to a list. Creation starts at the top and ends at the bottom. Think of it as adding to a pile.

center-aligned button — Do. Empty states are unique because they focus first on information and then try to sell the user on creation. In these special cases, where the container is constrained and the content is fairly short, the title and the button should be center aligned.

One primary button per layout

The primary action should not have to compete for attention. Use only one filled button per page, modal, form, or other layout.

one primary button per page — Do. Use only one filled button per layout. The primary action is the one you want the user to eventually complete.

page without primary button — Don't. Using too many primary buttons confuses the user.

Icons in buttons either stand on their own or add context

Icon buttons can save space. Limit icon buttons to groups of two—otherwise they lose meaning.

Do. Use icon buttons for universal actions that are easy to understand.

Don't use icons alone in a standard button. It defeats the purpose of saving space.

Icons can serve as a scanning aid in a text label, but keep to a minimum. Icons work best on labels for binary actions, for example, Create and Delete, and final actions, such as Save.

Do. Use icons to emphasize actions. The arrow on the Continue button lets users know they still have items to fill out. Using the word "Complete" with a rare check icon helps users understand that this is the final action.

Don't. Icons often distract from the text. This is especially true when the icon is positioned on the right, with a hard to grok icon.

Minimize the mixing of color, size, and type

When in doubt, use a blue button in the default size. Never put more than two visual styles next to each other.

Do. Stick to the default pattern: a filled, blue primary button paired with an empty, but same-colored button.

Don't. Readability suffers when multiple colors and sizes are used.

Stack action sets into one button

Two buttons are optimal for a side-by-side layout, three is rare. For more buttons, use a dropdown or context menu.

Do. This example puts multiple actions in one button rather than showing them separately.

Don't. When you have too many buttons, none matter.

Labels that say what the button does

Labels should provide a clear indication of that action that occurs when the user clicks the button. Prefer action words, and include an object when it is not clear from the context, for example, Add dashboard. Labels should be three words or fewer. If your label requires more words, consider using a text link instead.

Preferred words in buttons

Text	Description
	Establishes a new relationship. Often used in a create-then-add scenario. You create a dashboard, then add a visualization. Always followed by an object. Do not use "Add new." Remove is the correct opposite.
	Stops an action without saving pending changes. Never make Cancel red—it's not a destructive action. Cancel is always an empty button.
	Creates a new object from scratch. Always followed by an object, for example, “Create pipeline.” Do not use "Create new." Exception: “Add user” is more intuitive than “Create user.” Delete is the correct opposite.
	Deletes data so users can longer retrieve it. Create is the correct opposite. Do not confuse with Remove.
	Removes a relationship, but doesn't permanently delete data. For example, you remove a visualization from a dashboard. Add is the correct opposite.
	Carries out pending changes, for example, Save edits. Do not confuse with Add. Can use green if this button is the final save action.

Avoid these words in buttons

Text	Use this instead
	Remove or Delete
	Add or Create
	Words that explain the action
	Words that explain the action