Designing Buttons Right: Hierarchy, Labels, States and Size

Picture the homepage of a small yoga studio. At the top there’s a lovely photo, and below it three buttons side by side: “Learn more”, “Schedule” and “Get started”. All three are the same size, all three glow in the same turquoise. Further down you find “Click here”, “Trial class” and a small grey “Submit” under the newsletter field.

Someone visiting the site for the first time really only wants one thing: to book a trial class. But which button gets them there? “Get started” sounds promising, but it might just as well lead to an online course. “Trial class” sits far down the page and looks like everything else. The page has six buttons and still not a single one that clearly says: this is the way forward.

That’s what this article is about. Buttons are among the smallest elements in an interface, yet they decide whether people can do what they came to do. You’ll learn how to rank buttons by importance, how to label them, which states they need and how big they should be. No prior knowledge required.

What’s a button, and what’s a call to action?

A button is an element that triggers an action: saving something, sending something, adding an item to the cart, closing a dialog. That sets it apart from a link, which takes you somewhere else, such as a new page. The distinction sounds technical, but it has practical consequences. More on that later.

A call to action, or CTA for short, is a marketing term. It refers to the element that invites people to take the most important next step: “Book a trial class”, “Try it free”, “Request a quote”. A CTA is usually a button, but it can also be a prominent link or a whole box with a heading, text and button.

So every CTA is a call to act, but not every button is a CTA. “Cancel”, “Reset filters” or “Close” are buttons people need, but they aren’t meant to push anyone towards anything. When a CTA leads someone to do what the website wants to achieve, such as buying, booking or signing up, that’s called a conversion.

How people recognize a button

Before anyone clicks a button, they have to recognize it as one. That sounds obvious, but it isn’t. Designers call the cues that make this possible signifiers: visible hints that show that, and how, you can interact with an element. For buttons, these are typically a filled background or a border, rounded corners, enough padding around the text and a position where you’d expect a button.

How much these cues matter was shown by the Nielsen Norman Group (NN/g) in a 2017 eyetracking study with 71 participants. Eyetracking means a camera records where people look on the screen. Participants had to find a specific clickable element on various web pages. On versions with weak signifiers, such as flat text with no background or underline, they needed 22% more time on average and looked at 25% more spots than on versions with strong cues. Their gaze wandered across the page, searching.

In practice, that means a button should look like a button. A colored word with no background that only changes when you hover over it with the mouse is easy to miss. And on a smartphone, there’s no hovering at all. Stick to familiar shapes: people spend most of their time on other websites and bring their expectations with them. This principle is known as Jakob’s Law.

Hierarchy: not every button is equally important

Back to the yoga studio. The core problem with its homepage isn’t one badly designed button. It’s the lack of any ranking. If every button is equally loud, none of them is. People have to read and weigh each one before they can decide.

Apple puts it quite directly in its design guidelines, the Human Interface Guidelines: keep the number of prominent buttons to one or two per view. Too many of them increase cognitive load, because people spend more time considering their options before they choose.

The three levels

Most interfaces get by with three levels. The names vary from team to team and design system to design system, but the principle is the same everywhere:

• Primary button: the most important action in this area. A filled shape in the accent color, with the strongest visual impact. Ideally there’s exactly one per area.
• Secondary button: important but subordinate actions. Often just an outline or a paler fill. Easy to spot, but it doesn’t push itself forward.
• Tertiary button: the quietest level, often just text without a background (a text button). Meant for side actions like “Cancel” or “Remind me later”.

Google’s Material Design, a widely used design system, even distinguishes five levels: from the filled button for important, final actions like “Save” or “Confirm”, through tonal and elevated variants and the outlined button for medium-emphasis actions, down to the text button for the lowest-priority actions. For getting started, three levels are plenty.

Show hierarchy through style, not size

An obvious idea is to simply make the most important button bigger. Apple advises against it: when several options sit side by side, the buttons should be the same size and differ only in style. Buttons of different sizes right next to each other quickly look messy and inconsistent. Equal size, on the other hand, signals that these options belong together, and one of them is the recommended one.

For the yoga studio, it looks like this:

Before: “Learn more”, “Schedule” and “Get started”, all three the same size and filled with the same turquoise.

