Button

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to perform an action, such as saving or opening a component. Clearly define the expected result.

What to draw

Show default, hover, pressed, and keyboard focus states. If a disabled state exists, make the unavailable action clear.

How it behaves

Click, touch, Enter, and Space trigger the action. The person receives perceptible feedback that the button was activated.

What to document in Figma

Record each button’s purpose, the action result, and disabled behavior. If it opens or closes another component, document how that state will be communicated.

How to review

Does the text explain the action unambiguously? Are states distinguishable? Does the touch area work on small screens? Is keyboard focus visible? Activation and announcement as a button need implementation checks.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Button.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before interacting, can you visually tell that the component is actionable?
Before interacting, can you identify that an action will be performed on the same screen? (See "Considerations")
For a disabled button, can you visually tell that the component is not actionable?

Designing for mouse use (any pointing device)

Is there visual feedback when hovering over the component?
Is there visual feedback when clicking the component?
Does clicking the component trigger its corresponding action?

Designing for gesture use

Is there visual feedback when activating the component?
Does activating the component trigger its corresponding action?

Designing for keyboard use (any non-pointing device)

Is there visual feedback when focusing the component?
Can you interact with the button using the "enter" key and the "Space"?
When activated by keyboard, does the button trigger something on the same screen or perform a concrete action?
For a disabled button, is keyboard navigation prevented?

Designing for screen reader use

When focusing a button, can you hear that it really is a button rather than a link?
When focusing a button, can you clearly hear its purpose?
When a page displays multiple buttons, can you clearly identify each button's purpose without ambiguity?

Interaction methods

Possible interaction methods for components of type Button.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

On hover, the component should provide visual feedback confirming that interaction is possible.
On a mouse click, the component should provide visual feedback confirming the click.
On a mouse click, the action should execute.

Keyboard interaction (any non-pointing device)

When focused with the keyboard, the component should provide visual feedback with a visible focus indicator.
It should be possible to activate buttons with the ENTER or Space.

Keyboard (or gesture) interaction + screen reader

When focusing a button, you can hear that it is a button.
When focusing a button, you should be able to clearly identify its purpose.
On screens with multiple buttons, you should be able to clearly identify each one's purpose.
After pressing the "enter" or "Space" key, you can identify that the action was performed.
For buttons that trigger menus or hidden components, when focusing you can identify the component's state, for example open or closed.
For buttons that trigger menus or hidden components, after activation you can identify the component's state, for example open or closed.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing buttons

Keyboard navigation

WHEN I use the Tab key to move focus to an enabled button
The focus I SEE is strongly indicated visually
THEN, when I use Enter or Space to activate the button
I SEE the corresponding action performed
AND, when the button is disabled, I SEE that it does not receive keyboard focus or perform an action

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to a button
- I HEAR that the component is identified as a button.
- I HEAR an accessible name clearly describing the button's action.
- I HEAR the button's state when it triggers hidden components, such as open or closed.
THEN, when I use Enter or Space to activate the button
I HEAR or perceive that the action was performed.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus a button, the following happens:
- I HEAR that the component is identified as a button.
- I HEAR an accessible name clearly describing the button's action.
- I HEAR the button's state when it triggers hidden components, such as open or closed.
THEN, when I double-tap to activate the button
I HEAR or perceive that the action was performed.

Considerations

Considerations for components of type Button.

Buttons should behave as buttons rather than links.
Buttons may look like links, but if they perform an action on the current screen, that is button behavior and they should be implemented as buttons.
Disabled buttons should not receive keyboard focus. A useful but optional practice is to design actions that help people, such as displaying a message explaining what they need to do to enable the button.

References

Additional references for components of type Button.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.