Creating Usable Links and Buttons

A chain linkA chain linkPhoto by residae.

I’ve often wondered what the difference is between a button and a link. I mean, why do designers prefer one over the other? Isn’t the link a rather modern “invention?” During my day-to-day work, this is an issue that has come up on numerous occasions.

Why do users sometimes expect buttons and at other times expect links? What should we do to further differentiate these interface elements and make them unambiguous?

While refining the interface at Event Seek we always strived for consistency. Making sure that your interface uses buttons and links in a consistent manner saves users from second-guessing what your interface implies.

Element Functions

Based on my use of the web during the course of my lifetime, I’ve assumed a number of things about how links and buttons work independently and together.

Speaking from experience: Links generally navigate the browser to or from a particular view, but have no real effect in terms of data creation or loss. That means, generally speaking, links should only change what or how data is displayed to the end user.

On the other hand, buttons typically execute an action (create/update/delete) on a particular item within your web application. Hence, if you are changing the state of any part of your application (modifying a database, for example), it may be best to use a button to do so.

This action/navigation convention is just one of many possible UI delegations. Find something that makes the most sense for you—or indeed, your users—and stick with it. Perhaps your users would find it weird if “adding someone as a friend” was a button they could click (after all, that is a bit verbose for a button), but, again, it is changing the state of the application. These are the kinds of questions you should ask yourself before choosing a convention. What will make the most sense (consistently) throughout the application? A user’s mental model may dictate that a link should be used over a button.

Consistency is one of the best ways to make your site more usable and your design more attractive.

The advent of RESTful application architectures facilitates this generalization. In RESTful applications, any links on the site can be considered “safe”, that is, clicking them will generally not change the applications’ state. If the state is indeed changed, it is easily recoverable. By the same token, any buttons on the site will change the applications state. Think: adding items to a shopping cart or saving a document. These are actions and are therefore better suited to buttons.

Form

After you’ve decided which UI element does what, you should pay attention to making your links look like links and your buttons look like buttons.

Links

Traditionally, links came in the blue variety; a fragment of underlined text that renders a “hand” style cursor on hover will meet nearly everyone’s mental model of a link. Over time, this model has changed to merely text which is underlined, or text that is visually distinct yet still presented in content.

In the early days of the web, most links were chunks of text that merely said “click here.” Unfortunately, many people (and search engines) didn’t understand that text. “Click here” doesn’t describe the content being linked to. More often than not, to understand what content lie on the end of the link, someone would actually have to go to the page for to which link pointed towards. Today, we can fix this problem by two means: make the linked text actually describe the destination (For example: Your buddy list will display if you sign in now.). Now users can simply see the ‘linked’ text and know what will be on the end of the link. Secondly, providing a ‘title’ tag to links will create a tooltip that gives both users and search engines more information about what lies beyond the click.

Buttons

Buttons have evolved over the years. Initially, buttons were presented as static boxes in a rather simple UI. Today, buttons on the web are generally operating-system-specific UI elements that are rendered within a web page. Moreover, these buttons are generally 3-dimensional in shape with no highlight state. Presented this way, buttons can be the most easily overlooked element on a web page, since they will blend in with the operating system around them.

Thankfully we can style them any of a number of ways thanks to CSS–but try and keep something resembling a button. Slight bevels and rounded corners are key indicators that the user can click a button and initiate an action.

Interpretations

Button-tabs. Bleh.

To further illustrate how important the distinction between links and buttons are, consider navigation without links, but rather, with buttons:
How confusing would it be to come to a site and be presented with a series of buttons that renders your navigation? Surely users would be much more apt to use “tabs” to navigate your site. Tabs, for those of you wondering, have become increasingly popular because they fit a user’s mental model of how a physical page works. In a tabbed notebook, flipping to a certain tab will bring that tab to the top of the notebook and show you content only related to the tab (assuming good sorting!).

Always look to the physical world for examples of best practices. In many cases problems that appear new are only virtual copies of problems in the physical world. Tabbed navigation is a common UI-Pattern that uses links to display collections of information.

Microsoft uses this UI pattern in the color dialog box of Windows 2000.

Lastly, the concept of Extras on Demand allows Interaction Designers to simplify an interface by hiding ancillary interface elements. Extras on demand is a very useful pattern for displaying information to users. Always look to simplify your interface and provide users with only the bare-minimum interface elements. Allowing extras options only to savvy users, comforts new users and empowers advanced users.