After: “Book a trial class” as the only filled button. Next to it, “View schedule” as an outlined button. “Learn more” is gone, because the text below the photo already explains the studio.

After this change, nobody has to think. The eye lands on the turquoise button, and it says exactly what will happen.

Hierarchy applies per area, not per page

A long page can have several primary buttons as long as they sit in different areas. The yoga studio can offer “Book a trial class” in the header and again at the end of the page. What matters is that within any one screenful, it stays clear which action is the most important. And that the same CTA has the same label everywhere. If it says “Book a trial class” at the top and “Try it free now” at the bottom, people will rightly wonder whether those are two different things.

Button order in dialogs

In a dialog with two buttons, such as “Save” and “Cancel”, the question is which goes on the left and which on the right. NN/g gives a pragmatic answer: there is no universally correct order. Windows traditionally puts the confirming action first, Apple puts it last. More important than the order itself is that it stays the same throughout your product. Once people have learned where “Save” sits, they’ll click there next time without thinking.

One exception deserves attention: destructive actions, meaning those that delete something permanently. Apple explicitly advises against giving a destructive action the role of the highlighted primary button, even if it’s the most likely choice. The reason: precisely because the primary button stands out so much, people sometimes click it without reading it carefully. A delete button therefore gets a warning color (usually red) and a clear label, but not automatically the spot of the default button.

Labels: the button says what happens

The label is the part of a button that tells you the most about it, and at the same time the part where teams most often cut corners. These short bits of interface text are called microcopy. For buttons, there’s one simple rule: anyone who reads only the button should know what happens after clicking it.

Verb plus object

The most reliable labels start with a verb and name the object of the action. Apple recommends this in its guidelines too, using “Add to Cart” as an example. A few before-and-after examples:

• “OK” becomes “Confirm appointment”
• “Submit” becomes “Send request”
• “Click here” becomes “Download schedule (PDF)”
• “Next” becomes “Continue to payment”
• “Yes” (in the dialog “Do you want to delete this file?”) becomes “Delete file”

The last example is especially important. A dialog with “Yes” and “No” forces people to read the question above and translate it in their heads. If the question is phrased in the negative (“Are you sure you don’t want to save?”), a wrong click is almost guaranteed. With “Delete file” and “Cancel”, each button makes sense on its own. NN/g recommends labeling buttons with specific actions rather than generic words like “OK” for the same reason.

Avoid “Click here” and “Learn more”

“Click here” describes how to operate the element, not where it leads. “Learn more” is a little better but still vague: more about what? And if a page says “Learn more” five times, the buttons can no longer be told apart. That particularly affects people who use a screen reader, software that reads screen content aloud. Many screen readers can list all the links and buttons on a page. Five “Learn more” entries in a row help nobody there.

It’s better to name the destination: “More about Hatha yoga” or “See prices”. That’s slightly longer, but unambiguous.

Short, but not cryptic

Two to four words are enough for most buttons. Longer labels wrap onto two lines on a smartphone and look cluttered. If an action needs more explanation, put it in a short sentence next to or below the button, not in the button itself. At the yoga studio, for example, the line below “Book a trial class” reads: “Free, no contract. All you need is a mat.” That one sentence clears up the most common concerns without overloading the button.

Keep the wording consistent

Pick one style and stick with it. If one button says “Save”, the next one shouldn’t say “Store changes”. In English interfaces, short imperative verbs have become the norm (“Book class”, “Create account”). Possessive phrasing like “Book your class” works too, but use one pattern consistently rather than mixing them.

Stay honest

Labels can also manipulate. One well-known pattern is called confirmshaming: the button for declining a newsletter says something like “No thanks, I’d rather miss out on deals”. Tricks like this are dark patterns. They might bring in a few extra sign-ups in the short term, but they cost trust. A decline button simply says “No, thanks” or “Not now”.

By the way, in Germany the label of an online shop’s order button is regulated by law: under Section 312j of the German Civil Code (BGB), it must clearly indicate that the order involves an obligation to pay, for example with “zahlungspflichtig bestellen” (“order with obligation to pay”). What that means for checkouts in detail is covered in the article Forms Nobody Abandons.

States: a button is never just one picture

A button doesn’t always look the same. It responds to what people do with it and to what’s happening in the system. These different appearances are called states. So when you design a button, you’re not designing one element but a small family of variants.

