CTA Button

Highlight the next best action in a flow.

Cover - Call to action button



FYQ2 target

♼ Care

Figma component




First, we must understand the most important action within a specific region to guide the user on what step to take next. Our hierarchy emphasizes the next best action over anything else with Primary, so it’s easier to scan and allows people to take that action immediately.

When we suggest people do something meaningful that allows them to move forward in a flow, we don’t want other things to get in the way. Hence, CTA Buttons always go alone and are displayed at the end of the context. Alternatively, we can show an opposite or complementary action next to it to give people a way out, letting them do nothing, dismiss, or skip. These opposite actions use the Tertiary emphasis level.


If the buttons were a conversation with the user, a CTA would be the equivalent of telling them, “This is the next best action to take”. If we tell them, “This is the next best action to take… but you can also do this, this, and this”, our recommendation becomes pointless. For that purpose, use the Action Button instead.

As CTA Buttons are always unique, they’ll never need an icon to reinforce their label.

Related components

How to use

⛔️ Avoid high emphasis combinations

⛔️ Avoid high emphasis combinations

Primary CTAs should be unique to stand out from the rest and don't come at the secondary emphasis level. Action buttons have a different purpose.

✅ Combine Primary with Tertiary CTAs

✅ Combine Primary with Tertiary CTAs

Tertiary CTAs make the perfect companion in terms of emphasis. Opposite or complementary actions shouldn't steal the next best action protagonism.

⛔️ Avoid using Tertiary CTAs alone for actions that aren‘t dismissive or complimentary

⛔️ Avoid using Tertiary CTAs alone for actions that aren‘t dismissive or complimentary

Tertiary actions can go unnoticed when used standalone.

✅ Consider Primary CTA or Secondary Action

✅ Consider Primary CTA or Secondary Action

Depending on the context and purpose of the screen, these actions call for the necessary attention and are easier to scan.

Quality checklist

This component passes the following requirements described in our Component lifecycle:



α · Design tokens

It uses Ariane design tokens.

α · Official assets

It uses the official Ariane assets (e.g., icons and illustrations) in one of the official sizes.

α · Accessible use of color

Its color contrast ratio is at least 4.5:1 for text and interactive areas.

α · Target areas

Its interactive target areas are large enough for users to accurately select them, following the Fitts law.

α · Naming agreement

Its name is agreed upon and shared between design and development.

α · Responsive L1

Is responsive to different viewport sizes.

α · User-triggered states

If the component is interactive, all its possible user-triggered interactive states are defined.

β · Responsive L2

The responsive behavior has been reviewed and validated by the team.

β · State properties

All the possible state attributes are defined.

β · Docs L1

It has essential documentation with at least primary usage.

β · Use cases

All the uses are audited and refined.

RC · Definition agreement

Its naming and properties are audited and aligned in design and code.

RC · Accessible L1

Its accessibility is manually audited, and any significant issues are fixed.

RC · Docs L2

The documentation covers the most common use cases and is expected to be iterated during the Release Candidate phase.

RC · Storybook

Includes a Storybook playground of the component.

Stable · Stable API

The component and its API remain stable, with no breaking changes for at least one month.

Stable · Adaptive

Supports adaptive design via preference queries.

Stable · Docs L3

Detailed documentation exists for design, content, accessibility, and implementation, including do’s and dont’s.

Stable · Tooling

Tooling (such as linters, codemods, etc.) exists to help with migrations and prevent further use of alternatives.