By Lauren Bowen, User Experience Designer
The question of whether to use a button or a link seems small. But what starts as a simple UX design problem can create more discussion than you thought possible, and open up a visual design and development can of worms.
Whether you’re a UX designer or just someone who wants to know more about the thought process behind choosing between buttons and links, you've come to the right place: let's have a look at what, if anything, can help provide clarity and guidance on when and where we use what.
We can start by thinking about what we mean when we say a ‘button’.
When is a button a button?
It looks like a button and when we check the HTML we see it’s coded as a <button>.
That means that, semantically speaking, it has a specific use and a clear purpose - often in forms, where it’s used to submit, commit an action, trigger a script to run etc. Basically, something that changes the front or back end of the website.
Its use cases are technically driven, so we can be quite clear about what it does and when it’s appropriate to use it. And from an accessibility perspective, a screen reader will understand that it’s a button, so the end user knows a change is about to happen.
Purists might say that’s it: if it doesn’t act like a button, then it shouldn’t look like a button.
Drawing the line here creates a clear understanding in the user’s head as to what a button means and what types of behaviour to expect. So if it’s a purely navigational action, for example, it should just be link text.
Is it as easy as that?
Well, not every website is submitting data and firing off scripts left, right and centre.
A heavily content-driven website will still have interactions and goals, but relying entirely on uniform looking text links to help users meet those goals, sounds like a bit of a usability headache.
As we’re designing a website and user experience, we’ll map out key journeys, define the structure of the site, and determine the information hierarchy of pages. All this is based around supporting the user's primary, secondary, tertiary etc needs.
We need to help the user differentiate between a means of achieving these primary goals and everything else, so anything that helps us do that should be considered.
I know just because I click/tap on a button, it doesn’t mean I expect some back end/front end change to happen. I take it in the context of the site that I’m visiting and the action I’m undertaking: ‘Find out more’ is still an action as far as I’m concerned.
And do I expect more from it if it’s styled as a button?
No, not really. The link text has adequately set my expectations.
The TripAdvisor site is very functionally rich, and has a quite clear distinction between functional interactions (buttons, notably for two different user goals: those giving reviews and those using reviews) and navigational/content based interactions (links).
Designing with buttons
So putting HMTL buttons to one side, the real question is: in the context of user journeys, user interface and user experience design, when do we style a link as a link and when do we style a link as a button?
If it helps users to do what they came to our site to do, it makes sense to treat a button style as another weapon in our UI armoury.
We can convey our information hierarchy and page purposes through different button styles, for example:
-
a bold button style for primary calls to action (CTAs)
-
a secondary button style for secondary CTAs
-
a link style for tertiary CTAs etc
But whatever link styles we choose to use, we have to be consistent in how we apply them within our site.
We need to define rules and stick to them so that the user can quickly get to grips with the interface and not end up frustrated by unexpected behaviours (or lack thereof).
We do also need to consider styles in the wider context of the user's online and offline experiences and the expectations that come with that. For example, if industry practice is to style a particular action as a button, try bucking that trend at your peril. A bit of general background and/or specific user research can make a huge difference to the success of a design.
But regardless of whether our CTA is styled as a button or plain old text link, the text that we use is key to setting and managing the user’s expectation, by hinting at the behaviour that follows.
Lloyds TSB couldn’t decide what to use, so went with both for their loans calculator link… and right next to each other! Would be interesting to know what gets more click throughs.
From design to build
HTML5 buttons are great – they come out-of-the-box as a rough and ready clickable button, and they’re easier to style than traditional form inputs. So, for that reason, it could be easy to misuse them for ease of build.
But this isn’t using the button for it’s intended build purpose and, from an accessibility perspective (where a screen reader’s interpretation of a page is much more literal than a visual interpretation), this could create a negative user experience.
So when it comes to build, we need to be clear about when we functionally need a <button> and when we just need a good old fashioned HTML anchor link that looks like a button.
Optimising a design
Whether it’s a live site, high fidelity prototype, or low fidelity wireframe, user testing can offer invaluable insight into whether our designs are hitting the mark for users. And if we need to quantify the results of user testing or just want an indication of where there could be problems, some in-page analytics and button/link tagging can help tell the story.
Buttons and links are also some of the easiest things to test and optimise, so if we’re in doubt (or even if we’re certain), why not do some A/B testing to see what performs better?
As with all multi-variant testing, it’s important that we’re able to get meaningful insights and results that can be attributed directly to a specific change. We need to make sure we’re testing one measurable change at a time and getting enough data to draw some accurate conclusions from.
So, as with all other aspects of design, there’s no ‘one size fits all’ approach. It’s about getting as much information as you can to help inform your decisions and working with the different disciplines around you to get to the best solution for the user.
Connect with Lauren on Google+