Buttons

Links go places. Buttons do things. ~anonymous

Buttons are components that allow users to navigate between states or actions. They're different than links, because links move users from location to location within or outside the system.

When to use

• Whenever triggering an event or action. Examples:
  • Refreshing a page.
  • Saving or cancelling an order form
  • Moving elements up or down on a list.
  • Launching an in-page dialog.
• When navigating within a container such as a wizard or a paginated table. Essentially, if it looks like you're AJAXING the data in and the framework and context are staying the same, it's OK to use buttons.

When not to use

• When the user is navigating to another location. We have links for that, and they've got better accessibility built in for it.
• In place of other form fields such as toggles or radio buttons. They're difficult to code to behave accessibly, look dated (hello 2005!), and are more difficult to understand.
• Just to draw attention to a call to action on the page. There are lots of ways to get a user to a CTA and a big red button isn't always the answer.
• In place of a tabset. Don't use buttons instead of tabs - we invented tabs for that.

Best Practices

1. Make buttons look like buttons: affordances of shape and color.
   1. Rectangles or rectangles with rounded corners are the usual style. Some research suggests that rounded corners enhance information processing and draw eyes to the center of the element. Circular buttons, triangles, custom shapes, can all be troublesome.
   2. Raised buttons (shadow underneath) indicates the button can be clicked. They add dimension to mostly-flat layouts.
   3. Flat buttons that fill with color on press minimize distraction from content.
   4. Ghost buttons (border is different but fill matches the background) are good for secondary or tertiary content
2. Think carefully about target size and padding. Larger buttons are easier to use.
   1. Per Luke Wroblewski, visual distinctions are key for separating primary and secondary tasks. The difference between the buttons can slow users down slightly, but the users indicated that they liked it because it helped them be sure they were clicking the correct button. (In these examples, Submit was to the left and Cancel to the right.)
      1. It's worth noting that UX Movement advocates for OK buttons on the right in dialog boxes because the user will look over the secondary action and then end on the primary action to finish the task... essentially the argument that the last thing you look at should be the last thing you do. It's notable that this is a good heuristic analysis but there's no testing cases cited to back it up.
3. Mind the order and position of buttons, especially pairs like "previous" and "next".
   1. Per the Nielsen/Norman group it doesn't matter whether the positive is to the left or the right as long as the app is consistent. The default and emphasis matter more.
   2. Per Measuring UX, if the buttons are far apart as in a wizard, the expectation is for the cancel to be on the left. Otherwise it doesn't matter.
   3. Per Luke Wroblewski, putting the submit button on the far right caused more errors in a usability test than having the submit button on the right. Grouping the buttons together, whichever order they're in, yields fewer mistakes. However, grouping the buttons on the left side with the Submit button on the leftmost edge, was most successful.
   4. Buttons on the web, placement and order by Artem Syzonenko runs down all the options and their pros and cons, with lots of examples and screenshots.
4. Ensure that design puts emphasis on the primary or most important action.
5. Label buttons with what they do.
6. Be consistent.
7. Don't disable a button unless you absolutely have to; it's better to remove a button the user will never use (due to security, etc.) than to expose the button and make it unclickable. Disabled buttons suck.

Accessibility

• Building accessible buttons with ARIA: A11y Support Series by Dequeue describes what needs to be added to non-buttony buttons to to make them accessible.

Additional resources

• Color You Responsible - an A List Apart article on button colors
• An Ultimate Guide to Pseudo-Classes and Pseudo-Elements by Smashing Magazine
• "Primary Buttons" in Adam Silver's Improving UX for Color Blind Users article on Smashing Magazine covers how to draw more attention to buttons through more than just color.
• "Button UX Design: Best Practices, Types, and States" by Nick Babich on UX Planet.
• "OK-Key" and "Cancel-Key", which one should be set up on the left? by Chloe at Mockplus reviews many of the thoughts behind the order of buttons in a button bar. It does not take accessibility into account but does cover a more, we'll call it "historical" view of the thinking around these two buttons.
• Multi-Function Button by Adrian Roselli covers cases where you want the button to reflect the state of something by changing the button name, and how to do so accessibly.