cft

Basic Design System Button States

Designing buttons for multiple use-cases saves everyone time. Make sure your hand-off includes these crucial button states!


user

Scott Oliveri

2 years ago | 3 min read

As I work through my newest design project, I’ve been creating a design system that sets the basic foundation for my visual language. Ensuring that this system is consistent and organized is crucial for when the time comes to hand-off to UI Developers.

Developers won’t always be privy to your client’s intent and the design’s nuance. When they need to create something new that isn’t explicitly designed, it’s important that they have to infer as little as possible. The less information a developer or future designer can access, the less likely new design additions will be true to your original vision.

As someone relatively new to the UX/UI field, I made sure to reach out to a few senior designers to get their input on my fledgling design system. While I was on the right track, I was missing a few basic ingredients, namely, comprehensive button states!

While I had specified various large, small, and long buttons with multiple styles, I only designed “enabled”, “hover”, and “pressed” states. I was missing three additional button states that each design system should include at the bare minimum. I’ll walk you through these states with some example buttons and I’ll also show how you can present the “anatomy” of your design system’s buttons for hand-off.

Enabled State

An outlined and contained variation of the enabled button state.

Ah, the enabled state, or the active/display state. Your simple, go-to visual for a button. This will probably be the first button state you will design and use. It denotes that a button or setting is interactive.

Hovered State

An outlined and contained variation of the hovered button state.

For web applications, where users are usually using a mouse, the hovered state communicates when a user has placed a cursor above an interactive element.

Focused State

An outlined and contained variation of the focused button state, placed on a gray background for increased contrast and emphasis.

The focused state communicates when a user has highlighted an element using a keyboard or voice. Focused states are crucial when designing for accessibility, as screen readers and keyboard navigation relies on focus states for visually impaired or limited mobility users. Focus states apply to all interactive components. They should receive high emphasis, as they are not indicated by other visual cues.

Pressed State

An outlined and contained variation of the pressed button state.

The pressed state communicates a user click, tap, or press. Pressed states usually are denoted through darker colors or inner shadows to skeuomorphically represent that they are depressed, like physical buttons.

Dragged State

An outlined and contained variation of the dragged button state.

The dragged state communicates when a user clicks or presses, and then moves an element. Dragged states can be used when reordering list items or rearranging applications on your smartphone’s home screen. These buttons are usually telegraphed with drop shadows, representing that the button has been lifted and moved “above” the digital screen.

Disabled State

The disabled state communicates when a component or element isn’t interactive. The visuals for a disabled state should be de-emphasized, usually through muted colors, reduced opacity, or reduced elevation. Though understated, a disabled button should still be legible.

Design Hand-off Examples

When finalizing your design system, it’s important to set the rules for creating your UI elements. Buttons as well as sliders, loading bars, and many other useful interface atoms all should follow a consistent rule set and styling. Below you can see a simple hand-off entry for our example enabled button.

Note that specifications such as font, size, color, and padding are specified. Dimensions for the buttons are visually represented. It’s important to detail the width of the button as a variable width. Typically, button width changes based on the text inside of it, so you can assume the width of the button is the padding on each side plus the width of the text.

It’s important to include detailed specifications for buttons with multiple colors and effects like shadows, like the inner shadow on this solid pressed state button shown above.

Buttons are just a small piece of a holistic design system, however, building for multiple use cases and keeping your designs detailed and consistent builds good habits that will save everyone a bit of grief down the road.

Upvote


user
Created by

Scott Oliveri


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles