Key UX Concepts

Keep in-product communication focused and concise

Users typically learn about feature releases outside of a product. Generally, users come to a product to complete a specific task, rather than to learn, explore, or find out about changes to the service. Thus, the role of new feature announcements is to help users orient themselves and become aware of any changes that can affect their workflows. To reduce cognitive load, keep concise any text that explains the feature and its benefits. Provide a Learn more link to where the feature is documented so that users can decide when to read more about it.

Give users control over surfacing information

Users are likely to immediately dismiss communication that covers or adds clutter to the interface, especially when the communication is not directly related to their workflow. Communication that appears without user action slows users down, adding friction and building frustration. This amplifies when communication is unrelated to the current task and forces users' attention away from it.
Unless you’re communicating a service-wide feature release, ensure that user action invokes the communication, as opposed to the communication loading automatically when users launch the service.

Minimize visual noise

Be mindful of what will grab most of users’ 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 them for communicating new features. We do recommend using flashbars to alert the user to large, service-wide announcements.

Types of feature announcements

Service-wide feature releases

Service-wide features affect all pages in the service. Only service-wide feature releases should use a flashbar as a feedback mechanism.

Page-level feature releases

Page-level feature releases refer to features that are introduced as a new page or a new section within a service. For example, adding a new dashboard page or a new sub-service within a service.

To mark new pages, use New labels in the side navigation. Because users typically see the side navigation as the site map of the service product, these labels give a first glance overview of new pages that have been introduced.

Include a popover, invoked by user action, that provides a summary of the functionalities introduced by the new page. Add an external Learn more link, guiding users to relevant service documentation about the new feature.

If you’re using a New label, change the behavior of collapsible sections. Open any section that is usually collapsed if one or more pages in that section use the New label. This improves discoverability.

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

<Box color="text-status-info" display="inline">
    header="Introducing [feature name]"
        Add feature description.{' '}
        <Link external>Learn more</Link>
    <Box color="text-status-info" fontSize="body-s" fontWeight="bold">

In-page feature releases

For in-page feature releases, add a new element to an existing page, or a new functionality to a page element. For example, adding a new widget on the dashboard.

Because users see these features when going through a specific workflow, the indicators announcing them should be subtle to minimize distractions. Indicate that a form element is new by adding -new on labels, headings, or group items (such as an individual radio button in a radio group).

Use in-page help content to explain or describe the feature. If a content ramp with the help panel can't be implemented, standalone learn more links may be used as a fallback. These links should be placed after descriptions. Don't add popovers for in-page feature announcements, as they can create double click targets or conflict with info links.

Some new features, such as a new option within a select component, might not be noticeable at first glance. To bring attention to these hidden features, leverage external channels, such as a blog or a feature spotlight, to announce the release.

General guidelines


  • New labels should persist for 30 days.
  • To communicate interactivity and not conflate with status related information, use the same blue that’s used for links for New labels in the side navigation (as opposed to green or another color).
  • Use New labels in the side navigation only for pages that are entirely new. Don’t use it to communicate a new addition to an existing page.
  • Always combine New labels in the side navigation with a popover.


  • Don't add New labels for changes of low importance, such as small bug fixes or minor UI improvements. Keep the visual noise to a minimum to decrease the cognitive load.
  • Don't launch popovers when the page loads. Popovers should always be initiated by user action.
  • Don’t use badges for labeling features as new.
  • Avoid using flashbars for releases that are not service-wide.
  • Don’t create a series of popovers that move from one new feature to the next. This can be unexpected and disorienting for users.
  • Don't add New labels to section headers in the side navigation, because this can create double-click targets. Instead, add New labels to every new page introduced in the new expandable section.

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.

New label

  • Use only the word New to call out new features. Don’t use other words, such as New release or Update.

  • Capitalize New labels in the side navigation. If you use the label in the context of the page, such as in the name of a field, the new 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 the format: - new, optional.

Popover content

  • For the title of the popover, use this format: Introducing [feature name]

    • For example: Introducing cache statistics

  • Follow the writing guidelines for popover.

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.


  • Follow the accessibility guidelines for popover.

Related patterns and components

Communicate to users which features are in beta or preview.
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.