Toggle navigation

Button Guidelines

Buttons are an input that allows users to trigger an action. Along with links, they are the building blocks of any interface.

Applies to:
Button Bar
Multiline Button
Pointy Button
Floating Action Bar

When designing a button or adding it to an interface, it must be apparent what action it will trigger to avoid any mistakes or confusion. There are a few ways you can do this: The first is consistently styling your buttons to indicate what they mean. The second is making sure your labels are descriptive. And the third is placing them on a specific area of the page so that users know what they mean.


In this section, we will look at the hierarchy of buttons and what they communicate. Button actions are not determined by how they look (although they have a visual language) but rather by the event they trigger.

Call to action button

A call to action (CTA) button, depending on the situation, will usually encourage users to do something, e.g., "Sign up", "Go premium", "Join our mailing list", etc.

CTA buttons tend to trigger events that benefit the company or product and are less about helping a user complete a journey. Usually, these buttons are big and eye-catching. You will probably only use these on the marketing or sales side of the platform and not when the user is logged in.

Primary action button

Primary buttons are used to indicate to users how they can finish their current journey. Examples of primary button text labels are “Next”, “Save”, “Publish”, and “Start”.

Secondary action button

Secondary buttons are the alternative option to the primary button. They will usually be paired with and next to the primary button to make the user feel like they always have an out if they don’t want to complete a journey. Examples are: “Back” paired with “Next”, “Edit” with “Publish,” or “View cart” and “Buy now”.

Tertiary action button

Tertiary buttons are usually used for miscellaneous actions, meaning that the action is important but may not be what the user is looking to do right then. This would be things like “Add friend”, “Add new”, “Edit”, or “Download” (provided they aren’t part of the current user journey). You will usually position this button out of the way of the more critical primary action button.

Destructive primary action buttons

While these are technically primary buttons, they are slightly different because they trigger destructive actions. “Trash”, “Delete”, and “Exit” are all examples of destructive actions.

To protect the user from doing something by mistake, you must make it very clear to them what the button will do. While you can make this clear in the rest of the interface using symbols and warning text, you also want to clarify it in the button itself. Your button’s text label should be obvious and unambiguous. You should also consider making the button background red to hit home the nature of the event it triggers.


Button states let the user know what is happening. The state is a simple way of letting the user know that a button is clickable or if it is being or has been clicked.

Normal state

The normal state is when a button is active. This is how it will look to users most of the time.

Focus state

The focus state occurs when you hover over a button or tab to it using the keyboard. This little bit of interactive feedback lets the user know that the button is clickable.

Selected state

The selected state shows the user that they have clicked the button. This state is critical for older, slower systems that don’t respond as quickly.

Disabled state

If a user hasn’t completed a form or an event currently isn’t available, the button will appear greyed out, letting the user know that they can’t click it. For example, if a user hasn’t entered their dress size, they shouldn’t be able to buy it, so the button will be disabled.


The trick to button labeling is consistency. At the beginning of a project, decide on a couple of button labeling rules; this will save you a lot of pain later on. Consider having the following 3 rules:

  1. Choose the amount of words per button label.
  2. Choose the label’s case.
  3. Choose the label’s structure.

1. Amount of words

When labeling buttons, there is a thin line between being descriptive and making your buttons too long. Ideally, all buttons would be one word, but for new users or more complex platforms, that just isn’t possible.

You also want to keep your primary and secondary buttons similar lengths so that the buttons look good together.

2. Case

You should also decide on what case to use. Your options are:

  1. All caps, e.g., “PUBLISH POST”
  2. Title case, e.g., “Publish Post”
  3. Sentence case, e.g., “Publish post” (Note: no period at the end)
  4. Lower case, e.g., “publish post”

3. Label structure

Most buttons contain verbs to indicate what the button will do, e.g., “Save”, “Publish”, or “Edit”. While “Back” and “Next” aren’t verbs, they seem to work in the same way in the context of an interface.

When labeling buttons, you want to be as descriptive of what the action will do as possible.

Grouping buttons

When grouping buttons, there are a few rules you should keep in mind.

Group by purpose

Buttons should be grouped by purpose; adding non-related buttons creates confusion. Usually, you group primary and secondary buttons together and place tertiary buttons in a different part of the screen.

Separate touch targets

Make sure your buttons are far enough apart, so your user doesn’t click on the wrong one by mistake. Eight pixels is the usual standard gap between 2 buttons.

Keep consistent width

Buttons grouped together should be the same width. Having different widths makes one button seem more important than another, which may not be the case, as in the example below.

Left to right

To state the obvious: in the majority of countries users read from left to right. Consequently, this is the direction in which they will read your buttons. If you place your primary button on the far right, users reading through the button labels will end on the option you'd like them to select.

Best practices

There are a few best practices when it comes to buttons. Deciding on where to place them is almost as crucial as styling them.

Buttons should be grouped with related components so that the user knows that they're clicking on the right thing. Where a button is placed will usually be indicative of its action.

Create button hierarchy

The more complex a system is, the more buttons and links you will need per screen. Unfortunately, the more buttons there are, the easier it is for the user to become confused when looking where to go next. So, make the user’s job easier by clearly indicating the primary action and making everything else secondary or tertiary (or, better yet, a link).

Buttons should be where you would expect to find them

This goes without saying: in UX design, you want to make the user’s journey as easy as possible. You don’t want them to hunt around the screen trying to find a button. The best way to determine where to place buttons is to see how similar platforms do it. For example, most online retail sites have the product image on the left and the buttons on the right.


There are many different variations of buttons. Using more specific styles will indicate to the user what will happen when they click on them.

Controls included in Balsamiq

Balsamiq offers a wide range of pre-made button controls. Use the ‘Quick add’ tool to find the one you need, then drop it directly into your wireframe.

Pointy buttons: Pointy buttons, because of their shape, indicate to the user that they will go forwards or backwards though different pages. You can add or remove the border and change the direction of the arrows from the control panel.

Button bar: A button bar is a group of buttons. You can select which one is active from the control panel.

Multiline button: The multiline button is a big button that gives the user a longer description of what will happen when they click it.

Circle button: Circle buttons, also known as Floating Action Buttons (FAB), usually float in the bottom right-hand corner of the screen, meaning that it is always accessible for users.

By Tess Gadd
Got questions or feedback? Email