What should be considered in app button design?

Deep dive

Buttons indicate actions users can take and are one of the key elements of the interactive design. You’ll find them in key spots like dialogs, modal windows, forms, cards, and toolbars. 

Clear, well-placed buttons boost usability, increase conversions, reduce task completion times, and improve navigation. They indicate what actions to take and what to expect, preventing users from guessing or wandering aimlessly through the interface. 

Button UI design can get detailed, so let’s focus on the essentials. 

Button anatomy

The anatomy of a button typically includes the following elements:

1. Text label: The text on the button that indicates the action (e.g., “Submit,” “Next”).
2. Container: The button's overall shape or body, which holds a text or an icon inside; the tappable area.
3. Icon: An optional element that can accompany or replace the text to clarify the action.
4. Border: A line around the button that helps it stand out from other UI elements.
5. Border radius: Defines the roundness of the button's corners. A higher border radius will create more rounded corners, while a lower value keeps them sharp. 
6. Background: The color behind the text, which makes the button pop and feel interactive.
7. Top and bottom padding: The space between the text and the button’s top and bottom edges. It controls the button's height and ensures the content is vertically centered and spaced properly.
8. Right and left padding: The space between the content and the button’s left and right edges. It controls the button’s width and ensures the content isn’t too close to the edges.
9. Outer margin (safe space): The space around the button, separating it from surrounding elements. It ensures sufficient white space around.

In your button design, you can also use elements like shadows or highlights to create a three-dimensional effect, or color changes and subtle animations to indicate interactivity.

Button types

There are two distinct categories of buttons: those based on hierarchical importance and those defined by functionality and appearance. 

Hierarchy-based buttons

These buttons differ by their level of importance in guiding user actions. They visually signal the priority of actions a user can take:

• Primary button: Represents the most important action on a screen, such as “Create New Project.”
• Secondary button: Provides alternative or supporting actions, such as “Import Existing Project.”
• Tertiary button: Represents less important actions, such as “View Archived Projects.”

In this example, “Publish” is the primary button, “Save” is the secondary button, and “Preview” is the tertiary button—each with a distinct style.

👋 Read the full case study

Related reading: How to create the right button hierarchy?

Functionality and style-based buttons

Let’s turn to Material Design to review different types of buttons. Their library is extensive enough yet not too cluttered.

1. Elevated button

Use: Raised with a shadow for emphasis, great for highlighting primary actions on low-contrast backgrounds or in dense content areas.

Avoid: On already elevated elements (like cards) where it might look redundant or cluttered.

2. Filled button

Use: Solid, bold button ideal for primary actions where you need strong visual emphasis (e.g., “Submit” or “Approve Request”).

Avoid: When there are multiple buttons with similar importance, as it can visually overwhelm the interface.

3. Outlined button

Use: Button with just an outline, perfect for secondary actions where you want subtle visibility, like “Cancel” or “Learn More.”

Avoid: On busy backgrounds or in low-contrast environments where it might not stand out enough.

4. Icon button

Use: A small button with just an icon, ideal for simple actions (like settings, search, or navigation).

Avoid: For complex actions that require more explanation, as it lacks text and might confuse users.

5. Text button

Use: A button with just text, good for minimal actions that don’t need much emphasis, like “Skip” or “Read More.”

Avoid: For critical actions, as it lacks strong visual prominence and can easily be overlooked.

FAB (Floating Action Button)

This is a circular button that hovers above other content in an app interface.

Use: For secondary or tertiary actions, such as opening a chatbot or expanding a floating menu. Sometimes, FABs can be used for primary actions, like in Gmail. 

Avoid: In interfaces with many options or actions, as it might confuse users or clash with other primary elements.

Extended FAB

Use: A wider version of the FAB with a label, perfect for primary actions, and good for mobile interfaces.

Avoid: In minimal interfaces where space is limited, as it can dominate the screen.

Button states

Let’s turn again to Material Design to review the button states: 

