GitLab navigation was complex and confusing - that was the message we received from our users through issues and other feedback channels. Initially, to address these concerns, we conducted research around proposed solutions, but quickly found they wouldn't help users achieve their goals well enough to warrant implementing them. In the process of learning what wasn't working and what wouldn't work, we still didn't have clarity around why the navigation wasn't working. This article chronicles our journey to finding that clarity and developing navigation that is easier to use and better suited to our users' needs.
Our approach
As a first step, we reviewed past research and user feedback to ensure we had a solid understanding of what we had done and learned already. We found that we still needed more insight into why proposed changes weren’t receiving enough positive feedback to implement them.
Our goals were straightforward:
- understand what users are doing in GitLab
- study how they navigate the platform
- learn why they need certain navigation elements
Our perspective shifted from validating proposed solutions to going back to revalidate the problems that exist with our navigation experience. Our hypothesis was that with a deeper understanding of our users’ behavior and mental models for how they navigate around GitLab, we could develop concepts to better match their needs and improve their overall experience.
The scope of features in GitLab and the number of user personas across GitLab made this challenging. We have 16 personas to represent different types of users, all with unique goals and techniques to achieve those goals. We focused our efforts on a subset of those personas that best represented usage across GitLab to ensure a holistic understanding of different user needs. We wanted to learn how navigation among different personas was similar and where it differed, what worked well with the current navigation, and what challenges users faced.
Studying key persona cohorts
We conducted diary studies with cohorts of our key personas to learn what their primary tasks and workflows were at a deeper level. This provided us with many real-world examples of how they navigate to their tasks and why. We also learned what worked well with their current workflows, what pain points existed, and what workarounds were being used (such as creating browser bookmarks, typing in the URL to pull browser history, or keeping a bunch of browser tabs open) to streamline their tasks in GitLab.
We learned that for some users, many of their primary tasks don’t require much navigation within GitLab because they use outside tools that link into GitLab through notifications (e.g., Slack and email) or use direct links through other tools. We also learned that often users’ work is quite scoped in GitLab, and they would like easier access to some of their core features without having to wade through all of the other features they don’t use. This illuminated some unmet needs that would improve their workflows, such as having the ability to customize navigation to access things important to them more quickly and streamline their path to relevant projects.
Learning more about our users from a foundational perspective ensured that we had a solid base to build upon when considering changes to the navigation.
Anchoring to a North Star
To anchor the redesign process in user problems more broadly, a review of past feedback was analyzed that revealed three overarching themes with navigation-related feedback. These themes helped to guide the process and to remind us of the key problems we were trying to solve:
- minimize feeling overwhelmed (ability to customize left sidebar)
- orient users across the platform (differentiating groups and projects)
- pick up where you left off (switching contexts)
The team continually mapped back design concepts to these themes to ensure potential solutions were rooted in user problems.
Evaluating and iterating
Next, several navigation design concepts were developed and shared with users for feedback. Multiple rounds of solution validation testing were conducted with our key personas to determine which design concepts to move forward with. The testing revealed how users felt about each design and also how well each design supported users completing core tasks. We identified a final concept that supported mature and new GitLab users with common workflows.
Understanding mental models for sidebar organization
We wanted to revisit our groupings in the left sidebar because we’ve heard over time that the organization can be confusing and unintuitive, especially some categories such as Operations. We needed to understand our users’ mental models for how they would group these items, and why. Learning the thought processes behind their organization was critical for us to know what changes to make that would align with user expectations.
We ran facilitated card sort studies with our key personas to understand how they would group items in the left sidebar, and why. This helped us learn some areas that could benefit from readjusting, such as the Manage and Operate categories. We learned that users most often preferred to have analytics items together, for example, which is reflected in the Analyze tab. This insight, combined with patterns in analytics data, informed changes to the groupings in the left sidebar to better support workflows.
Launching and learning
Prior to launching to external users, the new navigation was released to internal team members and we collected feedback to help iterate and improve the experience.
Next, we launched the new navigation to external users as a toggle that could be turned on optionally. During this initial launch, a longitudinal study was conducted with a sample of GitLab users to learn how they experienced the change in the context of their real work. Over time, the study would provide insight into adoption among the entire user base.
We interviewed users prior to the monthlong study to learn more about their experience with the existing navigation. Then, they began using the new navigation while completing surveys and participating in interviews at checkpoints in the beginning, middle, and end of the month. This enabled us to capture their initial impressions of the new navigation, what they liked/disliked, how the new experience compared to the previous one, and if their sentiment changed over the course of the month as they continued to use the new navigation.
Users in this study found the new navigation to be an improvement from the previous one, and most preferred its features, including:
- the ability to pin items streamlined common workflows
- the new task-based sidebar categories in the sidebar, which they said felt more approachable, especially for newer users
- the new navigation changes, which they said weren’t too overwhelming and felt familiar
We also learned about some opportunities to iterate and improve the new experience. For instance, some users pointed out:
- the inability to pin entire Projects, Groups, or specific pages makes it difficult to streamline other workflows
- some users unpin items accidentally
- the overall lack of color can cause some features to blend in or be missed
- it's not always easy to know what’s new in GitLab
What’s next: Iterate, listen, and iterate again
To capture large-scale feedback on navigation over time, we launched a new navigation-focused quarterly survey in Q1 (February) of this year. This first quarter data established a baseline of our old navigation, and beginning in Q2 (May), we began collecting data on the new navigation experience. We will monitor this closely, and look for themes to help us learn what is working well and what may need further iteration.
This survey, along with our longitudinal study feedback and various other user feedback sources, will provide insights to help prioritize iterative improvements to the new navigation experience. Stay tuned for changes, and keep sharing your navigation feedback with us!