The most important states

• Default: what the button looks like when nobody is interacting with it.
• Hover: the mouse pointer rests on the button. A slight color change signals: you can click here. Touchscreens have no hover state, so it must never be the only cue.
• Focus: the button is selected via keyboard, for example after pressing the Tab key a few times. A clearly visible outline shows where you are.
• Pressed (or active): the moment of the click or tap. The button gets slightly darker or looks pushed in.
• Loading: the action is running, but the result isn’t there yet.
• Disabled: the button is visible but can’t be used right now.

Focus: invisible until it’s missing

Many people don’t use websites with a mouse but with a keyboard, for example because of motor impairments, because they use a screen reader, or simply because they’re faster that way. For them, the focus state is their only orientation. Without it, they don’t know which button will be triggered when they press Enter.

That’s why the Web Content Accessibility Guidelines (WCAG), the internationally recognized guidelines for accessible web content, require in success criterion 2.4.7 (“Focus Visible”) at level AA that keyboard focus is visible. A common mistake is removing the browser’s default focus outline with CSS because it “doesn’t look nice”. If you replace it, use a custom one that’s at least as visible. You’ll find more on the topic in the glossary under keyboard accessibility.

Pressed and loading: give feedback

Apple puts it briefly: a custom button always needs a pressed state. Without one, it feels unresponsive, and people wonder whether their tap registered at all.

Feedback becomes even more important when an action takes time. Imagine someone taps “Book a trial class” at the yoga studio, and for two seconds nothing visible happens. What comes next is predictable: they tap again, maybe a third time, and in the worst case three bookings are created. For cases like this, Apple recommends showing an activity indicator inside the button and adjusting the label, for example from “Checkout” to “Checking out…”. For the yoga studio, it could look like this:

Before: “Book a trial class”, no visible change for two seconds after the tap.

After: “Book a trial class” immediately changes to “Booking…” with a small spinner. A second tap doesn’t trigger another booking.

The button keeps its width so the layout doesn’t jump.

Disabled buttons: use with care

A greyed-out button that only becomes active once a form is complete looks elegant at first glance. In practice, it brings a number of problems. The Swedish consultancy Axess Lab summarized them in a widely cited article:

• A disabled button doesn’t explain why it’s disabled. People have to guess what’s missing.
• It’s usually pale and low in contrast, which makes it hard to read. WCAG explicitly exempts inactive components from contrast requirements, which doesn’t make things any better.
• Keyboard and screen reader users often can’t reach it at all, because disabled elements drop out of the tab order.

Axess Lab’s recommendation: keep the button active and, on click, say clearly what’s missing, right at the affected field. If you still want to tone it down visually, make sure it stays easy to read. Disabled buttons aren’t forbidden, but they should be the exception, for instance when an action really is impossible right now and a short note next to it explains why.

Size and spacing: hitting it should be easy

A button you can’t hit helps nobody. How easy a target is to hit depends on its size and distance. This relationship is described by Fitts’ Law: the bigger and closer a target, the faster and more reliably you reach it.

Minimum sizes

There are clear reference values for button size:

• WCAG 2.2 requires at least 24 × 24 CSS pixels in success criterion 2.5.8 (“Target Size (Minimum)”) at level AA. Smaller targets are only allowed if there’s enough spacing to neighboring targets.
• The stricter level AAA (criterion 2.5.5) calls for 44 × 44 CSS pixels.
• Apple recommends a hit region of at least 44 × 44 points.
• Google recommends at least 48 × 48 dp for Android (density-independent pixels, a unit that appears roughly the same size on different displays).

For everyday work, the rule of thumb is simple: buttons that people tap on a smartphone should be at least 44 to 48 pixels tall. 24 pixels is the WCAG minimum, not a recommendation for good usability.

Keep in mind that what counts is the clickable area, not necessarily the visible one. A small icon, such as an “X” for closing, can stay visually delicate as long as padding makes its hit area big enough. For image buttons, Apple recommends about 10 pixels of padding between the image and the button’s edge.

Spacing between buttons

Spacing matters at least as much as size. Two buttons that touch each other invite mis-taps. That’s especially risky when the two actions have very different consequences, such as “Save” and “Delete”. Pairs like these shouldn’t sit tightly together, and the destructive action also needs a confirmation step or a way to undo it.

