Simplify your job search
Get 5+ job offers from top companies with 1 application
Get job offers

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. In my day-to-day work, this is an issue that has come up on numerous occasions.

More importantly, 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?

I worked for a year as a UX designer at Event Seek, refining the interface. When faced with the problem of links vs. buttons, our main goal was consistency. Buttons and links are signals to the user. Making sure that your interface uses buttons and links in a consistent manner saves users from second-guessing what your interface is telling them.

Element Functions

Based on my use of the web over the last 20 years, I’ve come to assume a number of things about how links and buttons work, both 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, such as create, update, or 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. As a designer, it’s your responsibility to find a UI attribute that makes the most sense for you—or indeed, your users—and stick with it. Perhaps your users would find it weird if “add [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 application’s 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 Function

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.


Traditionally, links came in blue; 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, such as a link that says “Your buddy list will display if you sign in now.”

The contextual explanation of the link offers many benefits. Most importantly, users can simply see the linked text and know where the link is likely to send them. In addition, providing a ‘title’ tag to links creates a tooltip that gives both users and search engines more information about what lies beyond the click.


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, for example, are key indicators that the user can click a button and initiate an action.


An image of four buttons, meant to work as tabs within a page.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!).

Look to the physical world for examples of best practices and mental models. 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?

About the Author

Andrew Maier

Andrew Maier is a lifelong student of the design community who believes that creation and learning are synonymous. His current interests include security, law, cities, and autonomy. He lives in Washington, D.C., in Dupont Circle.


  • Chris Ritke Reply

    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.

  • Andrew Maier Reply

    @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.

  • Joseph Hinson Reply

    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.

  • Marianna Reply

    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.

  • Michael A. Reply

    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.

    (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?

  • Andrew Maier Reply

    @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).

  • Joshua Lewis Reply

    @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.

  • JohnnyB Reply

    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:

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

  • roné/di/kristu Reply

    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.

  • huwaw69 Reply

    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…

  • Benjamin Dobson Reply


    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.

  • Brian Reply

    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.

  • Jim Parker Reply

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

  • Karl Walker Reply

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

  • Matt Canvas Reply

    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

  • rudraksha Reply

    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.

Leave a Comment on This Article