Navigation Proposal for What's New

Summary

Problem

When there are new product updates or when there are GTM activities for product launches, groupactivation often gets asked to help promotion of these updates by implementing in-product announcements (i.e. banners). Most recently we did so for Release 1 of GitLab Duo Core (epic)

Previous UX research also identified an actionable Product insight wherein for GitLab Duo features specifically, users want to be informed of improvements and updates. Today we have no solution to doing that in-product #516226

While these updates are important in driving successful adoption of any given product initiative, we tend to overuse banners and this results in a noisy user experience when using the product. Banners are also dismissible (and have high dismissal rates). If a user dismisses the banner, the update is gone forever.

Context

To support the upcoming Release 2 for GitLab Duo Core and any future needs for in-app announcements, we want to explore a more scalable solution that helps the business in promoting these updates whilst preserving the user experience when using GitLab.

For Release 2 of GitLab Duo Core specifically

We believe that a major barrier to GitLab Duo Core adoption is granular controls. Group/Project controls is being planned for 18.2.

For the following cohorts, we want to ensure they are aware of when granular controls is available and try to encourage enablement of GitLab Duo Core again:

• Existing customers (prior to May 15th) who have not yet enabled GitLab Duo Core
• New customers (after May 15th) that have chosen to disable GitLab Duo Core

Background

Link to epic / issue with overall feature proposal:

• Issue link is https://gitlab.com/gitlab-org/gitlab/-/issues/538452

Does this navigation proposal facilitate one of our primary JTBDs? Which job?

• It will support our ability to communicate new releases to users, and advertise larger scale features to users, including GitLab Duo, pricing & packaging efforts, and large scale feature releases.

How does this change improve the workflow for users attempting to complete that job?

• It will improve the affordance offered to What's New, and increase its accessibility, as currently it is nested in an area that is not quite as intuitive for users to get to.

How many users will be impacted by this proposed change?

• Limited
• Moderate
• All users

What is the product maturity stage of the associated feature?

• Experimental
• Beta
• General availability

How often do you expect an average GitLab user (not just your target persona) to reach for this functionality?

• Several times a day
• Once a day
• A few times a week
• Once a week
• Less than once a week

Proposed Solution

Our proposed solution involves the following updates:

• Leverage progressive disclosure to only surface to users the What's New section at the same hierarchy as Help when there is unread content. When content has been marked as read by opening the What's New drawer the menu item would go back to the Support Drawer either at one of two moments:
  • Next Load
  • Next Session

Unread Release Notes	No Unread Release Notes

Approaches considered

Alternative Locations

Option	Image	Description
Option 1 - Change copy + add badge (MVC change)		Changes Involved: Changing copy from Help to Support Add Unread Badge next to Support to further draw the users attention to Support Why it may work: Can further build on the change and approach it iteratively. Allows us to first mainly focus on improving the drawer update. Why it may not work: Not a drastic change from the current UX, potentially won't see a large impact to increasing engagement.
Option 2 - Add to profile menu		Changes Involved: Removing What's new from the Help menu and adding it to the Profile menu Why it may work: We are hypothesizing that the Profile menu gets more interaction at the moment than the Help menu, although we cannot confirm this as there are no analytics at the moment for this section. Why it may not work: It may not fit within the context of the menu items featured in that dropdown at the moment. Currently those items are very much geared towards the user, whereas What's new is more so focused on GitLab in general.
Option 3 - Redesigned help		Changes Involved: Redesigning the Help menu from a dropdown to appear in a drawer. Why it may work: Allows for a more comprehensive Support experience where we can really highlight What's new , as right now it is just featured as one of many options in a dropdown. Why it may not work: The scope involved in making the change may lead to it not working for this particular project.

Variations of Side Navigation Location

Option	Image	Description
Option 4 - Iconography		Changes Involved: Adding an icon to the top section of the side navigation, that when clicked, launches the What's new drawer Why it may work: Brings the What's new component to the next level of hierarchy. Why it may not work: There is a lot going on in that particular area of the product. With the Next badge, as well as the possibility for additional icons.
Option 5 - Stacked options		Changes Involved: Stack the What's new menu item immediately on top of the Help menu item Why it may work: Accomplishes the goal of removing the What's new option to the next level of hierarchy, bringing more visual presence to the functionality. Why it may not work: Adds more vertical height to an area where real estate is very desirable.
Option 6 - Balanced left and right		Changes Involved: Align the What's new menu item beside the Help menu item. Why it may work: Accomplishes the goal, while not adding vertical height. Why it may not work: Cases where the Admin CTA appear will need to be considered, at which point an alternative location would need to be found which is undesirable.
Option 7 - Just iconography		Changes Involved: Switch the Help and What's new menu items to be icons only. Why it may work: Does not take up any additional vertical space, and leaves room for the Admin CTA to appear. Why it may not work: Switching to only icons could lead to less affordance, and generally lead to less access for both areas of the product. Icon size would need to be further explored.

Justification

Business Case

As noted in the main issue description above, the business has on-going needs for promoting feature updates and releases in-product. The goal of promoting these updates are to ensure customers are aware of the evolving feature value in GitLab and adopt features. The next immediate need for this is GitLab Duo Core repackaging efforts as we believe adoption of these features as they evolve will reduce contraction and churn.

Without a visibile and scalable solution for these updates, the business will continue to rely on ad-hoc banners that lead to a noisy experience using the product.

Problem Validation

As noted in the main issue description above, this problem has already been validated as part of recent UX research around GitLab Duo feature adoption and onboarding. We identified an Actionable InsightProduct change wherein for GitLab Duo features specifically, users want to be informed of improvements and updates.

As part of this proposal, we are planning additional validation research to further support the hypothesis that the current placement of What's new is hard to find.

UX Review

Async UX Review completed with @aregnery.

Counterpart Support

Solution has full counterpart support from Product, UX, and Engineering.

Solution Validation

We completed an un moderated First Click Test testing 4 options with a sample size of 25 people. You can see a video outlining the testing here.

Baseline	Option 1	Option 5	Option 7
30% of participants correctly selected the correct option	52% of participants correctly selected the correct option	92% of participants correctly selected the correct option	41.7% of participants correctly selected the correct option

Review checklist

Requester

• Review the handbook page for navigation.
• Add relevant information to the issue description detailing your proposal, including usage and business drivers.
• List at least two other places you considered to introduce your feature.
• Add relevant designs to the Design Management area of the issue.
• Ensure your UI suggestion align with the Documentation Style Guide.
• Engage Technical Writing. They can help craft a term that best describes the feature(s) you’re proposing.
• Follow the product development workflow validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is mandatory for additions or when restructuring.
• Engage the Foundations Product Manager for approval. The Foundations DRI (@jtucker_gl) will work with UX partners in product design, research, and technical writing, as applicable.
• Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your item will live in more than one place.
• Ensure engineers are familiar with the implementation steps for navigation.

Foundations Product Manager

• Confirm proposal has necessary information
• Schedule design review for next milestone

Foundations Product Designer

• Confirm Pajamas guidelines are followed
• Confirm a11y needs are addressed
• Confirm burden of proof supplied for stated scope of access