Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

What are the differences between buttons and links?

share|improve this question
2  
what do you mean? –  Adrian Jul 26 '10 at 9:03

12 Answers 12

Rule of thumb: a link takes you to other place, a button does something.

That said, things can be flexible in this regard. Links are sometimes seen as low priority buttons, and buttons, almost always take you to other place.

[edit 2013] Things have changed a bit since I wrote this answer. I now use big buttons as clear "call to action" and try to avoid using more than two of them on any screen. Then I use smallish, tag-like buttons or links as low priority options.

The different meaning of buttons and links is not in their nature, but in its visual weight and its place in the hierarchy of the screen/design.

share|improve this answer
3  
Two years ago, I would have agreed with this answer, but the convention has changed. Things styled as links now routinely act as buttons. –  Alex Feinman Jan 4 '13 at 13:38
1  
I would say a button does something, rather than make something. But otherwise, yeah. –  Bryan Oakley Jan 6 '13 at 20:44
    
I try to follow this rule mostly. However, these days to most people, both are simply "things I can click on that make something happen" and that's fine too. The distinction is pretty conceptual anyway, I don't believe many people actually have expectations more precise than that. –  Koen Lageveen Aug 21 '13 at 9:34
    
This answer was written 3 years ago. I agree that today expectations have changed. I am editing the answer to reflect it. –  luna1999 Aug 21 '13 at 9:45
    
Can you show some examples of big buttons vs. smallish, tag-like buttons vs. links? –  Homer Aug 21 '13 at 14:16

In general, users expect links to link and command buttons to command. That is, links navigate, presenting new content without changing the underlying data objects or their relations or positions. Buttons change these things, performing creation, deletion, association, conversion, duplication, etc. An easy rule-of-thumb is if the most terse caption for the control is a noun (e.g., Home, Products, Site Map), then use a link. If the caption is a verb (e.g., Update, Submit, Delete, Purchase), then use a button.

However, in thick-client desktop apps, buttons may navigate, especially in older apps that originated before the web (and links) was commonly used. Furthermore, more recently links have been used in place of command buttons in various web sites and even some style guides endorse this. In fact, links have been used in place of just about every other control (e.g., radio buttons, tabs, checkboxes).

I believe all this confuses users and we really should use distinct-looking controls for distinct functions. Both web apps and desktop apps should clearly distinguish between navigation and commands by using link and buttons respectively. Navigating is significantly distinct than commands because:

  • Users don’t have to save after navigating. Saving is frequently necessary after a command.

  • Users easily revert navigation by clicking Back or closing the window. It’s always a “safe” action. Commands frequently cannot be reverted in a web app. If commands can be reverted, it’s through an Undo feature, which involves a different user response than Back or Close.

  • Commands provide different feedback that is often more subtle than navigation. It’s generally apparent when the user is presented with new content. Commands may show the change in the content, but often no change is apparent (e.g., for Copy or Save). Web apps often resort to confirmation pages (which doesn’t count as navigation in my book).

For these reasons, it helps the user to have distinct controls for navigation and commands, and fortunately user expectations for buttons and links make this easy. However, continued use of links for commands (and buttons for navigation) undermine these expectations, and soon we’ll lose this opportunity.

Graphically distinguishing navigation and commands afford us powerful ways to communicate with our users. For example if Contact Us is a link, then it displays a list of addresses and phone numbers (I’d label it “Contact Us” rather than the more terse “Contacts” since “Contact Us” is such a common convention, users scan for it specifically in menus). In contrast, if Contact Us is a button, then it takes users to a form where they can directly submit questions or comments (the button caption should have an ellipsis to indicate more information is required for the command).

I agree there is a need for light-weight controls for secondary actions, especially for typical web apps that lack an object-selection-action interface. However, the solution is to develop lightweight version of the appropriate controls, not recruit another control with a totally different user expectations. Such lightweight controls may technically be links, but they should look like the control they’re imitating. For example, a lightweight “button” can be a linked image of a small shaded rectangle with a center-aligned caption.

