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:
  • When navigating in a paginated set of data. We could use links to do this (arguably the user’s going to a new set of data) but because we AJAX the data into the page, to the user it looks more like an action than a transition to another place.

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. Ensure that design puts emphasis on the primary or most important action.
  5. Label buttons with what they do.
  6. Be consistent.

Additional resources