Vocabulary

Nouns

Dataset vs. data set

Spell “dataset” as one word because it matches the industry spelling used by the Clinical Data Interchange Standards Consortium (CDISC).

Name vs. label vs. title

Use “name” as the default, and when needed, opt for “label”. Avoid “title” to prevent ambiguity, as it can refer to either a name or a role/position. Reserve “title” for English honorifics like Mr. and Mrs. or when mentioning job roles.

Verbs

Select vs. choose vs. click

Use “Select” as the default when:

• instructing users to choose something from a set of options of the same type
• prompting users to make a straightforward decision that doesn’t demand extensive thought or analysis

Avoid “Click” because keyboards and touch screens don’t support this action.

Avoid “Choose” unless you are asking users to make a decision that is more subjective, strategic, emotional, or open-ended, such as themes or pricing plans. When in doubt, use “Select”.

Close vs. accept

Use “Close” when users are expected to acknowledge that they have read a message without legally accepting the terms of service before continuing.

Use “Accept” when users are legally required to acknowledge their acceptance of the terms of service before moving forward.

Avoid using “OK” as it represents an exclamation rather than an action. By clicking the “Close” button, users are not simply saying “OK” but rather performing a distinct action.

Close vs. cancel

Use “Close” or the ”×” button as the call to action for modals and screens when:

• the content is in a view-only state

Avoid “Close” as the call to action when there’s the option for the user to:

• make any changes to the modal or screen
• confirm they’ve read something or accept terms of service

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

Create vs. add

Use “Create” when you’re encouraging users to generate something from scratch in the product, like a project, study, analysis, spec, data package, or user account. This action is commonly associated with actions like “Delete,” “Archive,” and “Activate/Deactivate.”

Pattern impact:

• Buttons:
  • The label should read ”+ Create.”
  • The label should only include the object type when creating from an empty state, indicating it is the first of its kind.
• Modals:
  • The title should be “Create {object type}.”
• Create pages:
  • The title should be “Create {object type}.”
  • The primary action button label should be “Create.”

Use “Add” when prompting users to introduce or associate something that already exists into a specific context, such as adding a dataset to an analysis, adding a user to a team, or adding permissions to a role. The object itself is not being created in that moment (it already exists) but it is being associated. This term is commonly used alongside “Remove.”

For example, a user account is created at the system level, but that user is added to a team.

Pattern impact:

• Buttons:
  • The label should be ”+ Add.”
• Modals:
  • The title should be “Add {object type}.”

This legacy term should be removed from existing pages.

Delete vs. remove

Use “Delete” when prompting users to permanently erase something that was previously created in the product, such as a user account, study, analysis, spec, data package, or dataset. This action is commonly associated with actions like “Create,” “Archive,” and “Activate/Deactivate.”

Pattern impact:

• Buttons:
  • The label should read “Delete.”
• Modals:
  • The title should be “Delete {object type}?”
  • The primary action button label should be “Delete.”
• Pages (if applicable):
  • The title should be “Delete {object type}.”

Use “Remove” when prompting users to detach or unassign something that already exists in the product from a specific context, such as a imported data from an analysis, a user from a team, or permissions from a role. The object continues to exist elsewhere in the product or outside the product. This term is commonly used alongside “Add.”

Pattern impact:

• Buttons:
  • The label should be “Remove.”
• Modals:
  • The title should be “Remove {object type}?”

Archive

Use “Archive” when you’re prompting users to deactivate or retire something that was previously created in the product, without permanently deleting it. The object continues to exist in the product but is no longer active in primary workflows. This action is commonly associated with actions like “Create,” “Delete,” and “Activate/Deactivate.”

Archiving is a lifecycle state change. The object still exists, can typically be restored, and may remain visible in filtered or archived views.

Pattern impact:

• Buttons:
  • The label should read “Archive.”
• Modals:
  • The title should be “Archive {object type}?”
  • The primary action button label should be “Archive.”
• Pages (if applicable):
  • The title should be “Archive {object type}.”

If the object can be restored, use the inverse action “Activate” or “Restore,” depending on the system terminology, to return it to an active state.

Edit vs. manage

Use “Edit” when you can change the input of a field (letters, numbers, properties). Place as link text next to the field or area being edited. Pair this verb with a noun if it’s unclear what is being edited.

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

Export vs. download

Use “Export” as the call to action when users need to transfer data from Certara and convert it into a different format.

Use “Download” as the call to action when users need to copy data of the same format from Certara to a computer system.

Import vs. upload

Use “Import” as the call to action when users need to transfer data and convert it into a different format that can be used in Certara.

Use “Upload” as the call to action when users need to copy data of the same format from a computer system into Certara.

Save vs. apply

Use “Save” when a change is saved immediately to a database.

Use “Apply” for deferred saves. Occasionally, confirming changes within a modal results in these changes being treated as unsaved adjustments on the current page, that are not promptly saved to the database.

Use “Apply all” when users make bulk changes to a set of items where the final “Save” action is deferred.

Save vs. update

Use “Save” when users are adjusting settings for items created or added within the product, such as projects, studies, analyses, specs, or data packages. This function is often linked with actions like “Create” and “Add.”

Use “Update” for items that have been published and require re-publication. It is similar to saving changes made to a created item. Updating is commonly associated with the action of “Publish.”

View vs. see

Use “View” when you’re encouraging users 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. For example, “View details” or “Try clearing your filters to view all results.”

Use “See” in more general, conversational descriptions without a specific call to action. For example, “Add your first analysis and see how your data looks.”

Show/hide vs. enable/disable vs. activate/deactivate

Use “Show” to make an existing UI element visible on the screen. The item already exists and continues to function; this action affects visibility only.

Use “Hide” to remove an existing UI element from view without deleting it or changing its functionality. These actions are commonly associated with actions like “Show/hide module”, and “Show/hide subscription”.

Pattern impact:

• Buttons:
  • The label should read “Show {object type}” or “Hide {object type}”
• Switches, checkboxes and radio buttons
  • The label should read “Show {object type}” if the action reveals it.
• Tables
  • Where a visibility column is used, table cells should read “Show” or “Hide”.

Use “Enable” when users turn on functionality for a feature, integration, or setting. The feature already exists but cannot function until enabled.

Use “Disable” when users turn off functionality for a feature, integration, or setting. The feature remains available but cannot function while disabled. These actions are commonly associated with actions like “Enable SSO”, and “Enable notification category”.

Pattern impact:

• Buttons:
  • The label should read “Enable {object type}” or “Disable {object type}”.
• Switches, checkboxes and radio buttons
  • The label should read “Enable {object type}” if the action turns on functionality.
• Badges
  • If an object is enabled and a badge is used, it should read “Enabled” and use a success badge.
  • If an object is disabled and a badge is used, it should read “Disabled” and use a neutral badge.

Use “Activate” for actions that give access to a product, organization, or account. Activation allows the person or entity to access and use the system.

Use “Deactivate” for actions that remove access from a product, organization, or account. The account or entity remains in the system but cannot access it while deactivated. These actions are commonly associated with actions like “Deactivate user”, and states like “Environment is active”.

Pattern impact:

• Buttons:
  • The label should read “Activate {object type}” or “Deactivate {object type}”.
• Modals:
  • The title should be “Deactivate {object type}?”
  • The primary action button label should be “Deactivate”.

In cases where users do not have direct control over their own access, use request-based language, for example, “Request access” or “Request role”. These actions submit a request and do not immediately change access.

Avoid using “Activate” or “Enable” when access depends on approval or admin control. Reserve those terms for actions that immediately change access or functionality.