Actionable language

Headings and subheadings are titles and subtitles that refer to sections of the interface.

Basic structure

Headings and subheadings should be:

• Informative and descriptive:

  • Highlight the most important concept or piece of information for merchants
  • Help merchants understand what they’ll find in the section below

• Concise and scannable:

  • Use simple, clear language
  • Keep headings to a single sentence
  • Avoid using punctuation such as periods, commas, or semicolons
  • Write in sentence case (capitalize the first word and proper nouns only)

Articles

Whether or not to use articles (“the,” “a,” “an”) in headings and subheadings depends on the type of message.

Conversational headings

For more conversational areas of the product, like Home cards, sell pages, and empty states, use articles. It makes the language more approachable and helps people to understand new, complex concepts.

Microcopy headings

For labels, titles, and microcopy, avoid articles to keep content short and actionable. This increases readability and encourages immediate action.

Start sentences with imperative verbs when telling merchants what actions they can take (especially when introducing something new).

When a merchant reads a sentence that starts with an imperative verb it should sound like they’re being instructed what to do. Don’t use permissive language like “you can.”

Buttons need to be clear and predictable. Merchants should be able to anticipate what will happen when they select a button. Never mislead someone by mislabeling a button.

Buttons should always lead with a strong verb that encourages action. To provide enough context to merchants, use the {verb} + {noun} content formula on buttons except in the case of common actions like “Done,” “Close,” “Cancel,” or “OK.”

Always write button text in sentence case, which means the first word is capitalized and the rest are lowercase (unless a term is a proper noun).

Avoid unnecessary words and articles such as “the,” “an,” or “a.”

Links need to be clear and predictable. Merchants should be able to anticipate what will happen when they select a link. Never mislead someone by mislabeling a link.

Links should never use “click here” or “here” as link text.

Links in a sentence

Links in full sentences shouldn’t link the entire sentence, only the text that describes where merchants go when they select the link.

It’s better for internationalization to have only single terms or small parts of phrases linked. Linking a full phrase is problematic because the word order might change, which would break the link into two parts.

Links outside of a sentence

Links that aren’t in full sentences should use the {verb + noun} pattern and not be punctuated, with the exception of question marks.

Confirmations are presented for actions that can’t be undone or are difficult to undo.

Confirmation messages should:

• Always give merchants the option to either confirm or cancel their action
• Be used for a single, primary task
• Keep body content to one line of text and not use more than two calls to action

Confirmation titles should:

• Ask if merchants want to continue, using a concise {verb}+{noun} question
• Be one sentence and avoid using punctuation, with the exception of question marks
• Avoid articles (the, a, an) to keep content short and actionable
• Be written in sentence case (the first word is capitalized, and the rest is lowercase)

Confirmation body content should:

• Clearly explain if the action is irreversible or difficult to undo, using plain language.
• Be concise: use only one line of text. Don’t start the sentence with “Are you sure?”

Confirmation primary and secondary actions should:

• Be clear and predictable: merchants should be able to anticipate what will happen when they click a button
• Scannable: avoid unnecessary words and articles such as “the,” “an,” or “a”

Since confirmation messages are placed in modals, the call to action in the title is in close context to the buttons. Because of this, the call to action text on the buttons doesn’t have to follow the {verb}+{noun} pattern. Instead, one word calls to action can be used, for example, [Cancel] [Delete].

Deletions

Before merchants can delete objects like collections, transfers, products, and variants, we present them with a confirmation message that has two calls to action, one to [Cancel] and one to [Delete]. We keep it short and don’t use {verb}+{noun} button copy.

Primary action:

Secondary action:

Discarding changes while on a page

Primary action:

Secondary action:

Leaving a page with unsaved changes

Primary action:

Secondary action:

In the same way that links should never say “click here,” avoid using directional language such as “above/below” or “right/left.”

Directional language is confusing and unhelpful when spoken aloud by a screen reader. It creates challenges for internationalization (for example, right to left languages) and can conflict with mobile design patterns.

Directional language often indicates a lack of visual or content hierarchy. Whenever possible, keep instructional copy and related actions close together so that directional language isn’t needed.

Use “Save” when a change is saved immediately to a database and “Done” for deferred saves.

Saving immediately to a database

Use “Save” for web and iOS as the default for any action that saves immediately to a database. For Android, use a check mark.

Saving using the context bar component

