GitLab navigation redesign 9.0-10.0

GitLab is a web-based git repository manager with wiki, issue tracking, CI, CD, and monitoring. GitLab operates under an open core business model where the core version of our product, GitLab Community Edition (CE), is free and open-source while GitLab Enterprise Edition (EE) and GitLab Enterprise Edition Premium (EEP) are held under a proprietary license and contain additional features not available in GitLab CE.

We work iteratively and out in the open at Gitlab with a release going out every month. In 9.0, we took a risk and tried to fix perceived problems in our navigation before thoroughly testing the solution with our users. As an open source project for a software development tool with a diverse user base, the feedback we receive is big, varied, and direct. The impact of this change was heard and felt immediately. Rather than respond reactively, we used an iterative UX research process to gain deeper insight and understanding of our user's needs. This process ultimately led to a complete re-imagining of the way users navigate within GitLab.

Step One: Understanding the problem

GitLab users had two ways of navigating, globally and contextually. Users could browse between groups and projects (global navigation) using the static left sidebar. Once within a project or group itself, users were presented with corresponding on-page navigation and content (contextual navigation) that changed as the user changed location.

First round moderated testing on existing navigation

Moderated user testing revealed significant problems with this configuration. In initial tests, six participants with a variety of job titles and experience with GitLab were asked to perform a series of tasks while we recorded their behavior. Results showed that users often had difficulty understanding where they were. The sidebar navigation competed with on-page navigation for the user’s attention, and to compound the issue, there were similarities between the menus which made them hard to distinguish.

Some users, whose primary focus was code review with little need for switching between projects, complained that the sidebar reduced their work area. To combat this problem, we gave users the ability to ‘pin’ or ‘unpin’ the sidebar. Pinning kept the sidebar in place, unpinning the sidebar removed it from the screen and placed it under a hamburger menu icon.

Step Two: Creating new problems

In 9.0, it was decided to 'unpin' the left-hand sidebar for all and place it permanently inside the hamburger menu. There was little quantitative data to support this change as our tracking tools were unable to detect how many people interacted daily with the sidebar. The decision was based mainly on anecdotal evidence gathered from developers, contributors, and users working on GitLab CE, the open source. version of our product. The push to make this change occurred for the following reasons:

• Users wanted more space to work and said they rarely interacted with the sidebar
• Eliminating 1,000+ lines of code needed to maintain the 'pinned' and 'unpinned' sidebar
• Alleviate context confusion between the sidebar and page navigations

The reaction from our user base was adverse and immediate. In addressing just some of the problems identified, we'd worsened the situation by failing to address the broader Information Architecture issues.

Step Three: Test, iterate, test, iterate...

With the amount of negative feedback outweighing the positive, there were calls to revert the 9.0 navigation change. Rather than revert, we went back to our initial user testing to look for answers. Individual issues were created to address each of the problems found in our initial round of research. The team gathered feedback inside each issue to discuss and refine the design.

Second round moderated testing using one prototype

These designs were then gathered together to create a single prototype for round two of moderated user-testing. In round two, six participants were tested on icon recognition, then given a series of tasks to perform using the interactive prototype.

High-level issues identified

• Overall, users feel the Interface looks like a ‘“tablet,” “mobile” or “responsive view” with “wasted space,” rather than designed for desktop
• Users still struggled to identify their location and understand how to perform basic tasks

Areas Improved

Users in this round are much more successful in finding their 'my projects,' and there is increased recognition of the issue and merge request icons Once again, the results were analyzed and prioritized according to the level of certainty we felt that the results were conclusive. New issues were created to address and track these new findings.

Third round A/B testing using two prototypes

We conducted a third round of A/B moderated user testing with twelve participants. The study split participants, showing each group of six a different prototype. Participants were asked to perform a series of tasks with close attention paid to time-on-task to more quantitatively gauge improvements in different areas of the navigation. Over the course of our research, we concluded that the global and contextual navigation elements weren’t wrong but that they should be switched. The header would remain static, containing global navigation elements. The sidebar would be contextual, changing as users moved through projects and groups.

High Level issues identified

• Users are still slow to adopt and use the many icons in the navigation
• Users rarely interact with the breadcrumbs, and only some used them for wayfinding
• One user remained unsure of location at times

Areas improved

No users commented that either interface looked like a “tablet,” “mobile” or “responsive view” and tooltips increased users ability to understand the meanings of the icons. Only one user expressed confusion over where they were located, the majority of users were able navigate the interface. Icons were more easily identifiable to users.

Step Four: Feature flag

During usability testing, you will eventually reach a point where users start demonstrating the same behavior. Once this happens, testing with more users will no longer yield anything new. It is time to implement solutions based on the user feedback and then re-test with different users. At this stage, the navigation had been through three rounds of usability testing with twenty-four users in total. We felt comfortable sharing the new navigation with a wider audience.

We placed this new navigation under a ‘feature flag,' enabling users to turn on the new navigation and take it for a spin. We now had the opportunity to get feedback from hundreds of real-world users. An issue dedicated to gathering user feedback was created, with users being asked to provide specific pieces of information to ensure we had the proper context for the input provided. We iterated on the navigation in our 9.4 and 9.5 releases using feedback gathered from those using the feature.

Conclusion

After three rounds of user testing and two months of iteration and feedback under a feature flag, we released GitLab 10.0 with an entirely new way to navigate. The response was overwhelmingly positive and marked a new beginning for the user research process at GitLab. The experience of introducing GitLab’s new navigation led to several key learning points:

• Learn what your users are doing, not what they say they are doing. Having User Research to back up design decisions kept us from second-guessing ourselves when we received feedback.
• Iterate. Breaking results into individual problems that can be solved on their own and brought back into full context allowed us to work rapidly.
• Progressive disclosure (internal > behind a feature flag > default) — this allowed us to iterate and fix things quickly using feedback from people that use the tool daily.
• Use the right tool for the job — for research we used InVision, then Framer, and then real code; each tool used when needed.