By default, use "Normal" button styling. "Primary", "Normal", and "Link" buttons use the configured accent color.

Don’t rely on the styling of buttons to convey their meaning. Use text labels that convey sufficient information to users who cannot see the button color.


"Primary" button styling draws attention to the most common action on an interface to speed up user interactions.

Assume that many users will be biased toward selecting the primary button; make sure to limit side effects of mistakes.


Don’t show more than one primary button on an interface.

Don’t use "Primary" styling for buttons that delete data or cancel the user’s current activity.


"Secondary" button styling is used for actions that need to be differentiated from form submission buttons or for less common actions on an interface.


Use "Secondary" style for inline buttons within the body of a form


Use "Secondary" style, instead of a primary color, for buttons alongside a destructive action


"Destructive" button styling highlights actions that result in loss of persisted data.


Don’t use the "Destructive" style for easily-reversible actions or the removal of information entered by the user while viewing the interface.

Don’t show both primary and destructive buttons in one interface. Include a maximum of either one primary button or one destructive button.

Use the "Link" style to de-emphasize less common actions. The "Link" style should be used sparingly.



Avoid having more than one "Link" style button in a group


By default, use "Standard" size.

Keep in mind that there is only one button size on mobile devices.


Don't use more than one size button for a group of buttons


Use "Small" button size with "Secondary" style to differentiate inline buttons, such as grid toolbars, from form submission buttons.

When using buttons in a columns layout or side-by-side layout, use “Small” button size to match the height of other interface components, such as a text box or dropdown.


Use "Large" button size to draw more attention to the main action on the page.


If possible, use a verb that best describes the button action (e.g. "Approve") instead of a generic label (e.g. "Submit").

For wizards, use a "Next" or "Continue" label to indicate that additional steps remain.


Icons can be used in buttons to draw attention. If a button contains an icon but no text, be sure to add a label via the accessibility text parameter for non-sighted users.


The form footer button group is only for buttons that submit an entire form or navigate away from the form (Cancel, Go Back, etc.).

Use inline button groups within the interface content for buttons that act on part of the content and do not take the user away from the interface (e.g. buttons as a toolbar for selected items in a grid).



The footer is reserved for buttons that control flow away from a form (such as submitting the form or returning to the previous step of a wizard)


Place all form submission buttons on the right side of the button group. The most commonly-used button should come first (left-most). This button should use the primary style (unless the action deletes persisted data, in which case it should use the destructive style).

Go back/cancel buttons should be placed on the left side of the button group (back button left-most).



Buttons that are temporarily unavailable due to the state of form data should generally be disabled, not hidden.

However, if the availability of a large number of buttons changes as users interact with the form, unavailable buttons should be hidden to reduce clutter and allow users to easily see valid options.


Use concise titles for related actions to prevent shortcut button label truncation. If additional text is needed to convey the purpose of the action, add descriptive text rather than lengthening the title.

Make only the most relevant related actions to a record view available as shortcuts, no more than 3 if possible.



Open in Github Built: Fri, Nov 12, 2021 (02:39:09 PM)

On This Page