Make the most important button look like it’s the most important one.
Put buttons in a sensible order.
Label buttons with what they do.
If users don’t want to do something, don’t have a button for it.
Make it harder to find destructive buttons.
Nothing particularly revolutionary there, right? Ever since the <button> tag arrived in HTML4, buttons haven’t been especially difficult to create. Despite this, it’s rather easy to find buttons that don’t comply with these basic best practices, so I’m going to dig into them a little deeper in this column.
Champion Advertisement
Continue Reading…
1. Make buttons look like buttons.
The main point with buttons is that they need to look buttony—with a bit of shading on their surface or around their edges to make them stand out from the background and look clickable, as in Figure 1.
Figure 1—Buttons that look like buttons
A shape around a word without any shading isn’t enough to make it clearly look buttony, and a simple word on its own definitely doesn’t provide enough visual cues, as in Figure 2.
Figure 2— Buttons missing some of the visual cues they need
If you make a button too big, it may no longer look buttony. Figure 3 shows a section from the UK Web site for registering to be an organ donor. It has four buttons—one main action and three subsidiary actions—but the primary action button is so large that it no longer looks like a button.
Figure 3—A primary action button so large that it doesn’t look like a button
The solution for a button that is too big? Make it smaller. Figure 4 also has four buttons, but it’s now a lot easier to see which one is the primary action.
Figure 4—A primary action button that is smaller, but more obvious
Although it seems obvious to me that buttons need to look like buttons, many Web site designers appear to worry that a messy old button would spoil the lovely lines of their design. And, of course, they may be right: we want that primary action button to look great, as well as to look like a button. It’s the one single most important place for your users to look, so it needs to be a visual pleasure. Just make sure it’s a buttony pleasure.
2. Put buttons where users can find them.
One of the most hotly debated questions in user experience is: “Does the OK button go to the left or the right of the Cancel button?” And there are equally impassioned debates about other combinations of buttons—for example, the vexing question of Next and Previous buttons in survey research. You can find opinions everywhere—and they’re often backed up by references to various style guides, articles, and even actual research.
My experience is that I have never designed a dialog box or form that consisted solely of the two buttons OK and Cancel. Nor have I seen a survey page that consisted solely of the two buttons Next and Previous. I can’t remember ever seeing one, and my library of screenshots doesn’t include any. Why? Because there’s always something else: some text, an image, or of course, one or more questions.
What were users looking at immediately before they started to hunt for that crucial primary action button? What made them choose Cancel or Back?
Generally, on a Web page, it’s all about knowing what catches your users’ attention and inspires them to action. You have to decide on the text or image that inspires the call to action and put the corresponding button right there.
In the world of forms and surveys, users have just tabbed to or clicked a field—so put the primary action button, Next or OK or Send, as close as possible to the left-hand end of the last field on the form.
Figure 5—My presentation “Buttons on Forms and Surveys”
Why, then, do I see buttons that are hidden in all sorts of strange places? For example, in Figure 6, the Next button is hidden in a footer. There’s one hiding in the page’s banner as well, above the logo.
Figure 6—A black Next button hidden in a footer
3. Make the most important button look like it’s the most important one.
Another common way of making it difficult for users to play hunt-for-the-button-I-want is to offer them lots of buttons in a neat row, all of them looking very similar.
Figure 7—A tidy row of buttons that makes it harder to pick out the primary action button
Why not give users a bit of help and make the primary action button more prominent? Making it a bit bigger makes it look more important. It also creates a larger target for users to click. Or try the more conventional approach: use a brighter color for the primary action button—just don’t be too subtle. We’re aiming for obvious.
Figure 8—Making the primary action button easier to find by making it larger
4. Put buttons in a sensible order.
If the primary action button needs to be where users look next, where should the other buttons go?
Clearly, you should tuck the other buttons away somewhere users won’t stumble upon them too easily. This is fine advice, but if you follow it without taking other design considerations into account, it could lead to improper layouts like the one in Figure 9.
Figure 9— A survey page with the Previous button on the right
For languages that read left to right, a Previous button should always be to the left of a Next button, so the answer here is to rearrange the fields and buttons, possibly as in Figure 10. Another option would be to increase the left margin of the page and put the Previous button into it.
Figure 10—Rearranging the survey page, putting Previous on the left
5. Label buttons with what they do.
The other day, I was anxiously trying to upload a presentation to a Dropbox account. Up popped the message shown in Figure 11. It offered me a single button labeled Awesome! What was that supposed to mean? What did the button do? How could I fulfill my goal of getting that presentation to where it needed to be?
Figure 11—A confirmation message box with the single button Awesome!
This illustrates a violation of the best practice: Label buttons with what they do.
Most of us have experienced wholly unwelcome message boxes that tell us about some drastic and horrible error—and expect us to click OK. It’s not OK, and I don’t want to click OK after receiving such bad news.
We certainly can’t guarantee that users will read the labels on buttons. In my presentation, I referred to three studies that showed, if you put the wrong button in the line of fire, some users won’t read the button’s label and will click the button. But the two survey studies also showed that some users do read those labels, so help them by writing button labels that clearly explain what each button does.
And if you find yourself in one of those arguments about what exactly the action of, say, Cancel should be on a dialog box—remember that you ought to be labeling the button with what it does, not trying to build an action that corresponds with the label that a button happens to have.
Figure 12—Button labels that clearly explain what the buttons do
6. If users don’t want to do something, don’t have a button for it.
I constantly browse for forms to use as examples. To find out whether they work well, I fill them in as honestly as I can, but I don’t really want to register for a site or apply for a loan or do whatever else the purpose of a form might be, so I find a Reset or Cancel button rather convenient. I once wrote an article titled “Reset: The Piece of HTML Invented Just for Me, in which I said, “If you’re designing for consultants who specialize in forms design, make sure you include that Reset button. If you’re designing for anyone else, ask yourself whether they really will want to throw away all their work.”
Writing this, I just realized that it’s been a long time since I’ve seen a Reset button on a form—in fact, I haven’t seen one this year—and even Cancel buttons are becoming rarer. I capture screenshots of nearly every form and survey I see, and my 2012 example library, so far, has not got a single Reset button and only about 10% of forms have a Cancel button—and about half of those were forms for which it seemed plausible to me that a user might actually want to cancel.
I continue to see a lot of buttons that simply repeat the same action, so users get the feeling that they aren’t making any progress. For example, I recently started to apply for a credit card. Figure 13 shows the primary action buttons from the first three steps—none of which offered me a form, so I was feeling impatient before I had even answered a single question and quickly abandoned that process.
Figure 13—The first three buttons in an application process—no progress here
Lest you think this problem is a bit trivial, remember the “$300 million button.” Part-way into a process, users encountered a form with a choice of buttons: Log In or Register.
But users either didn’t remember their log-in credentials or didn’t want to register, so both choices were things that they didn’t want to do. Changing Register to Continue, something they did want to do, achieved a dramatic increase in sales.
7. Make it harder to find destructive buttons.
Despite my arguments against buttons for things that users don’t want to do, we sometimes do need to offer destructive buttons such as Cancel This Order. This was one of the plausible Cancel buttons that I found in my library, from a Web site that is aimed at non-savvy users who were about to commit to a rather large purchase, with long-term monthly payments, and who might not realize that the Close the Window option would let them escape.
If you do need to include destructive buttons, you should definitely find a way to make them harder to find than the primary action button—for example, by making them look less buttony, smaller, or even turning them into links. Users who want to cancel—or perform some similarly destructive action—will break off and go hunting for them. But users who are happily proceeding with their tasks don’t get snagged into a horrible error.
Figure 14—Are these destructive actions sufficiently well hidden from users?
Buttons Have a Role in the Conversation
In our book Forms That Work: Designing Web Forms for Usability, Gerry Gaffney and I talk about forms as having three layers: relationship, conversation, and appearance. In her book Letting Go of the Words: Web Content That Works, Ginny Redish recommends that we “Think of the Web as a conversation started by a busy user.”
The humble button plays a crucial role in these conversations. When users first navigate to a page that contains a form, an appropriately easy-to-spot primary action button helps to show the extent of their task—a short form with a button that’s immediately visible is good; a long form with no button above the fold might not be so good. Of course, this depends on the relationship—that is, on the combination of the user’s goals and the assessment of the organization asking the questions.
Clicking a button signals the end of my turn, a crucial element in any successful conversation. A smooth handover keeps the conversation flowing along; glitches such as an unsatisfactory game of hunt-the-button serve, at best, as interruptions and, at worst, as breakdowns.
From the conversational point of view, does it matter whether the primary action button’s label is Submit? Possibly. Both Send and Submit label the button with what it does—but only if you are a tech-savvy person with a clear concept of data being whizzed off to a processor that will deal with it. For others, either label simply signals the button to click to move things along—just as the Esc button on a keyboard sometimes helps you to jump out of what you’re doing. From these neutral viewpoints, the two labels are equivalent. But there is a minority who have read and thought about these terms, for whom Submit seems to create an unpleasant tone within the conversation, to the point where some especially sensitive people may break off entirely. Hence the possibly.
Summary: the Basics About Buttons
Buttons are hardly newfangled or glamorous; they’re just an ordinary, every-day element of interaction design. Despite this, because buttons are a vital element in creating a smooth conversational flow in Web, form, and survey experiences, it’s worth paying attention to these basic best practices for buttons:
Make buttons look like buttons.
Put buttons where users can find them.
Make the most important button look like it’s the most important one.
Put buttons in a sensible order.
Label buttons with what they do.
If users don’t want to do something, don’t have a button for it.
I’d like to suggest a corollary to best practice #1: Don’t make things that are not buttons look like buttons.
Making things that should probably be text links look like buttons seems to be a common interface design strategy. To make matters worse, these non-button buttons often crop up multiple times on a single page, making it even more difficult to suss out where the real button is.
Thanks for putting together such a useful list with great examples!
Great stuff, Caroline. I’d suggest a corollary to number 1: Don’t make something look like a button if it isn’t a button. For example, I recently saw a site where the navigation link for the current page was highlighted to look like a button, but, of course, clicking it had no effect.
8. Make sure your application handles double-clicks appropriately.
A recent article from Baymard Institute reports that some users still persist in double-clicking buttons. There aren’t that many of them, but they are some of the most nervous users of the Web. Assume that you will get this behavior, and make sure that you design for it.
How about a Submit button? What is the best practice for a Submit button on a form? Should the best practice be that once it is clicked, the button gets disabled so multiple forms are not submitted? Should a pop-up also appear to let the user know the form is in process?
I don’t agree with make your destructive buttons hard to find. Why should a user go searching? If it is destructive, confirm the destructive action. Nothing is worse than looking for the little Delete or Remove button to remove an item from a shopping cart.
Do you have any recommendations about button sizes—like using min-width and max-width? Especially when thinking about translating button labels, should the button-size grow and up to what size?
I think this is a good checklist. I immediately think of Google and their past UX initiative to flatten all components, so buttons became simple colored squares, no borders, no drop shadows. They often were confused with message boxes rather than buttons; seriously, make a button look like a button, duh. They also decided that red was a great primary button color—huh? Well, it’s a great color if you run a small Web ad with a quick blurb and a Buy Now button, so their AdWords genius team probably were instrumental in making Gmail’s Send a red button. Funny that the new, “revolutionary” UX initiative from Google is now Polymer, with paper tabs and buttons that now feature drop shadows—and don’t show any red action buttons—finally admitting years of stubborn refusal to acknowledge the bad design strategy.
when to use a form input button and when to use an a href link
So long as the user accepts CSS stylesheets and doesn’t have a local override, links can be made to look like buttons, and buttons can be made to look like links.
I’ve seen lots of cases where, because the wireframe / design looked button like, front-end coders made it a form input button—often with unintended consequences. And vice versa.
Separating out the presentation (CSS) of a button or link from the HTML / HTTP semantics feels like a piece of design that goes missing.
Usually form input buttons are used to post data to the Web site and somehow change its state. And links are used to get a different resource and not change the application state. Using the wrong one can cause all sorts of problems.
If you want the resource at the other side of the “button” to be crawlable by search engines and other bots, a form input button usually won’t get you that. Google bots don’t know how to fill forms. I’d argue that quite a few of the examples in the post—Sign Up Now, Apply Now—should be a href links—maybe decorated as buttons—because going to them doesn’t change the state of the application and you want them to be crawl able.
For actions that do change the state of the system—and definitely if those actions are destructive—you want to use a form input button, so non-human user agents don’t change system state or destroy data. Even if the page is behind a login or on a intranet, there might be agents like Google Accelerator running that follow all links and cache the pages to improve performance and might inadvertently destroy data.
How and where to display buttons is covered very well by your post, but separating document (HTML) and HTTP semantics from display feels like a necessary step.
And I’m no expert on screen readers, but I’d assume that getting the document design of when to use buttons and when to use links would have implications for accessibility.
Completely agree. This is the one point I don’t agree with: Add an “Are you sure?” pop-up message with buttons to continue or cancel, which is simple and quick to accomplish and protects users who may have accidentally pressed Cancel. It bums me out every single time I have to hunt for a Cancel button, and it makes me think significantly less well of the business that chose to implement things this way on their Web site.
Caroline became interested in forms when delivering OCR (Optical Character Recognition) systems to the UK Inland Revenue. The systems didn’t work very well, and it turned out that problems arose because people made mistakes when filling in forms. Since then, she’s developed a fascination with the challenge of making forms easy to fill in—a fascination that shows no signs of wearing off over 15 years later. These days, forms are usually part of information-rich Web sites, so Caroline now spends much of her time helping clients with content strategy on huge Web sites. Caroline is coauthor, with Gerry Gaffney, of Forms that Work: Designing Web Forms for Usability, the companion volume to Ginny Redish’s hugely popular book Letting Go of the Words: Writing Web Content That Works. Read More
