NordSecurity.Design

Button

Overview

  • Buttons communicate actions that users can take.
  • Use style — not size — to visually distinguish the preferred choice among multiple options.
  • Use a filled button for the most likely action in a section or view.

Anatomy

  1. Container
  2. Icon
  3. Text

Variants & States

Variant

Our button types follow our semantic mapping of the color the button represents.

Style

All Buttons have three levels of emphasis. The hierarchy is the following filled, outline, transparent. The higher in the hierarchy the style is the more attention it will bring to the button.

Size

Size can be used to emphasize or deemphasize a buttons hierarchy. Our default size is the md size. Button sizes do not change on different breakpoints and stay consistent.

darkMode

Some of the buttons have a different visual appearance if they are placed on a dark background. For cases where this is needed we have the reversed property that needs to be applied.

States

The button states are named after their css pseudo-class.

Hover is activated when the user interacts with an element with a pointing device, but does not necessarily activate it. 

Active state represents a button that is being activated by the user by clicking on it.

The focus state is globally defined, no special adjustment is made on this component.

Disabled is if the button can’t be activated (clicked on) or accept focus.

Icon

In rare cases an optional icon can be added to the button. The icon should always support and reflect the action and text the button has. On lg and md button sizes we are using md icon sizes with a light stroke style while the sm button uses sm icon size and a regular style for easier readability on the smaller scale .

Internationalization

For RTL (right-to-left) languages, the layout of the button is mirrored.

Writing Guidelines

Buttons are designed to guide users to take specific actions. The text on a button should be concise, clear, and action-oriented. Be descriptive in your button labels and keep screenreaders in mind.

Character Limit recommendations:

While it might be daunting to rather write longer button copy than shorter, we should be aware that our buttons need to fit on a multitude of devices and screens and multiple line breaks in the button label copy will induce reading difficulty.

Maximum: 40 characters

Recommendation: ~27 characters

Usage

All eyes on you, CTA! Stakes are high because this is the copy for the component that prompts action. Even though it feels like it’s really hard to get this one wrong here are some tips with examples.

Do
Use active verbs. If the user only reads the button copy, they should understand what’s needed to do.
Don’t
Do
Use normal case. Even though some may consider that the title case will draw more attention, you’re not adding much sense or significance by capitalizing all the other words except for the first one. Besides, our corporate style guide says so.
Don’t
Do
Forget about punctuation — you don’t need a period ever. And you’d rarely want to yell with an exclamation mark. Question marks are fine though.
Don’t
Do
The fewer words the better, cut down as much as you can for it to make sense. Having up to three words is totally fine, ideally, it would be just one or two. Mind the localization team’s efforts — they’ll be having a hard time fitting in that phrase in German or Indonesian. And… a two-lined button never looks nice, if your copy is too long.
Don’t
Do
To make the button copy to be concise, eliminate the articles where possible.
Don’t
Do
Sound clear and humane. Avoid overly technical or complicated jargon that users will have trouble understanding
Don’t
Do
For the button to be concise and make sense, allow the copy that directly relates to the button to be informative and useful.
Don’t

Accessibility 

Keep screen readers in mind. 

For instance, hearing “get plan” several times about different plans the visually impaired user might get confused. It will be helpful to sound specific and clear.

✅ Do —

❌ Don’t —

Localization 

The phrase’s length should be prioritized over preciseness. Translators don’t have to be literal, they can go creative while sticking to the point and keeping the phrase short.

In this instance for the Ukrainian language, we could go with “Buy Ultra”, etc. The literal translation that is currently used is “Get plan Ultra,” but “get” in Ukrainian is quite long and “buy” is shorter, and it still looks clear if you take away the word “plan.” Then button copy would fit into one row, and it would look nice and fit the guidelines without losing any value.

✅ Do —

❌ Don’t —

Accessibility

Accessibility

Keep screen readers in mind. 