Would these extras be better reached by the use of a “link” in the OS? Interestingly enough, links have slowly made their way into operating systems, yet they are the product of the internet. Do you think the differences between these two interface elements are subtle or distinct? When are each of these elements are appropriate?

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. I agree with your definition of links vs buttons. I’m starting to like the notion of a ‘blink’: a sort of button-link mix that looks like this: [link] – for those cases where you’re navigating to a different view: not a normal view of data but rather to an area where you will be manipulating or adding data. Or also when you’re performing an action such as deleting an item. Blinks are ‘lightweight’ – they don’t weigh down the page as buttons do. And then there are the mouseover blinks, that only appear when you mouseover the general area of a data element – they perform actions like deleting or editing of that specific element.

  2. @Chris Ritke: I made a very similar concept for Event Seek. Links that are underlined by default and have a more weighty hover do “actions” on various views. It seems that there may be too many UI elements in that case, but it made the most sense to me at the time.

  3. Thanks for the article. I’m excited about the site and look forward to more interesting posts like this one in the future.

    I think as the general public becomes more saturated with web conventions that they will gravitate to using buttons and links the right way in the future. We can only hope that we see less websites using buttons as navigation as time goes on.

    Although, it does provide us with redesign work.

  4. Thanks for the post.
    I am a User Experience Architect and I tend to use buttons for call to actions (CTA). They must have nice UI design, clear labelling and prompt the user to click them. As you already stated buttons should follow an action while links connect the page with another content page. I use links in content areas or as view also suggestions.

  5. Michael A. December 27, 2008

    Great post. I really love this site…thank you for your gift to the UX community. I wanted to mention a specific scenario and get your opinion. Studies have shown that it is more effective to use a text link for the action “Cancel” and a button for the “positive” calls to action such as “Continue” or “Submit” (anything that keeps the user moving forward in the task vs. ending it) when the two are placed together.

    Example:
    (button that says “Save”) next to (text link that says “Cancel”)

    So, my question is, what do you think about breaking convention in this instance?

  6. @Michael A.: Michael, do you have any links to those studies? I’d be very interested to read them. Personally, I think that cancel doesn’t execute an action so much as navigate the user away from the present page, as a link normally does. In this regard, I think that the prevalence of the ‘cancel’ link in forms is a step forward towards establishing a more universal convention of links (navigation) vs. buttons (changing data).

  7. Joshua Lewis February 1, 2009

    @Andrew Maier: I disagree about the nature of the cancel action. Think of it as beeing similar to clearing a dry erase board, you are taking the action of destroying the information that is there and possibly even the expected return on the time invested in posting it. But regardless of which view is objectively correct it is the end users perception that is should be more important.

    That being said I think that a cancel action should usualy be treated as a link, depending on context of course. This is because I believe it is an effective method of reducing a users chance of taking the cancel action in error. Since cancel is destructive and can sometimes have a fairly high cost the benefit tends to outweigh the cost of breaking the convention discussed in the article.

    I expect that some of the studies and articles that have brought me to this conclusion are the same that Michael was refering to.

  8. Thanks for putting this together. For me, it’s all about cheat sheets. I always have my iPhone with me, so I keep them there for handy reference – even offline. The best HTML cheat sheet I’ve found so far is from these guys:

    http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=303696538&mt=8

    It has all of the elements, entities, colors and more. They also have great cheat sheets for CSS and Javascript. Hope this is helpful.

  9. roné/di/kristu March 24, 2009

    Great article and great thoughts.

    There is no universal answer. However I would highly recommend reading over and over just one book to prevent going nuts over n00b behaviour: Web Usability from the one and only Jakob Nielsen.

    He gives answers to questions you never tried to ask. It is an eye opener in so many ways and really is extremly helpful because it shapes your understanding of design regarded as usability.

    There are so many hypes, trends and things only trendy hyped experts understand – Nielsen is the man who puts a mirror in front of you and simply ask you: “Dude, there is you and there are many potential customers who simply do not get what you want from them.”

    Never ever try to educate the masses, instead invite them having a good time on your website. Actually I put all my (re-)design projects on hold to take a break. I made a list of important changes and priorities I want to implement in any of my current projects to really do some outstanding performance – for the n00bs and therefore potential experts.

  10. i pretty much like to use buttons than links, and add a little design to the buttons so the reader will be curious to what’s going to happen when they click the button hahaha, like the animations and stuffs…

  11. Benjamin Dobson May 5, 2009

    Hi,

    As someone whose trying to design Mac apps, links in the OS interest me. I have decided that they should only be used when linking to a web page. One interesting aspect of links in desktop apps is that they must be styled much more meticulously than web page links, as you have no right to control the look and feel of the OS. Your links will either integrate nicely or look ugly and out-of-place.

    In general, however, links should be avoided. They will rarely look right, except in a few special contexts, such as word processing.

  12. I think that website visitors expect buttons (picture links) in the site navigation if the site is visually appealing. Other times (like in this blog) users expect regular text links ( Website design ). Also remember when designing sites that in regular static sites, the use of rollovers can be applied to really appeal to the senses of users. These however have to be used cleverly. For example make one of the buttons look like it is being pressed down when clicked.

  13. I wrote an article (in Dutch, http://www.frank-ly.nl/acties-op-een-formulier) about the use of links vs buttons in forms, and I might have used the same sources as Michael A..
    These were from Jarret: http://www.ixda.org/discuss.php?post=33164 andWroblewski: http://www.lukew.com/resources/articles/web_forms.html, http://www.lukew.com/ff/entry.asp?730 and http://www.lukew.com/resources/articles/psactions.asp
    Hope you’ll find them useful!

  14. I think a stylish nav bar that uses interactive buttons work very well in my experience.. thanks for the article

  15. I always like to use buttons with my navigation but I here text link is much more search engine friendly.

  16. at the moment i like the cufon replacement graphic link on nav bars.

    handy article to bookmark though when asked about links v buttons. thank you

  17. Links are treated as outbound by SEO knowledge. But how about the Buttons. Buttons will not be links. so buttons can be shown as links while still making it useful sometimes.

Related Posts