Skip to main content

Designing Button States

By Tyler Sticka

Published on March 13th, 2018


Buttons are a staple of any design system. The best ones are simple, versatile, maybe even a little fun. But there’s a lot of hidden complexity in these jolly, candylike controls and toggles… complexity that’s easy to overlook when we focus on the same old default and hover states in our designs.

Mockup of a default button, a button with a hover effect, and a mystery button state

In truth, mouse effects are probably the least important state to design for. By accounting for more functional states early, you can lower the need for costly redesigns as your pattern library matures.

Here are the fundamental states you should address early on, in approximate order of importance.

Perhaps unsurprisingly, the standard button appearance is really important. Make it too prominent or too reserved and you’ll see it become underused across your projects without modifier classes or alternative styles.

Mockup of buttons in descending order of prominence

It’s also important to design buttons in some sort of context. One common mistake is to choose a button style that isn’t differentiated enough from input fields, which can make forms confusing to navigate.

Mockup of a button that could be confused for an input

It’s also important to choose colors with adequate contrast for most users. I use the Contrast app to test my designs for WCAG 2.0 compliance:

Mockup of buttons with varying contrast ratios

The most important state to account for is :focus. Without it, navigation via keyboards or other directional input devices is virtually impossible. The good news is that browsers already include a solution by default, typically a dotted outline or blue glow:

Examples of default focus outlines in Edge, Firefox and Chrome

These outlines can sometimes feel inconsistent with a project’s visual styles, which is why they’re frequently disabled… leaving many users in the dark. So let’s all raise a hand and repeat after me:

“I do solemnly swear never to disable browser focus styles without including a thoughtfully designed replacement.”

Good job! With that out of the way, here’s what to keep in mind when designing a custom focus style:

  1. In a group of buttons, the focused one should be easy to spot.
  2. It should not rely entirely on color and value changes, which can be difficult for some users to identify.
  3. Ideally, it should be flexible enough to work across many button styles without frequent overrides.
Mockup of good and bad focus designs juxtaposed with other button states

While it may seem a far-off possibility in the early days of a design system, it’s very likely that at some point you’ll need buttons that act as toggles: Opening and closing menus, toggling a like/favorite/bookmark, switching tabs, etc. Considering this possibility early helps avoid potential conflicts with other button states down the line.

An expanded button design can vary a lot per project. You may even need more than one. The important considerations are that the “on” and “off” states are distinguishable from one another, and that it cooperate well with your focus styles.

Mockup of various solutions for expanded states

Like focus and expanded states, disabled buttons should be easy to identify. Unlike those states, it should not stand out from the crowd. The disabled state should feel muted, inert, dull.

One of the most popular methods of styling disabled buttons is to lower their opacity. This works well for buttons with the same default style, but less so when a disabled button has more saturated colors than its neighbor. A combination of opacity and desaturation can do the trick:

Mockup of disabled states and their effects on different button styles

Okay, I know it’s a drag waiting this long to design these states. But there are at least two really solid arguments for holding off:

  1. These states will only apply to some users and input types. Not everyone uses a mouse, not everyone uses their fingers.
  2. It’s way, way more fun to design these states with awareness of everything else.

Having waited, we now know which effects would overlap with other states:

Mockup of good and bad hover states when juxtaposed with expanded buttons

We also know enough to gracefully transition between and reinforce these states via color, scale and animation:

Animation of button states changing based on mouse interactions

This is by no means an exhaustive list of considerations for designing resilient, extensible button patterns in a design system (for that, I recommend reading Nathan Curtis’s Buttons in Design Systems). It’s merely a call for designers to re-prioritize the button states they explore early on.

Next time you pop open your editor or design app of choice, consider holding off on that hover state till you’ve defined more essential states like focus, expanded and disabled. It might make all your button interactions that much more useful and delightful.


Patrick H. Lauke said:

One tiny addendum for the hover/active example: for the on/off toggle scenario, you probably want to consider designing two separate states – off and hovered, on and hovered (and the same applies to focus styles of course – off and focused, on and focused).

Eman Emantsal said:

Something not mentioned here, but should be considered is thought for those with color blindness. Changes of state should not be indicated solely by change of color, especially for state such as disabled, selected, on, etc.. Take the On/Off toggle for example – A common indication may be green for on and red for off. Great for those with ‘normal’ vision but if you suffer from red/green color blindness the two states are almost completely indistinguishable.

Jochen Wolters said:

It’s always nice to see articles like this that cover the very fundamentals of interaction design. This is a great read, Tyler!

There’s one detail, however, that I’d like to discuss further, and that’s the use of regular buttons — with their well-established appearance and behavior — for anything but triggering an action like “Print” or “Save.”

We’ve had dedicated widgets for state toggles and menus since the beginning of “GUI time,” 😉 so why should designers unnecessarily increase the cognitive load for their users by using, say, a regular push button in place of a checkbox?

Just to clarify, I have not seen any issues with toggle buttons that have a non-standard appearance, like a heart-shaped button for “liking” a tweet, or a flag icon for flagging an email message.

Using a default button without any additional embellishments for this purpose, though, breaks UI consistency, and does so, IMHO, without gaining any benefits.

Do you agree, Tyler? If not, what am I missing? 😉