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||
This direction page is a work in progress, and everyone can contribute:
~"Category:Navigation & Settings"label, or reach out to us internally in the
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.
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 have invested 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 internal 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, we recently added Pinning to the Navigation which is a non-destructive way to ensure that the needs of both a customized experience and a consistent experience are in balance.
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.
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. Along with SUS reviews, we are determining if there are any data visualizations that will give us a more robust look at our navigation usage and may lead to a new PPI.
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:
View the Foundations roadmap as a gantt here.
Given the challenges outlined above which changing navigation, we use a three-pronged approach to ensure we design a great Navigation experience for our users.
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 (after 16.1) 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.
4) We have increased the fidelity of the navigation proposal process to reduce changes that could affect SUS.
For the next three months, our focus is:
As this is not a marketing category, we don't have a specific measure of maturity.
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.