Understanding button states in UI design

Think about the last time you clicked a button and immediately knew it worked. It might’ve been a slight color shift, a brief spinner, or a checkmark. Each of those micro-moments is a button state. Together, they’re what make an interaction feel like it’s working.

Designing them well means thinking through every possible condition a button can be in, across every screen. That includes what happens when a payment fails, a file upload stalls, or an action isn’t available yet. This guide covers what you need to build and document button states that work for every user.

Read on to learn:

• Why button states are important
• Main types of button states and what they mean
• How to use state diagrams for app screen mapping
• How to build interactive states in Figma
• How to code button states with CSS
• Best practices and common mistakes in button state design
• Frequently asked questions about button states

Why are button states important?

Button states keep users oriented by signaling what’s clickable, what’s processing, and what’s complete. When they’re consistent, users build trust quickly because the product behaves as expected.

That consistency becomes even more important as user interfaces (UI) grow in complexity. Most products span dozens of screens, each with buttons that can exist in multiple states at once. Mapping how those states trigger different outcomes lets you catch logic gaps before they become user complaints.

Button states vs. button styles vs. button types

Type, style, and state each describe a different dimension of UI buttons. Keeping them straight matters when you’re building a consistent design system.

• Button type: the functional role of a button. Examples include submit, reset, toggle, and call-to-action buttons like “Get started” or “Buy now.”
• Button style: the visual hierarchy of a button. Primary buttons command the most attention; secondary, ghost, and outlined styles are progressively more subdued.
• Button state: the interactive condition of a button at a given moment. A primary “Submit” button can be in a default, hover, active, or disabled state without its type or style changing.

Button states in UI design: the 5 core states every design system needs

Every design system needs at least five button states to cover the full range of user interactions. These are the states users encounter most often, and without all five, your interface will have gaps in feedback that erode trust. Here’s how they break down.

Default

The default state (also known as enabled, idle, or normal) is what users see before they’ve interacted with a button. It’s the baseline, the visual from which all other states derive. At rest, a button should clearly indicate it’s clickable without any additional context or instructions.

That means getting the fundamentals right: sufficient color contrast, a shape and size that reads as interactive, and a label that tells users exactly what will happen when they click. A default button that looks like plain text or a decorative element will confuse users before the interaction even begins.

Hover

The hover state activates when a user moves their cursor over a button, confirming that it’s interactive before they click. Hover states are a small but meaningful moment of feedback—the interface acknowledging that it sees the user’s intent.

The key word here is subtle. A slight darkening of the background, a gentle shadow lift, or a minor border change is all it takes. Overdoing it—dramatic color swaps, heavy motion—can feel jarring and pull attention away from the task.

Active

The active state (also known as pressed) fires the moment a user clicks or taps a button. It’s the briefest of all the states, lasting only as long as the click itself, but it carries a lot of weight. Users expect immediate confirmation that their input has been registered, and the active state delivers that with a subtle visual response.

A slight darkening of the fill, a small scale-down, or an inset shadow all work well here. The goal is to mimic the physical sensation of pressing something, giving users the tactile feedback they’re looking for, even on a flat screen.

Focus

The focus state appears when a user navigates to a button using their keyboard, typically via the Tab key. It’s the visual indicator that says “you’re here” for anyone who isn’t using a mouse.

WCAG 2.2 requires focus indicators to meet minimum size and contrast thresholds, so a clearly visible focus ring is a non-negotiable for accessible design. Make it visible, keep it consistent, and never suppress it with outline: none without providing a custom alternative.

Disabled

The disabled state signals that a button exists but isn’t available right now. Visually, that typically means a muted fill, reduced opacity, and a not-allowed cursor on hover. The button stays visible so users know the action is possible—just not yet.

Striking the right balance matters here. Too subtle, and users will keep trying to click it. Too heavy-handed, and the feature feels hidden. Pairing a disabled button with a tooltip or inline message helps keep users oriented.

Functional button states for complex user flows

The five core states cover the basics, but real user flows are rarely that clean. A checkout process or a form submission can have multiple possible outcomes, each with a corresponding button state. Functional states handle those in-between moments and edge cases, communicating system status where it matters most.

Loading button state

The loading state activates after a user clicks a button, and the system needs time to respond. Without it, users can’t tell whether their action was registered or whether they should click again.

Choosing between a spinner and a progress bar depends on the wait time. Spinners work well for short, indeterminate processes, like authenticating a login or submitting a form. Progress bars are better for longer operations where you can measure progress, like a file upload or a bulk data export. In both cases, the button should be disabled during loading to prevent duplicate submissions.

Success/complete button state

The success state confirms that an action was completed as expected. It’s a moment of closure, and it should feel immediate and unambiguous.

A green fill paired with a checkmark icon is the most universally understood signal for a positive outcome. Keep the animation brief and the messaging clear. “Saved,” “Sent,” or “Done” lands better than a generic “Success.”

Error button state

The error state signals that something went wrong. Like the success state, it uses color and iconography to communicate the outcome. A red fill or border paired with a warning icon draws on widely recognized color symbolism.

Recovery UX is where most error states fall short. The button should reset to a clickable state so users can try again, paired with a clear inline message explaining what went wrong and what to do next. “Payment failed. Check your card details and try again” is far more useful than a red button with no context.

Selected or toggled button state

The selected state indicates that a button is actively toggled on. Unlike the other states, it stays on until the user turns it off, making it the right pattern for toggle buttons, filters, and segmented controls.

A filled or inverted style works well here to distinguish it clearly from the default state. If the meaning of a toggle isn’t immediately obvious from the label or icon alone, a tooltip on state change helps. Consider adding one when:

