Super Sidebar

Overview

GitLab had 15 user personas, a product that spanned groups, projects, and admin contexts, and navigation that had grown organically for years to accommodate all of it. The result was a cluttered, inconsistent experience that showed up consistently as a pain point in System Usability Score feedback.

This is the story of how we fixed it. A year of research, a north star exercise, an alpha behind a feature flag, and a GA release in GitLab 16.0 that shipped to every user on the platform. It also turned out to be the foundation that made Project Studio possible two years later.

---

The problem

Navigation debt accumulates quietly. Each addition makes sense in isolation. Over time, the whole becomes harder to understand than any of its parts.

GitLab's navigation had three distinct problems by the time we started. First, context switching between groups, projects, and admin areas created cognitive overhead. Users had to reorient every time they moved between contexts, and the nav gave them little help doing it. Second, the information hierarchy had inconsistencies that confused both new users trying to find their footing and power users who knew exactly what they wanted but had to hunt for it. Third, there was no coherent system behind the decisions. Each team had made reasonable local choices, but there was no global logic holding it together.

The stakes were high. Navigation is the one part of the product that every user touches in every session. Getting it wrong does not affect a feature, it affects everything.

---

Finding the north star

Before any design work, the team ran a north star exercise. We collected every piece of SUS feedback GitLab had received about navigation and coded it thematically. Three themes emerged that became the litmus test for every design decision that followed.

That exercise changed the nature of the work. Instead of debating opinions about what the nav should do, we had a set of user-derived criteria we could test any design against. A solution that hit all three themes was worth pursuing. One that hit two but compromised the third needed more thought. One that solved a problem not represented in the themes needed a strong justification.

It also removed a particular kind of paralysis. GitLab has a wide, opinionated user base. Power users are vocal. New users are not. Without a clear frame, every design decision becomes a negotiation between whoever speaks loudest. The north star gave us a way to cut through that.

---

The constraint that shaped everything

We made one commitment early that shaped every subsequent decision: nothing we ship will degrade a user's current workflow.

This meant the alpha had to be fully usable by GitLab's own team before it went wider. We ate our own cooking first. If something was broken or confusing for us, it was broken or confusing for users. The internal rollout was not a soft launch, it was a quality gate.

This constraint was not always comfortable. There were moments where we had ideas we believed in but could not ship yet because we had not hit the baseline. Holding that line required discipline, but it protected the rollout. When we eventually opened the alpha to a broader audience, we were confident in what we were asking people to try.

---

What we shipped

The Super Sidebar introduced a collapsible left navigation with two levels of hierarchy: top-level items with unique icons and contextual sub-level items that changed based on what the user was doing. No third level. The structure was consistent across groups, projects, and admin areas, so users could build a reliable mental model instead of relearning the nav every time they switched contexts.

Pinned items let users surface the links they used most, persisting across the contexts they moved through. The context switcher gave users a fast path between groups and projects without losing their place. Collapsing the sidebar to an icon rail freed up screen real estate for users who wanted it.

My specific contributions were in the polish layer where the details matter most. Icon consistency in the nav, because a single icon at the wrong stroke weight catches the eye in a way that erodes trust in the whole system. Badge variants, because a neutral count and an urgent alert should not look the same. Context switcher alignment, because small misalignments in repeated components compound across sessions into a feeling of low quality that users cannot always name but always feel.

These are not glamorous problems. They are the problems that separate a navigation that works from one that feels right.

---

Rollout and results

The alpha launched behind a feature flag, which let us gather real-world feedback while continuing to iterate. The volume and specificity of responses gave us signal we could not have gotten any other way. Some decisions were validated, others were revised. The feature flag approach meant users who found issues were reporting them against something we could still change, not something that had already shipped to everyone.

GA landed in GitLab 16.0. The results showed up in Customer Satisfaction scores and, more tangibly, in the enterprise upgrade cycle. Features that had been hard to discover became accessible. Customers who had been on the fence about upgrading to higher tiers had clearer paths to the capabilities that justified the cost.

---

What this project actually taught me

Going slower did not make for a better outcome than what came later with Project Studio. The year we spent on Super Sidebar was not wasted, but it was not the research depth that made the nav better. It was the shipping, the feedback, and the iteration.

What the Super Sidebar gave me was something more valuable than a research process. It gave me an understanding of every challenge we would face in changing GitLab's navigation at scale. The organizational dynamics, the user communication approach, the rollout strategy, the feature flag mechanics, the way vocal power users respond to change versus how the data actually looks. I had all of that in memory when Project Studio needed to move in 12 weeks instead of a year.

You cannot do the second one without the first one. The slow project built the judgment that made the fast project possible.