Placement

On a smartphone, people reach the bottom of the screen with their thumb more easily than the top corners. In apps, placing important actions at the bottom, often as a full-width button, has proven its worth. On websites, the primary button belongs where the decision is made, right after the information someone needs to make it. That’s why the yoga studio places “Book a trial class” below the short description of its offer and again after the prices, not isolated in a corner.

Contrast and color

A button has to stand out clearly from its surroundings, and its text has to be easy to read. Both can be measured. The contrast ratio describes how much two colors differ in brightness. WCAG requires at least 4.5:1 for normal text (criterion 1.4.3). For the boundary of a control, criterion 1.4.11 (“Non-text Contrast”) requires at least 3:1 against adjacent colors, but only when that boundary is needed to identify the button in the first place. A button that is already recognizable by its text doesn’t need a high-contrast border.

In practice, a light grey outlined button on a white background can be a problem if the border is the only thing marking it as a button. The focus indicator also needs a contrast of 3:1 against adjacent colors.

And color alone is never enough. If the primary button differs from the secondary one only by being green instead of grey, not everyone will see the difference. A filled shape versus an outline is a difference that works even without color perception. You can check the values with tools like the WebAIM Contrast Checker.

Button or link?

One final point that’s more about implementation but matters in design too: buttons trigger actions, links take you somewhere else. In code, these are two different HTML elements, <button> and <a>. Screen readers announce them differently, and they respond differently to the keyboard.

In design, the line often blurs, and that’s fine: a CTA like “View schedule” technically leads to another page but may look like a button. What matters is that the right element is used in the code. A common mistake is the opposite: a <div> that looks like a button and works on click, but can’t be reached with the keyboard and isn’t recognized as a button by screen readers.

Another detail concerns buttons that only show an icon, such as a heart for saving or a gear for settings. According to MDN Web Docs, Mozilla’s web development reference, such buttons have no accessible name a screen reader could announce if they contain no text. The fix: text inside the button, visually hidden if necessary. Visible text helps everyone, though, because not every icon is as obvious as it seems to the design team.

Conclusion

In the end, the yoga studio’s homepage no longer has six equally loud buttons but a clear ranking. “Book a trial class” is the only filled button in view, with a short sentence below it that addresses concerns. “View schedule” sits next to it as an outlined button. All buttons are at least 44 pixels tall, have a visible focus state and show that something is happening after a tap. “Click here” and “Submit” are gone.

Good buttons are rarely spectacular. You notice them when they’re missing: when people search, hesitate, click twice or delete the wrong thing. If you ask yourself the four questions from this article for every button (How important is it? Does it say what happens? Does it respond to everything people do? Is it easy to hit?), you’re already a step ahead of most interfaces. Whether it really works is shown by a quick test: ask someone to complete the most important task on your page without any explanation, and watch where their eyes go first.

Checklist

• Each area has exactly one primary button, and all others are visibly subordinate.
• Hierarchy comes from style (filled, outlined, text), not from different sizes side by side.
• The same CTA has the same label everywhere.
• Every label names the action, ideally as verb plus object. No “OK”, “Click here” or “Yes”.
• Destructive actions are clearly labeled, color-coded and not the default button.
• Hover, focus, pressed and loading states are designed, and focus is clearly visible.
• Disabled buttons are the exception and explain why they can’t be used.
• Touch targets are at least 44 × 44 pixels and have enough space between them.
• Button text has a contrast of at least 4.5:1, and necessary boundaries at least 3:1.
• The code uses real <button> and <a> elements, and icon buttons have an accessible name.

Sources

• Nielsen Norman Group: Flat UI Elements Attract Less Attention and Cause Uncertainty
• Nielsen Norman Group: OK-Cancel or Cancel-OK?
• Apple Human Interface Guidelines: Buttons
• Material Design (Material Web): Buttons
• Google: Touch target size (Android accessibility)
• Axess Lab: Disabled buttons suck
• W3C: Understanding SC 2.5.8 Target Size (Minimum)
• W3C: Understanding SC 1.4.11 Non-text Contrast
• W3C: Understanding SC 2.4.7 Focus Visible
• MDN Web Docs: The Button element
• Gesetze im Internet: Section 312j BGB (in German)