1. Normal or default: This is the button's regular state when it's just sitting there, ready to be clicked. It should be visually clear and easy to spot, but it doesn't have any special interaction happening yet. This state is used most of the time when the button is available for action.
2. Disabled: A disabled button looks inactive or faded out. It shows the user that it's not currently clickable, like when a form isn't fully filled out yet. This state is important for guiding users to understand that something else needs to be done before this button can be used.
3. Hovered: The hover state happens when the user moves their cursor over the button without clicking it. It's often highlighted or changes color slightly to show that it’s clickable. This helps the user understand that they can interact with the button.
4. Focused: The focus state shows when the button is selected or highlighted, often through keyboard navigation (like using the Tab key). It usually has an outline or glow around it. This state helps improve accessibility for users who navigate without a mouse. Designers often skip it because developers can easily set it up in the browser console, saving time and effort. 
5. Pressed: This state shows when the button is being actively clicked or tapped. It may appear “pushed in” to visually mimic pressing a real button. It gives immediate feedback that the user’s click is being recognized. This state is part of Material Design, but many designers skip it, as users rarely notice the subtle "pressed" effect. 
6. Progress: The progress state shows when an action triggered by the button is actively being processed and hasn’t finished yet. It often displays a small loading spinner or animation in place of the button’s usual text, letting the user know that something is happening. This state is useful for actions that take a moment to complete, like processing a payment or submitting a form.

Should you avoid inactive buttons in the interface?

By their nature, inactive buttons are designed to restrict user actions, preventing errors, premature form filling, and unnecessary back-and-forths between error messages. They are indeed effective for high-risk actions. For instance, in a financial management system, a disabled “Submit Invoice” button can prevent sending incomplete invoices, safeguarding the business from billing errors.

However, the problem with inactive, or disabled, buttons is that they don't explain why they’re inactive or how users can enable them. Is it due to missing information, an incomplete task, or a system issue? 

Learn to communicate clearly what’s wrong and why the action isn’t possible. As Vitaliy Freedman said, “Communicating that something isn’t possible is as important as preventing users from making costly mistakes.”

Without clear feedback, users are left guessing – retyping data, refreshing pages, or even abandoning the task altogether. A common example is when users re-enter their phone number in different formats (with or without a country code, with or without spaces) only to realize the issue is in a completely different field. 

An alternative to disabled buttons is inline validation, which provides real-time feedback as users move from one input field to another. This works well in simple forms, allowing users to correct mistakes immediately, like entering an invalid email address or leaving fields incomplete.

However, inline validation isn’t always foolproof. For example, an outdated validator might fail to recognize postal addresses, or it might not accept certain email characters. No matter how thorough, you can’t anticipate every use case – something will inevitably be overlooked. 

To make disabled buttons or inline validation more inclusive, follow these recommendations:

• When designing buttons or inline validation, provide clear, actionable feedback with suggestions on how to resolve the issue. For example, add a link button to an FAQ article that addresses common problems or to a community forum, placed next to the inactive button. Additionally, you might add a tooltip with an explanation that appears when hovering over an incorrect field or an inactive button. 
• Ensure users can contact support without losing their progress if possible.
• If possible, allow users to continue despite validation problems. If there's a typo in the address, prompt the user to double-check it. If they choose to proceed, display a message notifying them that support may follow up for clarification. While it might lead to errors in the database, it's an effective way to lower the abandonment rate.

Here’s an excellent explanation by Vitaliy Freedman, featuring examples from his work—we highly recommend checking it out.

Keep exploring: Usability Pitfalls of Disabled Buttons, and How To Avoid Them

Button sizes

There’s no single answer to this question, as button sizes can vary depending on the design system in use. Moreover, button sizes can vary across the application, depending on whether you're working with more or less data-heavy interfaces. 

Usually, design systems include: 

• Small buttons: Typically used for secondary or tertiary actions, especially when placed alongside other buttons. For example, a small “Cancel” button in a pop-up.
• Default buttons: The default button size, commonly used for primary actions or calls to action. For example, a “Submit” button on a form.
• Large buttons: Usually reserved for actions that need to draw extra attention, such as prominent calls to action. For example, a “Start” or “Sign Up” button on a landing page. This size of buttons is especially common in mobile apps, where larger touch targets are essential.

Here are some guidelines:

• Small: Minimum height of 32px.
• Default: Height between 40-48px.
• Large: Height of 48px or more.

These sizes apply to both desktop and mobile applications.

How to design buttons for the Thumb Zone?

Follow these guidelines: 

