Key UX concepts

Informing users about beta or preview features

To help ensure users know whether a feature is in beta or preview, clearly communicate the feature’s release state in the user’s workflow. Do this even if if the feature’s state is communicated through other communication channels.

Communicating the impact of the beta or preview state

Certain beta or preview features can affect users' workflows. For example, they can introduce functionality changes or be unsuitable for production workloads. Providing contextual information about these features helps users decide how they will use them. To reduce cognitive load on the user, keep your explanation concise. If there's additional information that would be helpful, provide a Learn more link.

Minimizing visual noise

Be mindful of what will attract the most attention on the screen. Loud visual indicators such as badges or flashbars can distract users from their main tasks. Because of this, we don’t recommend using badges to communicate information about beta or preview features. We do recommend using flashbars to alert the user when the entire product service is in beta or preview.

Beta and preview releases

Betas releases aren’t publicly announced. Teams use them to gather customer feedback before a general availability (GA) launch. Previews are expected to be publicly announced. Both beta and preview releases might not be immediately ready for all customers or might be missing key features.

Types of beta and preview announcements

Entire service in beta/preview

Use a flashbar to communicate that an entire service has launched in beta or preview state. The flash message should communicate the impact of the the beta or preview state for the service and provide links to learn more and to give feedback for the product.service. Use a flashbar only when the entire service is in beta or preview.

On the service homepage, the flashbar should be persistent, without a way to dismiss it, so the beta or preview state remains in view for the user. On every other page, users should be able to dismiss the flashbar.

Page or section in beta/preview

Page level releases refer to features in a beta or preview state that are introduced as a new page or a new section within a service. For example, adding a dashboard in preview or a table view in beta.

Using labels in the side navigation

Use Beta or Preview labels in the side navigation to mark pages appropriately. Marking features as beta or preview within the side navigation helps to set users’ expectations about these pages.

Include a popover communicating what users can expect from the page. For example, the popover content area can say: We’re improving the way to use [feature name]. Add an external Learn more link, guiding users to relevant service documentation about the feature, if available.

To implement the Beta or Preview labels in the side navigation, use the snippet below in the info slot of the SideNavigation component:

<Box color="text-status-info" display="inline">
  <Popover
    header="[Release type] feature"
    size="medium"
    triggerType="text"
    content={
      <>
        Add description about the feature state.{' '}
        <Link external>Learn more</Link>
      </>
    }
    renderWithPortal={true} 
  >
    <Box color="text-status-info" fontSize="body-s" fontWeight="bold">
      Beta
    </Box>
  </Popover>
</Box>

Using labels in page titles

In addition to the side navigation, append a - beta or - preview label to the page title. Because users might access the page through a direct link, and not only through the side navigation, this reinforces the page’s release type.

Include an info link and help panel to provide more information about the beta or preview, such as a description of what it entails, how it impacts users' workflows, and how to provide feedback. If you can't implement a content ramp with the help panel, you can use Learn more links as a fallback. Place the links after beta or preview descriptions.

Don't add additional popovers on the page for page-level beta and previews.

In-page features in beta or preview

For in-page features in beta or preview, add a beta or preview element to the existing page, or add functionality to a page element. For example, adding a beta setting in a creation flow.

To minimize distractions, the indicators announcing that the feature is in beta or preview should be subtle. Indicate that an element is in a given release type by adding - beta or - preview on labels, headings, or group items (such as an individual radio button in a radio group).

Leverage external channels, such as documentation, to bring attention to a hidden feature. For example, a beta option within a select component that might not be seen at first glance.

General guidelines

Do

  • Make sure to communicate the impact of a beta or preview in users’ workflows.
  • Mark pages as beta or preview within the side navigation to help set users’ expectations about these pages before they open them.
  • Plan your release so users will know when the feature is going into GA. This way users can stay engaged with the beta or preview, and also plan on using the feature in production workflows.
  • Use Beta or Preview labels in the side navigation only for pages that are entirely in a beta or preview release state.
  • Always combine Beta or Preview labels in the side navigation with a popover so that users can get more details about the features in those states.

Don't

  • Don’t rely only on external channels, such as documentation or email, to communicate that a feature is in beta or preview.
  • Don’t use the New label together with Beta or Preview
  • Don’t use badges for labeling features as beta or preview.
  • Don't use flashbars for releases that aren't service-wide.

Writing guidelines

General writing guidelines

  • Keep labels and descriptions clear and concise.

  • Use sentence case for all text. Don't use title case.

  • Use present-tense verbs and active voice wherever possible.

  • Don't use "please," "thank you," or Latinisms such as "e.g.," "i.e.," or "etc."

  • Localize the text on the user interface.

    • For example: If the interface is in French, all text should be written in French.

Beta and Preview labels

  • Only use Beta or Preview to call out new features. Don’t use other words, such as Beta feature or Experimental.

  • Capitalize Beta and Preview labels in the side navigation. If you use labels in the context of the page, such as in the name of a field, the beta or preview label should be lowercase and italicized, to match the optional styling. For more information, see form field.

  • If you need to label an optional field in the context of the page, use this format: - beta, optional

Popover content

  • For the title of the popover, use this format: [Release type] feature

    • For example: Beta feature

  • Follow the writing guidelines for popover.

Flashbar content

  • Follow the writing guidelines for flashbar.

Accessibility guidelines

General accessibility guidelines

  • Follow the guidelines on alternative text and Accessible Rich Internet Applications (ARIA) regions for each component.

  • Make sure to define ARIA labels aligned with the language context of your application.

  • Don't add unnecessary markup for roles and landmarks. Follow the guidelines for each component.

  • Provide keyboard functionality to all available content in a logical and predictable order. The flow of information should make sense.

  • Make sure you define ARIA labels for the selection inputs that are aligned with the language context of your application.

Popover

  • Follow the accessibility guidelines for popover.

Flashbar

  • Follow the accessibility guidelines for flashbar.

Related patterns and components

Communicate new feature releases to users.
Displays one or more page-level flash notifications to communicate the status of a user’s action, such as success, failed, and so on.
Provides on-demand contextual information about elements or events.