I’ve written previously about the important differences between buttons and links. While reviewing some “component refresh” design mocks at work yesterday I noticed the designs were a bit unclear in this regard so I sent the designers a little decision-tree, which I’m noting here for future reference.
It’s important both for our users and for us as practitioners to distinguish between links (the <a> element) and the <button> element. The reason I push this is because they’re fundamentally different functionally, which has important usability implications. Users expect to use mouse, keyboard, browser back-button and assistive tech differently for links than they do for <button>s. And if they can’t visually distinguish one from the other, they’ll try things they expect to work then get confused when they don’t work.
I think this is an area where design and materials can’t be considered separately and need a joined-up approach.
Here’s a flow I hope is helpful.
Ask: does it…
- take the user to another page? Then it’ll be a link – the
<a>(anchor) element. - cause something to change on the current page, or submit a form? Then it’ll be a button – i.e. the
<button>element.
If it’s a link (<a>):
- it should be underlined so people know it’s a link
- it should have a hover state, for example stay underlined but change colour
- in cases where it’s a CTA you might choose to design it to look button-like and remove some standard link affordances. Just be aware you’re only “calling” it a button. In real user-experienced terms, it’s still a link.
- it does not natively have a disabled state. We shouldn’t be disabling links.
If it’s a button (<button>):
- it should look like a button, i.e. like a pill or rectangle
- It should not look like a link – that’d confuse users into thinking it takes them to another page.
- So it shouldn’t be underlined by default or on hover. It should have some other hover state.