There is a gray area in navigation/command distinction which we should sort out. I recommend the following until the appropriate research can be conducted:

Use links for:

  • Loading a page of content

  • Loading dynamically generated content.

  • Loading content to part of a page if no other option is tenable (e.g., a tab).

  • Navigating between pages of a wizard (in contrast to traditional desktop wizards that use buttons).

Use command buttons for:

  • Actions that change or apply the underlying content or data objects.

  • Actions that affect the view of the content if no other option is tenable.

  • Execution of a dialog’s commands, including the Finish action of a wizard.

  • Canceling of a dialog, assuming canceling resets the dialogs parameters to the default or previous values.

Use a command button with an ellipsis at the end of the caption to access a dialog.

Gory details at http://www.zuschlogin.com/?p=18.

share|improve this answer
5  
Long answer, gets my vote for the rule of thumb in the first paragraph. –  Lisa Daske Jul 26 '10 at 15:15
    
By far the best and most clear answer. –  Bart Gijssens Nov 28 '13 at 11:39

Links are text—if you can only click the text, it's a link.

Buttons tend to look like physical controls or icons (although many are disguised as links)—if you can click the area around the text, it's a button.

Links tend to navigate to different pages, while buttons tend to stand for actions, but those actions often include navigation. Links tend to provide a lighter visual impact because they are text-based. Buttons tend to emphasize a functional use. For example, a big SAVE button has more impact than an inline "Save" link.

Buttons represent the mental model of physical controls, while links are a purely hypertext entity with no physical analog. As web design has evolved, the UX distinction between buttons and links has blurred: many buttons are styled to look like just text; CSS-styled text takes on the look of buttons.

share|improve this answer

Links convey relationship, whereas buttons stress action.

This reasoning is based on the premiss that buttons actually mimic physical buttons, and the symbolic meaning of links stems from chaining.

If you think what a real button or trigger on a machine does, it is easier to see what kind of actions a digital button can use. I.e. on, off, fire, and so on. The same goes for thinking of hyperlinks as index cards in a library - book abc on shelf a1 section b - they are used to identify a way to an item.

Both are interchangeable in different scenarios, but the implied functionality is slightly different.

share|improve this answer

Semantically speaking, any action which modifies server state should be done using a POST request from a and therefore use a button, rather than a link.

That's not to say the two can't be styled up to look and behave identically, but the markup should be different.

share|improve this answer
3  
Sorry, I don't agree. I don't think server state should be reflected in design "per se". I always design from the user's viewpoint, and she couldn't care less for server state. Technicals details should be transparent to user. –  luna1999 Jul 26 '10 at 13:45
1  
Yes, that's what I was saying in my second paragraph - you can make a link and a button look and behave exactly the same. The user would never know one is a button and one is a link. Though whether or not you should depends entirely on the context of their use. Buttons and links have different accordances and user expectations, which you may wish to leverage. –  Pete Williams Jul 26 '10 at 15:34
    
Unfortunately, buttons can't be styled entirely like links, but you can get close. –  theazureshadow Sep 20 '11 at 2:03
    
There are buttons which trigger no direct action and thus should use Post. The most common of these is "Search" –  CodesInChaos Nov 20 '11 at 19:43

In the good old days when you could easily change the 'read / unread' period in the browser, which show read links in a different colour - the advantage of links would be that you could easily see where you'd already been.