For instance, hearing “get plan” several times about different plans the visually impaired user might get confused. It will be helpful to sound specific and clear.

✅ Do —

❌ Don’t —

Properties

Name Type Values Description
variant String critical
accent
neutral
appearance String fill
outline
transparent
size String lg
md
sm
darkMode Boolean true
false
disabled Boolean true
false
isFullWidth Bolean true
false		 Enables the button to switch from content wide to container wide width.

Usage Guidelines

DoOnly use the critical variant of the button for business and journey critical actions like brining the user to the pricing page.
Don’tDon't use the accent button variant for critical actions.
DoUse the provided component and variants from the system.
Don’tAdjust border-radius, colors or other properties on your own.
DoKeep the button copy short and in line with the writing guidelines
Don’tNever use longer copy and try to avoid having two lines in the button (at least on bigger breakpoints).
DoWhen you have multiple buttons use only one fill button to mark the most important action clearly
Don’tUse multiple fill buttons beside each other, whenever the user needs to choose one of them.
DoWhen having mutliple buttons beside each other keep the secondary action in the same variant as the primary one.
Don’tMix critical and accent fill buttons beside each other.
DoWhen you have multiple buttons use styling to differentiate between them and create a clear hierarchy.
Don’tever use size — to visually distinguish the preferred choice among multiple options.
DoOnly have one fill button per section to mark it clearly as the most important action that the user needs to take here.
Don’tDon't complicate the decision making and journey of the user by not having clear hierarchy.
DoUse active verbs. If the user only reads the button copy, they should understand what’s needed to do.
DoUse normal case. Even though some may consider that the title case will draw more attention, you’re not adding much sense or significance by capitalizing all the other words except for the first one. Besides, our corporate style guide says so.
DoForget about punctuation — you don’t need a period ever. And you’d rarely want to yell with an exclamation mark. Question marks are fine though.
DoThe fewer words the better, cut down as much as you can for it to make sense. Having up to three words is totally fine, ideally, it would be just one or two. Mind the localization team’s efforts — they’ll be having a hard time fitting in that phrase in German or Indonesian. And… a two-lined button never looks nice, if your copy is too long.
DoTo make the button copy to be concise, eliminate the articles where possible.
DoSound clear and humane. Avoid overly technical or complicated jargon that users will have trouble understanding
DoFor the button to be concise and make sense, allow the copy that directly relates to the button to be informative and useful.

Content Guidelines

Buttons are how users trigger an immediate action or move to a new experience. They’re a primary way users interact with our product.

Voice and tone

We aim for an encouraging and action-oriented tone.

Copy

  • We always start with a strong verb.
  • We keep it concise, aiming for 1-3 words.
  • We make sure the label clearly communicates what will happen after clicking.
  • We use sentence case in product UI (apps + Nord Account) because it fits UX norms, supports readability, and matches how users scan interactive UI.
  • We use title case in web/marketing writing (landing pages, blog CTAs, and promotional content, etc.) where visual emphasis takes priority.
  • We don’t use punctuation marks at the end.
  • We avoid unnecessary articles like “the,” “an,” or “a”.
  • We follow the common “Verb + Noun” pattern if possible.
DoLog in
Don’tReconnect to the VPN now.

Accessibility

  • We ensure that the button text clearly and concisely describes the action that will occur when the button is clicked.
  • For buttons without visible text, we provide a descriptive text to ensure the announcement is the action name (for example, “Search”), not a description of the visual icon.
  • Buttons must be reachable via standard navigation. We ensure disabled buttons are not focusable by the keyboard, as focusing an un-interactable element can be confusing. We ensure that the disabled state is communicated for screen readers to announce that the button is unavailable or dimmed.
  • We provide a brief, visible explanation near the button detailing why the button is currently disabled (for example, “Please accept the terms to continue”). This provides context for all users, including those using screen readers.
DoIcon button: Search countries, cities, or servers. Edit box.
Don’tIcon button: Magnifying glass.