• Original address: Bye, Bye Burger! What we learned from implementing the new Android Bottom Navigation
  • The Nuggets translation Project
  • Translator: Xiaonan Shen
  • Proofreader: Jaeger, Jamweak

I remember exactly what I was doing on March 15 when the news broke — when we were in the midst of ditching the burger menu in our Android job search app in favor of a visible tabbed navigation, Google’s announcement of the addition of the bottom navigation bar to the Android Material Design tutorial quickly spread through the Android community and sparked heated debate about the bottom bar’s visual and functional features.

Bottom navigation bar of Android. Source: Material Design Guidelines

At first, like everyone else, our enthusiasm was completely dampened. Choosing this new, unproven way of navigating that Google has thrown at us, instead of what we’ve been working on for months, made us panic. However, we decided to release a new version of our Android app shortly and be one of the first to use the new navigation bar.

Navigation bars and menus on mobile devices have always been a hot topic, especially with the introduction of burger menus and the emergence of smartphones as primary information consumption devices. This three-line menu has become the default navigation element in many major apps, such as Facebook, Spotify, and Youtube. However, this kind of navigation is less elegant because it hides relevant entries from the user’s view. For iOS applications, the bottom TAB bar, as a new visual navigation bar, has quickly become the standard way to implement the first level navigation bar on Apple smartphones.

Unfortunately, Android apps lack a proper solution to the bottom navigation bar, only giving apps like ours a burger menu. In order to keep the navigation bar visible without breaking the Material Design guidelines, (too many) app developers are starting to use the top TAB navigation bar. While tags work well for simple applications, they run out of space when you need to use secondary navigation or when you have more than three entrances. Given the “Thumb Zones” of mobile devices, the top space is also considered a difficult area for smartphone users to click on, especially compared to the bottom navigation bar.

With the introduction of the bottom navigation bar in Material Design, Google recognized the challenges faced by app developers and offered a solution from the user’s point of view to achieve a level 1 navigation bar that moved away from the burger. This makes us very happy to use it.

After deciding to use the bottom navigation bar, we entered the most challenging part, the design phase. In the midst of a lot of specification and animation, we had to make some important UX and product decisions:

Our bottom navigation bar

  • Hide while scrolling: We want to show as much content as possible on the user’s screen. Therefore, we decided to hide the navigation bar while scrolling down to give more space to the content area. Scrolling up reappears the navigation bar.
  • Transformation a navigation bar: Material Design at the bottom of the column has a very smooth animation, it refer to the transformation type navigation bar – when switching between different targets, the selected part can be amplified, and have not been selected elements will be backward, as to browse different targets on the navigation bar is a bit like browsing a merry-go-round. We decided to use this effect because it makes switching navigation targets a lot more fun. We hope this will drive our users to switch more between different functional groups in the app. Also, this animation is very important in our next point.

Android transform navigation bar. Source: Material Design Guidelines

  • Material Design look and feel: We wanted this bottom navigation bar to blend as much as possible into the native Android environment. This means investing more in animation and visual design. This is the only way we can achieve high acceptance among our Android user base — the last thing we want is for users to interact with the navigation bar and suspect that they’re using an app that was simply copied from iOS.
  • Save state: Apps that use the bottom navigation bar need to remember what the user did in each view group, which is very different from the burger menu. Because visible groupings are arranged for faster and more frequent switching, the click paths of each view group should be stored so that users can easily return to previous tasks. In contrast, an application that uses the Burger menu does not store state, and when the application returns to a group, it restarts from the first level of the view. Depending on the infrastructure of your application, saving state in groups can be a huge technical challenge, so I recommend discussing this with your development team as early as possible.
  • Reduce the number of groups: When we switched from the Burger menu to the bottom navigation bar, we only had to switch a few groups to make it easier to manage, which allowed us to get through design and development faster, while ensuring that only the most important entries were shown to the user. This allows us to move the entry to Settings to the three-point menu in the upper right corner, rather than placing it next to the most important features such as search, bookmarks and recommendations. I recommend being as strict as possible in deciding which features to put in the navigation bar. If your application has a large number of groups, the bottom bar may be relatively difficult to implement, and you may need to consider merging or rearranging some of them. Fortunately, we don’t have to do that.
  • While you need to figure out what features you want to implement in your new navigation bar, it’s more important not to get too bogged down in details until you’ve verified the core idea. Therefore, the minimum viable product in our bottom navigation bar does not contain a lot of extra polish. Of course, we will eventually add these additions to our product, but we just want to make sure we’re doing it right in the first place. We even released a version to a small number of users that didn’t save user status (see previous point). After we saw positive data in our test samples, we began to tackle the follow-up tasks.

It should be noted that while Google’sThe Material Design guidelinesWhile this may provide a detailed definition of how to use the new navigation bar, you still need to make some important decisions based on your own goals and how your application works.

We used The Google Play phased release feature to carefully roll out our new navigation bar to make sure the change worked as intended. Fortunately, we quickly confirmed that it did:

  • Increased user engagement: Our users became more active, which led to a significant increase in visits (both PV and monthly active users increased by double digits). At the same time, our users are coming back more often, which means that the new navigation resonates with users, leading to increased engagement (near double digit growth in visitor numbers and monthly active users).
  • App feature groups have grown: Important app features, like bookmarks and job recommendations, are now visible in the bottom bar, and their usage is reflected in the data (double – to triple-digit increases in the number of users entering these feature groups). This growth helps us better demonstrate our unique strengths to our users while improving the overall product experience.
  • No negative user feedback To date, we have received no complaints about the new navigation bar, either through direct user feedback or through app reviews. We’ve seen a lot of positive feedback through the above channels.

Burger menu vs. No Burger menu: We applied before and after changes to the navigation bar

Our venture with the new Android bottom navigation bar paid off, and we successfully achieved our goal of improving user experience and KPI performance. Therefore, if your app still relies on Burger navigation, I would strongly encourage you to explore this opportunity to switch to visible navigation. Of course, it is important to have a preliminary understanding of the design changes that need to be made before committing to development so that you have a better idea of the amount of work that will be done.

You can check out our latest version of the app here, which includes our subsequent design changes to the bottom navigation bar. The app is targeted at the German job market, so it may not have a full list of jobs in your location. I welcome any questions and thoughts, and look forward to your comments and emails.

Last but not least, I want to say thank you to our amazing design and development teams like Dema, Miguel and Cristian. They have implemented this new way of navigation in a way that makes it enjoyable and exciting.