The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
|Content Last Reviewed||
As a global, foundational aspect of the GitLab product, the Foundations Group within the Manage stage leads navigation and settings. Still, it is a collaborative cross-stage effort, because Navigation is vital to the GitLab experience and significantly impacts users. Because of this, Foundations must align with every stage group to ensure that Navigation's overall useability takes precedence when balancing the business needs of individual stage groups.
This direction is constantly evolving and everyone can contribute:
~"Category:Navigation & Settings"label, or reach out to us internally in the
Navigation is the highway through which every feature is accessed or discovered, and it must be accessible for all types of people and abilities. For this reason, Navigation is one of the most important parts of any application’s user interface.
When Navigation is effective, users trust that they can rely on it to help orient and empower them within the product. This is an example of the habituating UI tenet of “I quickly achieve mastery”1, which means the user can go from zero knowledge to completing their task. From a business perspective, habituation can drive overall user retention, net retention, and conversions to paid tiers as the users trust the product more and return to use it on a daily basis.
Users with accessibility needs must be considered when designing and building Navigation. Many companies cannot adopt software that is not compliant with accessibility standards, and accessible Navigation is essential to comply with accessibility standards such as VPAT.
Our near-term vision includes an overhaul of the top and left Navigation in GitLab. Looking further down the road, we will also start to focus on things like the product landing page and global search to increase success in navigating GitLab. Settings are also part of the long-term Navigation strategy, but right now we have put that on hold to focus on primary Navigation.
Knowing that Navigation is a crucial part of our user’s adoption and confidence in GitLab, we are investing heavily in a new Navigation design. We have seen a great deal of user feedback showing that users have frustration and difficulty feeling oriented in GitLab, including picking up where they left off, because our robust feature set can be overwhelming.
We resourced a full product team (Foundations) to address foundational parts of GitLab like Navigation & Settings and our Design System to help improve the overall usability of our product. We believe that iterating on the user feedback helps us reach our goal of a fulfilling experience in GitLab. It’s a big undertaking and will take many steps, but we are on our way to delivering an amazing user experience.
At GitLab, our current Navigation structure has compounded complexity. The first challenge is that we have nine stages and 500+ features, and we know that our Navigation must enable the users to quickly find the things that matter to them. The second challenge is that we have 14 user personas who use our features for their day-to-day work, and our Navigation has to consider their varying needs. This means that Navigation that works well for one persona may not work well for others.
Due to habituation, Navigation can be difficult to change, because users learn patterns and gain muscle memory around the things they use every day. For these reasons, big changes or constant updates to Navigation could adversely affect a user’s ability to do their daily work. Even features that are eventually high satisfaction can undergo an initial phase of negative feedback (who moved my cheese?), since they can initially disrupt existing use patterns. We should be mindful that this reaction exists and use feature flags, surveys, and beta testing as necessary.
We're still evaluating if we need customizable navigation to address the challenges our users face. There have been many references to wanting to customize the Projects and Group menus in GitLab. However, we also know that Navigation customization presents some risks. For example, it’s incredibly difficult to write consistently helpful documentation for an inconsistent menu experience. Similarly, users may forget they’ve customized their menu by removing something and assume it no longer exists. In light of this, we will continue to listen and learn, if we add customizable aspects to Navigation, we must do so in non-destructive ways to ensure that the needs of both a customized experience and a consistent experience are in balance.
Given the challenges outlined above, we use a three-pronged approach to ensure we design a great Navigation experience for our users.
1) We narrowed our north star vision from the six designs to just one. This design is guidepost for future work. We just created 10 MVCs that we will start to weight an build starting in %15.7.
2) A quarterly review of SUS verbatims has given us insight to these 3 themes that we are using to test our north star vision during UXR. We will continue to refine these themes as we move forward.
We can consider these themes “closed” when we test the design prototype with our users and they report overall feelings in alignment with each of them. We can use the same user survey to collect feedback about MVCs that we ship, which will ensure we continue to deliver improved usability.
We will also monitor the SUS verbatims for instances of negative sentiment decreasing over time and a decreasing ratio of navigation feedback in the total number of verbatims.
3) We will validate any Navigation changes in the app by tracking all usage data on Navigation. In the future, we will have a process for A/B testing to compare the performance of Navigation updates.
Our vision includes space for many other navigational concepts that we can consider to help users feel oriented and to pick up where they left off. Examples of these are dashboards, user landing pages, keyboard Navigation, and other complementary features that will support this vision and give users what they need.
All roles & personas interact with Navigation. We are focusing on helping users orient themselves around the things that are most important to them, so that they can be more productive.
We feel we can have an impact in the retention of users and drive the overall net retention of our customers. All of our PPI metrics are segmented by tier, and we will also track our SUS (lag metric) verbatims based on tiered feedback.
We are now working as a team to draft our New navigation rollout plan. The issue is still in draft and needs buy in from Design, Engineering, Product, Growth, Technical Writing and Marketing.
Given that there are risks and challenges to changing the habituation of our users, we need many modes of data collection that inform the success of our delivery and adoption of the new navigation. Overall, positively impacting SUS is the goal, but we want to also make sure that we are not causing a detriment to conversions.
The metrics are:
In Progress: Determine how users will opt in to using the new navigation
In Progress: 15.3-15.9 - Add tracking to all navigational elements in GitLab to fill out our PPI of total clicks and give us the groundwork for Navigation updates. Having each menu item tracked will allow us to get accurate counts on usage. Having correct event names will allow us to move elements around in new designs and not have them tied to old event names.
In Progress: 15.6 - After narrowing down the north star direction, we will utilize RITE to iterate on a single proposal that addresses any lingering usability questions.
Later: TBD - Audit Navigation accessibility to check how we measure against the high bar of inclusive standards.
Done: ~15.6 - We took the final design for the north start and broke it down into 10 MVCs.
DONE: 15.3 - 15.6 - Create and test six designs from the north star vision with two phases of testing in UXR and get it down to 1 final design. This final design is the guidepost for all of our MVCs and ultimately what we ship to customers for the next year+. It’s the most valuable design investment we are doing on Navigation to meet our goals.
DONE: 15.4 - Ship the “Menu Menu” change as a small but valuable iteration on our current top Navigation that sets the stage for the north star design. It brings the current “Menu” menu, in alignment with the top bar and removes the redundant word “Menu.”
Navigation: As a general rule, we are not redesigning individual content pages that are owned by other teams.
For now, we have de-prioritized all other Navigation issues and work until we get the North Star MVC live. We are also not diving into full designs for dashboards or user pages until we get our north star underway. We will still be pursuing opportunity canvases and exploration into the business value of re-prioritizing these items.
We are not currently driving ARR through upselling or cross-selling with navigation. We could re-visit this if we begin to work on dashboards at some point.
Settings: Even though the category is Navigation & Settings, Settings are not prioritized on our current roadmap in the interest of getting the north star Navigation designed and into the build track.
In the future, we aim to focus on the following goals for settings:
As this is not a marketing category, we don't have a specific measure of maturity.
Here is a list of the top user upvoted issues with descending popularity:
By descending popularity