When merchants make changes on a page they’re sometimes presented with a context bar at the top. This context bar displays a status message on the left to indicate the state of the changes, like “Unsaved discount.” Since the status message provides context around the action being taken, the button doesn’t need to follow the common {verb} + {noun} content formula. For example, [Save] instead of [Save product]. In the context bar component, use the verb “Save” for web and iOS, and a check mark in Android.

Status messages in the context bar should be descriptive and follow the {adjective} + {noun} content formula.

Saving in modals and sheets

For web and iOS, use the verb “Save” in modals and sheets when saving directly to the database. For Android, use a check mark to indicate “Save.”

Saving at the bottom of a page in web

Use the {Save} + {noun} content formula when a save action doesn’t have the surrounding context of a modal or context bar. This applies to the save action at the bottom of pages in web.

For example, the action at the bottom of the Create discount page in web uses [Save discount]:

Deferred saves

Sometimes, when merchants confirm a set of changes inside a modal or sheet, these changes are applied as unsaved changes to the current page. In other words, the changes made weren’t immediately saved to the database. When this happens, don’t use the verb “Save” as the call to action because it would be misleading.

Use the adjective “Done” in web, Android, and iOS for deferred saves. When the modal or sheet closes, then merchants can save all of the changes they made.

Most deferred saves happen when confirming changes in Add, Edit, Manage, and Select modals and sheets.

Datepickers

Use the adjective “Done” in web, Android, and iOS for datepickers.

Use the adjective “OK” when merchants need to confirm they’ve read something, but aren’t required to legally accept terms of service before continuing. For example, use “OK” when presenting a security notification in a modal or sheet.

Use the adjective “Accept” when terms of service require legal confirmation before merchants can continue.

Use the back arrow button in web, “Close” in iOS, and an “X” in Android, as the call to action for modals and screens when:

• the content is in a view-only state

Don’t use “Close” as the call to action when there’s the option for merchants to:

• make any changes to the modal or screen
• confirm they’ve read something or accept terms of service (see OK vs. accept)

Use “Cancel” as the option for merchants to back out of any changes made on a page, modal, or sheet. When the cancel button is pressed, changes automatically get discarded. “Cancel” is often paired with “Save” and “Done” actions (and is always placed to the left).

Use the verb “select”:

• When telling merchants to pick something from a limited number of options of the same kind
• When merchants need to make an easy or obvious decision that doesn’t require deep reflection or analysis
• For defined lists and dropdown menus
• When merchants are given the option to pick from a list of already existing objects, like products

Pair Select modals and screens with the “Done” call to action.

Use the verb “choose” when:

• Encouraging merchants to make a decision that is more subjective, strategic, emotional, or open-ended
• Merchants have to pick from a large inventory of items, like themes, or options that require strategic decision making, like pricing plans

Use the verb “edit” when you can change the input of a field (letters, numbers, properties). Place as link text next to the field or area that is being edited. There’s no need for a noun unless it’s unclear what’s being edited.

Use the verb “manage” at a higher level to convey that multiple actions can be done, or sections and settings can be updated. Pair this verb with a noun if it’s in a button or if it’s unclear what is being managed.

Use the verb “change” when merchants can replace an option, but not edit it. For example, they can change an image or theme, but the action doesn’t include editing its properties. Place as link text next to the field or area that is being changed. There’s no need for a noun unless it’s unclear what is being changed.

Use the verb “switch” when it’s important for merchants to know what they’re switching between, like users, accounts, locations, or modes. When the switch happens, the previous option is turned off, logged out, or deactivated. Always pair with a noun to prevent confusion.

Use the verb “create” when you’re encouraging merchants to generate something from scratch, like a collection.

Use the verb “add” when you’re encouraging merchants to bring something that already exists into Shopify, like a product.

Use the verb “view” when you’re encouraging merchants to go to a specific page or section for more details, or to reveal more information. Use “view” in buttons, calls to action, and link text.

Use the verb “see” in more general, conversational descriptions without a specific call to action.

Use the verb “need” when you’re telling merchants something they’re required to do or should do.

Use “export” as the call to action when merchants needs to transfer data from Shopify and convert it into a different format.

Use “download” as the call to action when merchants need to copy data (of the same format) from Shopify to a computer system.

Use “import” as the call to action when merchants need to transfer data and convert it into a different format so it can be used in Shopify.

Use “upload” as the call to action when merchants need to copy data of the same format from a computer system into Shopify.