1. For mobile applications, avoid buttons smaller than 32px in height.
2. If you have small elements (e.g., 24px) on a desktop and are designing a responsive version, it's not always necessary to enlarge them. Avoid creating extra variants for developers unless you have the time, budget, and a clear understanding of each component's purpose. Users can increase the interface size through browser settings, which will automatically scale all elements.
3. If you have 1-2 key actions, use full-length buttons. This works well regardless of which hand the user is using to hold the phone.
4. Adapt the interface based on the target market. For Arabic, mirror the interface, and for systems like CarPlay or Android Auto, place the primary button closer to the driver's side to accommodate their position.
5. If possible, gather information about your users. Older adults or users with larger thumbs may have difficulty interacting with small buttons. For these users, consider making the primary elements slightly larger.
6. Allow button size for mobile to adjust according to the user's phone settings, particularly if larger fonts are enabled.

Button spacing 

Again, there’s no definite answer for what the ideal button spacing should be—it depends on the type of product. The more data on the screen, the less space you have, so buttons will need to be closer together. When there’s more space available, you can afford to increase the spacing between buttons.

Another factor is aesthetics and user convenience. Buttons should look visually appealing, and users should feel comfortable tapping on them without accidentally hitting the wrong button or struggling to reach them with their thumbs.

According to the study Touch Screen User Interfaces for Older Adults: Button Size and Spacing, when mobile buttons were spaced too far apart, it took users longer to reach the target. On the other hand, when buttons were too close together, their touch accuracy dropped. In other words, they were more likely to tap on the wrong button. 

The first factor—aesthetics—is subjective. The second—user comfort—can be evaluated by observing how users interact with the application and asking them for feedback.

Moreover, you can have different spacing within the same screen. For example, take a look at Jira.

Button width and padding 

Button width and padding also depend on the type of application and device.

In mobile applications, you can choose between smaller buttons or full-width buttons, which span the entire container. Full-width buttons are often a better choice as they increase the tappable area.

If you have two buttons, they can be placed side by side, covering the full width of the container, or stacked vertically with the primary button on top.

For more than two buttons, stacking them vertically is possible but can overwhelm the user. In such cases, it's better to keep the primary button visible and a three-dot menu for additional actions.

In desktop applications, button width is typically fixed. When you have multiple buttons, arrange them side by side, not vertically.

The width adjusts according to the text—the longer the text, the wider the button.

Vertical button padding depends on the text size. The main rule here is to have a general size of the button (frame) divisible by 4 or 8 depending on your grid system.

Horizontal padding varies based on the type of product. In data-heavy interfaces, space is limited, so smaller buttons with less horizontal padding are necessary. In cases where you have more space, you can increase the horizontal padding for a cleaner, more polished look.

In mobile applications, increase the tappable area of text buttons by using a larger button container.

Pro tip: Buttons are just one way to represent actions in a product, so use them thoughtfully. Too many buttons on a screen can clutter the visual hierarchy. Try organizing additional actions in a navigation drawer, or use elements like chips, text links, or icon buttons.

❓Questions designers should ask themselves

By asking the right questions, designers can question their decisions, find areas to improve, make sure nothing is overlooked, and reduce mistakes, leading to better, more thoughtful designs.

• What specific type of interface are we designing? Is it data-heavy, task-focused, or communication-oriented?
• Which platforms are we designing for? Is it for mobile, desktop, or tablet?
• Are we designing for both light and dark themes?
• Who are the primary users of this application, and what are their key tasks?

🤝 Credits

Our content combines the knowledge of Cieden’s designers with insights from industry influencers. Big thanks to all the influencers for sharing awesome content!

• UI/UX tips: A guide to creating buttons by Sarah Edwards
• A guide to design buttons for your design system by Raouf Belakhdar
• Buttons by Material Design
• Button Design — UI component series by Taras Bakusevych
• Usability Pitfalls of Disabled Buttons, and How To Avoid Them by Vitaly Friedman
• Best Practices for Designing UI Buttons by UXcel
• 8 Rules for Perfect Button Design by Dorjan Vulaj

📚 Keep exploring 

Explore the design systems of other products to gather inspiration and insights. For example: 

• Uber base design system 
• Tailwind design system