• The button’s icon changes between states
• The action is irreversible or hard to undo
• The toggle affects something outside the user’s immediate view

How to use state diagrams for app screen mapping

Most design work starts with the happy path, the ideal sequence of steps a user takes to complete an action. But users don’t always follow the happy path. App screen mapping is the practice of visualizing every possible route through an interface, including detours, dead ends, and edge cases.

UX state diagrams are a type of flowchart that makes the logic explicit. Mapping out every button state and the screen outcome it triggers helps designers and developers align on the answers to questions like: what happens if a payment fails? Does the button reset? Does an error message appear? Getting those answers documented before development starts prevents a lot of rework.

The process involves “exploding” a screen into multiple variations, one for each possible button state combination. It’s one of the most effective ways to surface edge cases early and make sure every user has a clear path forward, even when something goes wrong.

How button states translate to CSS

CSS buttons are controlled through a combination of native pseudo-classes and custom classes, each mapping to a specific button state. Together, they keep your UI and your code in sync.

Here’s a starter snippet covering the essentials:

Each pseudo-class maps to a specific interaction trigger, and knowing when each one fires is key to implementing button states correctly in CSS. Some behave differently across devices, and a couple have important accessibility implications worth calling out:

Accessibility and usability best practices for button states

WCAG 2.2 sets the baseline for accessibility in design, and button states are one of the most important places to get it right. Following these standards also tends to produce better usability for everyone, regardless of ability or device.

Here’s what to keep in mind:

• Color contrast: Text on buttons must meet a minimum contrast ratio of 4.5:1 for normal text per WCAG 2.2. This applies to every state, not just the default.
• Don’t rely on color alone: A state change communicated only through color will be invisible to colorblind users. Pair color shifts with icons, border weight changes, or underlines to ensure the message gets through.
• Touch target size: Website buttons on mobile should have a minimum tap target of 44x44 pixels to accommodate different hand sizes and dexterity levels.
• Transition timing: Keep animations between 100ms and 200ms. Slower than that, and the interface feels sluggish; faster, and the feedback is easy to miss.
• Consistency: Every button of the same type should behave the same way across the product. Inconsistent states erode trust and make interfaces harder to learn.

Common mistakes to avoid in button design

Even well-intentioned button designs can create friction if a few key details get overlooked. These are the most common pitfalls to audit in any design system.

• Buttons that don’t look like buttons. Also called mystery meat navigation, this happens when an element only reveals its interactivity on hover. Buttons should be recognizable in their default state through shape, color, or label.
• No visual hierarchy between primary and secondary actions: When primary and secondary buttons look too similar, users hesitate. Give your primary action a clear visual advantage so the right next step is obvious.
• Disabled buttons with no explanation: Graying out a button tells users they can’t proceed, but not why. An inline validation message that explains what’s blocking the action is far more useful.
• Suppressing the focus ring: Removing the default focus indicator without providing a custom alternative cuts off keyboard and assistive technology users entirely.
• Overanimating state transitions: Elaborate hover effects and loading animations can distract users from the task at hand. Transitions should be quick, subtle, and purposeful.

Button states FAQ

Keep reading for answers to frequently asked questions about button states.

Are button states necessary for mobile apps?

Yes, though the set of relevant states looks a bit different on mobile. Hover states don’t exist on touchscreens, so active and loading states carry more weight in communicating feedback. When designing an app, audit your button states for touch interactions to make sure users always know what’s happening after a tap.

How can I test if button states are effective?

Unmoderated usability testing is a good starting point. Heatmaps and click tracking can also surface patterns like rage clicks, which often indicate a button state problem. If users are repeatedly clicking the same element, the loading or disabled state probably isn’t working.

How do you implement button states in CSS?

CSS pseudo-classes like :hover, :active, :focus-visible, and :disabled cover the core button states natively. Functional states like loading and error require custom classes since the browser doesn’t track them automatically. See our full CSS button states breakdown above for a complete code example.

What’s the difference between a button “style” (Primary vs. Secondary) and a button “state”?

A button’s style defines its visual hierarchy, whether it’s a primary, secondary, or ghost button. A button’s state describes its interactive condition at any given moment, like hover, active, or disabled. The same primary button can move through multiple states without its style ever changing.

How to build interactive button states in Figma

Figma Design makes it easy to build a button component that contains every state in one place. Using variants, you can define each state as a separate variant property within the same component set, keeping everything organized and easy to update across the file.

Interactive components take it a step further. You configure the interaction once on the component itself, and it carries through everywhere the button gets used. Boolean properties let you toggle icon or label visibility on and off, while instance swap properties help manage different icon variations without duplicating components.

Once you’re ready to build, here’s how to get started:

1. Create your base button component.
2. Add variants for each state (default, hover, pressed, saved, unsaved).
3. Rename variant properties so they’re clear and consistent.
4. Open the Prototype tab and connect variants using triggers like “While hovering,” “Mouse down,” “Mouse leave,” and “Mouse up.”
5. Set animations to Smart animate at 150ms for transitions that feel responsive without being distracting.

Visit the Figma Help Center for a more detailed step-by-step walkthrough.

Design better interfaces with Figma

Well-designed button states are the difference between an interface that feels polished and one that leaves users guessing. Before your next build, take time to map out full state diagrams to catch logic gaps early, and audit your existing design system for state consistency and accessibility compliance. When you’re ready to put it into practice, we’d love for you to try Figma.

Here’s how to get started:

• Map out UX state diagrams and app screen flows in FigJam before moving into high-fidelity design.
• Turn on Dev Mode to hand off button states to engineers with accurate specs, CSS properties, and component mappings already attached.
• Use Figma Make to prototype and test multi-state button interactions without engineering dependency.