By Brona O’Connor, Richard Sneesby, Bryan Ye, Arjan Helmer, Tamarah Walsh, Eric Auld, Tarra van Amerongen and Varsha Patel
In October 2024, we unveiled the new navigation through an Early Access Program to 6 key Atlassian products, significantly improving the experience that millions use every day. Read on to learn how we rebuilt a navigation for a product suite, and the principles and process that made it possible.
One navigation for all products
Atlassian released its first product, Jira, in 2002, with Confluence following shortly after in 2004. Since then, we’ve added hundreds of features, expanded platform capabilities, and grown our product suite through development and acquisition. As customers adopted multiple Atlassian products, the inconsistent navigation across products forced them to relearn the same tasks in different contexts. Finding work became a consistent pain point in user feedback.
On the engineering side, each product team customized their navigation to quickly ship features and meet specific needs. While this helped teams move faster initially, the differences multiplied. Soon, simple updates required changes across multiple codebases, making even the smallest of changes costly and complex. These fragmented codebases prevented us from creating the consistent experience our customers needed.
Introducing the new navigation
How did we solve the inconsistent user experience and our fragmented codebases? One navigation, one codebase. Now when users move between our products, they don’t have to relearn how to find their work. The navigation works the same way in every product while adapting to each product’s unique needs.
The journey, from vision to reality
From experience, we knew that unifying the navigation across our products would require careful planning and rigorous validation. Our first step was to learn from previous efforts.
Learning from the past to design the future
In 2018, we redesigned the navigation and took a one-size-fits-all approach, applying an identical navigation to every product.
The results weren’t what we hoped for. With the one-size-fits-all approach, we couldn’t address each product’s unique needs. We learned that consistency doesn’t mean everything has to be identical. There has to be a balance between consistency and flexibility.
The principles behind the pixels
Before starting any design, we need guiding principles to make sound decisions. Design choices are never neutral — they reflect fundamental beliefs about how things should be. We believe our customers should be able to move seamlessly between our products, getting more value from using them together. This belief is behind the core principles that guided our design decisions:
- Maintain predictability and familiarity by repeating design patterns across all products wherever possible.
- Allow user control and customization to show and hide what’s relevant and what’s not.
- Progressively disclose information to be approachable for new users while retaining the functionality needed by power users.
From top to side: Building for familiarity, scale and clarity
The most significant change we made from the previous navigation design was moving product navigation from the top bar to the sidebar. This decision unlocks key benefits to customers:
- Modern and familiar UI: Users today work across multiple tools, such as Google WorkSpace, Slack, and Microsoft Teams, all of which use a sidebar for primary tasks. By building on this industry pattern, we’re aligning with users’ existing mental models and reducing cognitive load as they switch between tools.
- Move quickly between projects: The sidebar provides the vertical space and information density needed for a bird’s-eye view of work that wasn’t possible with dropdown menus in the top bar. This means users can move between projects far more efficiently. For example, a product manager can check ideas for a new initiative, review the dependencies in a launch release, and see feedback coming in via support queues, all from the sidebar.
- Clear and streamlined use for the top and sidebar: With product navigation in the sidebar, we could streamline the top bar across all products. This top bar is now consistently dedicated to universal actions like search and create, which are immediately discoverable no matter what product you’re using.
Use, iterate, repeat
While past learnings help with what to avoid, we wanted to co-create with our customers from day zero. Through each of the new navigation’s multiple phases of testing, we found new insights that shaped our design.
Here’s how the design evolved through five phases of testing:
- We started with user research with 16 Jira users to learn how they navigate our products. The research highlighted two clear needs: users wanted to customize their navigation to work more efficiently, and they needed better ways to find frequent items, which could potentially be solved by Starred and Recent. These insights formed the foundation of our new navigation system.
- Since static design tools can’t capture the navigation’s full complexity, we prototyped with Vision Lab, Atlassian’s internal prototyping tool. This enabled us to validate the complex interactions, like drop and drag, and accordion panels, in a realistic environment.
- We built a Chrome plugin that turned on the new navigation. After onboarding 160 users from a wide range of organizations and user types, we ran ease-of-use testing and conducted detailed interviews. Users loved the customization options so much that they wanted more of it. They wanted to personalize project navigation and have easier ways to hide sidebar items.
- Taking this feedback into account, we created a low-code prototype that allowed us to test our new design. Through this testing, we discovered that while settings were initially harder for users to find, the location made sense once discovered, as it matched patterns in other tools. From this, we decided to focus on onboarding users to settings locations.
- The final test before EAP was internal with Atlassians. One key piece of feedback was around the discoverability of the sidebar collapse pattern. We quickly tested other options and shipped the one that performed best.
Each stage provided insights that helped us build the new navigation to the point we’re at with the current EAP. With Open Beta and a full release ahead, we’ll continue learning and iterating based on broader user feedback.
Diving into the technical design behind the new navigation
Let’s look at some technical aspects of interaction design and design systems that shaped the new navigation. These choices didn’t just solve today’s challenges — they’ve set us up to build and scale the navigation for the future.
Three components to rule them all
When we audited our product suite, we discovered just how fragmented our navigation had become. Each product team had built custom components for their specific needs, resulting in hundreds of components and 23 major inconsistencies between products. Through focused design sprints, we mapped these overlapping components and discovered something surprising — most navigation needs can be met with three reusable components (menu button, flyout menu, and expandable menu) so we began consolidating.
How we made the components flexible
The power of these three components lies in their flexibility. Each component starts with a core set of required properties, but it’s the optional properties that make these components customizable.
By mixing and matching these properties, a single component can adapt to countless scenarios. Need to provide more context? Add a description. Want quick actions to appear on hover? Add the actions property. Need to show it’s expandable? Add an indicator like a chevron. This modular approach is how we handle the hundreds of navigation patterns with just three base components, each customizable to support a variety of behaviours.
Properties in action
Let’s look at an example of properties. In the old navigation, related actions were scattered everywhere: star an item in one place, delete it from somewhere else, and find other options buried in settings pages. In the new navigation, every action related to a navigation item lives in a consistent place — right on the component itself. Hover over any item, and its actions menu appears. This pattern is consistent across all products, making the entire system more familiar and predictable.
In addition, the new navigation is built on a modern tech stack that’s faster, enables more contributions, and requires less context switching. Built with design system primitives, it comes with built-in support for accessibility and RTL languages. Changes can be made once and applied everywhere, making the system more robust and efficient to evolve.
Driving adoption: Make is dead easy
While we had consolidated components, we needed to make sure everyone could use them correctly. So we created a navigation library that became the single source of truth for our designers.
To support this, we created several resources. One key resource was a Figma spec template that guides designers through every consideration, from accessibility and responsiveness to empty states and content design. Another was a component library, complete with sticker sheets, implementation videos, and clear usage guidelines.
An example of our Figma spec template
Looking ahead, we’ll evolve these into a simpler set of components with clearly defined rules that will be available next year in the Atlassian Design System.
Sweating the details: Indentation is underrated
Navigation isn’t just about moving places — it’s about understanding how everything fits together. Our old navigation relied heavily on labels to show relationships and hierarchy, creating a lot of visual clutter.
We knew there had to be a cleaner way. Using our design system’s spacing tokens, we built indentation directly into our components themselves. Our new Expandable Menu Item component can show relationships and hierarchy between navigation items while keeping the interface modern and clean.
But design is about iteration. When we tested internally, we discovered an unintended consequence: navigation items were getting truncated too frequently, especially on smaller screens. The indentation was doing its job showing hierarchy, but at the cost of readability.
This is where our systematic approach paid off. Because we had built indentation directly into design tokens, we could adjust the entire system at once. With a single update to our spacing tokens, we found the sweet spot: a more compact indentation that maintained a clear hierarchy while improving readability across all screen sizes.
Design is never done
While launching this new navigation is a significant milestone, it’s just the foundation. We know the design will continue evolving as it moves from EAP to Beta and finally to General Availability — that’s a healthy part of the process. As our users bring diverse perspectives from administrators and developers to community advocates and non-technical users, we’re deliberately pacing our release to ensure we balance feedback from all these viewpoints.
To experience the new design, try our new navigation and share your feedback. If you’re interested in tackling similar challenges, we’re always looking for people who are passionate about creating better ways to work. Explore career opportunities or see what else we’re designing.
💌 The new navigation design team