Buttons are a crucial component for UX designers to master. So, how do we get them right?
Recently, I decided to overhaul some of the button styles in the Design System of the company I work for. For the year that I’d been there, the development team and I would have constant back-and-forths, with questions like ‘is this the right use-case?’ and ‘what colour should this be?’ appearing often in my Slack messages. Each time, I felt uncertain in my response, because I didn’t truly know the answer. After grappling with this for long enough, we decided to make some changes.
I must admit — I had been avoiding this task. Superficially, buttons are possibly the easiest component to create, but because of this, I knew that there had to be something complex below the surface of their deceptively simple design. Sure, every app and website on the planet uses buttons, but what makes them work? And how damaging is a badly designed button to a user’s experience?
After much research, I discovered the answer: very.
But why?
To understand this, we need to think about the 5 key factors that influence a button’s design:
The type of button;
The action that it carries out, and whether this is primary or secondary;
Whether it relates to other actions nearby;
The location;
The state of interaction.
Button types.
According to Google’s Material Design guidelines, the three heuristics to remember when designing a button are: identifiable, findable, and clear.
Generally speaking, there are 6 core button types that you need to know about as a designer:
Text
Outlined (or Ghost)
Icon
Contained
Toggle
Floating Action Button (FAB)
There are more, less-frequently used styles, depending on where you look, but these are the ones you really need to get to grips with.
Hierarchy.
It’s important to note that the style of your button will be directly influenced by its hierarchy in the interface. There are three levels of emphasis we need to consider: high, medium, and low (think of these as a pyramid, with your most important actions at the very top). A high-emphasis button will command the most attention of any other, while a low-emphasis button will be seen as non-essential or supplementary. All actions in your interface should be attributed to at least one of these levels. If you’re unsure of where your actions fit within this hierarchy, I recommend creating an emphasis table to find out.
We can usually define the emphasis of a button by how visually prominent it is. Users tend to be biased towards objects that are identifiably different in size, shape, and/or colour, so it’s important that our primary, high-emphasis actions stand out from the crowd.
Text buttons.
This is a button where the label isn’t contained within a specific shape or fill. This is a medium to low-emphasis button, and tends to be used when we don’t want to distract from the main CTA but want to offer a secondary interaction. Text buttons can usually be found within dialogs and cards.
Outlined (or Ghost) buttons.
This is a medium to high-emphasis button. These are buttons that have no fill, but show a text label contained within a stroke. An outlined button tends to contain an important action that is not primary to the interface.
Contained buttons.
This is a high-emphasis button (the highest, really). A contained button will make use of a solid or gradient fill, and sometimes elevation. Contained buttons can make use of text labels as well as icons (sometimes just icons, too).
Toggle buttons.
Sometimes referred to as segmented button groups, a toggle button can be used to group similar actions. These should share a container to reflect the fact that they are related.
Primary and Secondary action buttons.
Most interfaces have a primary and secondary action at once; for example, ‘submit’ and ‘cancel’. These have a contextual relationship (the content that they act on is the same) but should be styled differently. As previously mentioned, you should always give the strongest visual weight to your most important action.
When your primary action is positive (‘submit’, ‘send’, ‘upload’), it should be styled with the strongest visual weight. In this case, it is assumed that the user will proceed with the primary action, and so the secondary ‘cancel’ or ‘exit’ option is de-emphasised. We want to encourage the user to move forward through the flow.
If, however, your primary action is negative, it is not enough to simply style it with more visual weight. In fact, this could be destructive to your user’s experience. We don’t, for example, want a user to accidentally select an irreversible action because they thought it was the right path to take. If you display a negative primary action that relates to a critical operation, it needs to be styled in a way that is unmistakably different from the rest of your primary actions.
Button groups.
There are two reasons why you may want to use a button group:
They have a contextual relationship; for example, a primary and alternative action like ‘delete’ and ‘cancel’.
They are being used for directional navigation; for example, if you are moving through linear content.
If your buttons are not related, placing them in close proximity could be destructive to your user’s experience.
Similarly, including a lot of actions will be detrimental, as your user could be overloaded by the burden of choice.
Unless your buttons are part of a toggle or segmented button group, they should have some visual differences. I would recommend that you never use the same exact styles for neighbouring buttons.
Labelling and affordances.
In addition to styling, arguably the best way of letting the user know what your button will do is through a clear, accurate label. With this, there is one key rule to follow: always explicitly describe the action.
Simple, right? There’s a little bit more to it though.
Use precise diction. As a graduate of English, I can promise you that verbs have very specific connotations. If you are aiming to make your interface accessible for people who aren’t reading their native language, or who aren’t clear on technical jargon, you will need to ensure that your words aren’t easily misinterpreted. Also, filler words like ‘a’ and ‘the’ are never needed.
Button labels should always, always use action verbs. There is possibly nothing worse than a generic ‘yes’ or ‘no’ label. This tells the user absolutely nothing. The best recipe you can use for a label is:
Verb + adverb OR direct object.
E.g. ‘Delete now’ or ‘Publish review’. Avoid using vague verbs like ‘Click here’, though, since they add no affordance at all.
Sometimes, just the verb is sufficient. For example, if your action can only relate to one piece of content. The brevity required in your label will usually depend on where the button is positioned. If you are showing a number of buttons relating to different pieces of content, it’s important that use a direct object in your label, or things could get confusing. Alternatively, when one button is shown for a whole page or card, the context will be pretty easy to grasp.
Icons
If you are labelling a critical action, consider adding a symbol for extra affordance. Adding a trashcan symbol for a ‘delete’ action, for example, is a great way of conveying the outcome of the action. Don’t be excessive with this, though; too many symbols can create visual noise and can actually reduce the effect you’re trying to achieve.
Sentence vs. title case?
If your labels aren’t capitalised (which, in 2022, is a rare occurrence), I would generally recommend that you use sentence case for all your labels. Definitely avoid using title case for labels of more than 2 words.
Content relationships and location.
One thing that’s important to consider is where you will display your buttons in relation to the content. One of the most frequent patterns you will find in UI is for the button to be placed on the right side. There are a few reasons for this:
Many people read from left to right, so if you are scanning your content in this direction, it makes sense for the ‘progress’ action to also be on the right.
Many people are right-handed, so a right-aligned button on an app interface is within comfortable reach of the thumb.
There is a general perception that a right-aligned button closes or completes a form.
When this style is applied, it’s important to ensure that your primary action is also on the right side.
Sometimes, it is better to use a left-aligned button. In terms of accessibility, a left-aligned button is easier for tab key navigation.
Adobe’s design system, Spectrum suggests that button groups should be left-aligned when they follow content such as a block of text and right-aligned when they are displayed in container components, such as dialogs, popups, and cards. In my book, this is the most intuitive way of aligning your buttons; when engaging with a block of text, we tend to read top-down. But, when we’re faced with more dynamic content, studies have found that our eyes tend to approach it in a zig-zag pattern, culminating at the bottom right.
Button states.
Button states are what we use to convey which stage the user is in the interaction. There are 6 you need to be aware of:
Enabled: a button the user can interact with.
Disabled: a button the user can’t interact with.
Hover: a user has placed their cursor over the button.
Focused: a user has highlighted the button using a keyboard or voice input.
Pressed: A user has tapped or clicked the button.
Because each state represents a different level of interaction, it’s important that they are visually similar, while not dramatically altering the appearance of the button. There need to be clear differences that distinguish it from the other states.
Designing states
A great way of keeping your states consistent between different buttons is by using an overlay; this is a semi-transparent covering that is placed over your enabled state. A good guideline is to match the colour of the overlay to the text colour of your button.
For disabled states, Material Design recommends a 38% opacity version of the enabled state. You can also remove elevation to emphasise that it can’t be interacted with.
Your pressed states should always have more visual weight than your enabled states; it’s important that the user knows when they have interacted with an element, to prevent rage-clicking.
Sources.
Here are some of the sources and articles that informed my research. I think you’ll find them helpful:
Thanks for reading. Happy designing!
Comments