Rethinking navigation for a developer product

Reaching a document meant reproducing the shape of the repository in your head first: which repo, which branch, which folder, which file, and only then the documentation attached to it.

The mismatch wasn't that the model was wrong. It was that the product asked for a path when the user arrived with a question.

The redesign wasn't a single before-and-after exercise. We explored several information architectures, including versions that remained heavily Git-oriented and others that retained the repository tree in different forms.

I created and iterated on the interface concepts in Figma with Design and Product, observed user interviews, and used multiple rounds of A/B testing and feedback to refine the direction.

Simplifying the user-facing information architecture did not simplify the data model. The interface still had to reconcile multiple repositories, branches, documentation that differs between branches, permissions, unavailable repositories, cloud entities and GitHub-backed entities — while loading large repositories and large documentation sets without stalling.

The user shouldn't have to understand the complexity of the underlying data model simply because the frontend has to.

Three destinations at the top meant every entity underneath had to resolve to a predictable behavior: whether it is reachable, whether it is branch-aware, where it came from, and what the interface does when any of that is missing.

The final direction made the product easier to understand at first glance: Home became the product entry point, Docs became the place to browse documentation, and Search offered a direct route to information across repositories.

Git remained an important part of the underlying model, but it stopped dictating every step of the user's navigation.