(Footnote - you may still be able to change the periods - but I've long since given up trying to find the control which does this...)

share|improve this answer

Links have been around for a long time and have a higher population than buttons on the web. When used in the context of navigating content they are effective.

Buttons are a much stronger affordance when you use them in the contexts when he user makes a form of commitment or investment to the website. (ie. saving, sharing, subscribing, joining, etc.)

I explain this in detail in the article I wrote: the-link-vs-button-debate

I hope this clears up the question of when to use the two once and for all.

share|improve this answer
    
Buttons have been around much longer in UI design than links. –  Bryan Oakley Jan 6 '13 at 20:45

One very important thing to note in the differences between links and buttons is that crawlers (both for search sites like Google and many site-level search engines) will not go to the target of a button; they only follow links.

Beyond that, luna, Michael and Pete all have valid points that cover just about everything else that I could think of.

share|improve this answer

I agree with the above, and I am against using hyperlinks for commands, particularly in non-web apps (e.g. winforms).

In non-web apps a hyperlink says to the user "ignore me unless to want to navigate away to some different information" and a button says "I'm going to change something or show a dialog if you click me".

The problem comes when the two are used interchangeably and a new user is scanning the form looking for a particular command. After a while they realise that they need to look at all of the hyperlinks too and invariably it takes the user twice as long to find what they are looking for because UI metaphors are not consistent. If the metaphors are not consistent the user loses trust and begins to hate the software. Trying to use software like this drives users up the wall (I think hotmail had the "attach" command as a hyperlink for a while and certainly for a while they had it in a combobox).

The Microsoft Windows Interaction Guidelines are a little fuzzy on the issue:

Command Buttons Vs Links

Guidelines: Links

They suggest that they are acceptable for secondary commands. The link posted by Michael Zushlag above makes an excellent point about this and the need for lightweight buttons.

The problem I see with lightweight buttons for secondary commands is knowing which commands these are. If you can come up with a consistent logic behind these (that is apparent to the user) and you can differentiate between primary and secondary commands with ease, then this is the best option.

share|improve this answer

Michael Zuschlag's answer is great, I would only precise that a link is different than a simple reference (an anchor).

Many people make a confusion between user experiences/interactions and HTML markup because they do not view the difference between a link and an anchor: - a link has a direction (forward or reverse link) and can be identify with a relation but can not be used by users with their user-agents to access to the hypertext reference (href attribute in HTML) because they can not be activated (except on Opera with the navigation toolbar). - an anchor only refers to something. It is only a reference to another resource even if it can be activated (with a click or with your keyboard) because user-agents defines this behavior.

And I think it help us to understand differences between an anchor and a button: - use a button when you call to action (as Michael said with "Update, Submit, Delete, Purchase" but also "read more", "download", etc.) - use a anchor when you just refers to another resource with an anchor text identifying the resource. If you require your user to read it, that means it is a "call-to-action" and not just a reference, so implement it with a button.

share|improve this answer

My experience show that often links are recognized easier as clickable and therefore clicked better taht for us sometimes leads to decisions to use links instead of buttons. But I agree that that shouldn't be done deep inside a process where the user is triggering an action. I also would like to add that the verb/noun differentiation can be difficult in other languages than english.

share|improve this answer

Whilst it is true that buttons and links are used interchangeably on the modern web, there is one fundamental browser feature that sets them apart:

Users can open a link in a new window or tab. A <button> or <input type='button'> cannot.

(As an example, try right-clicking on the "add comment" link and the (Add Comment) button below - only the first allows "Open Link In New Tab".)

Although <a> links can be styled to look like buttons, users will generally only expect the open-in-tab functionality to work on things that look like links.

share|improve this answer
    
This isn't all that true anymore given that both buttons and links can be set up to do anything you want client-side. –  DA01 Feb 23 at 22:53
    
@DA01 I had not made it clear that I was talking about <button> elements, which do not have this functionality. I have now updated the answer! –  joeytwiddle Feb 24 at 9:01
    
yes, that is a good point. I'd maybe be a bit clearly and state that a 'link can be opened by the user in a new window or tab' whereas a button element can not (the code would have to open the new browser for you). –  DA01 Feb 24 at 16:09
    
@DA01 Thanks, that was the missing bit. Done. –  joeytwiddle Feb 25 at 3:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.